On 21/06/17 17:47, Stephen Pelc wrote:> On Mon, 19 Jun 2017 00:47:31 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> Again, you are missing my point entirely. >> >> The /language/ has not changed. > > In the same way that C hasn't changed.No, but that has already been discussed and there is no need to repeat it.> >> You are still stuck with a typeless >> system relying on programmers writing comments to describe a function's >> inputs and outputs. > > Just like C. And I read a lot of C.No, because C is a typed language. It is not a particularly strongly typed language, and some people write their C code in very weak ways (making everything an "int"). But it is a big step up from a typeless language and lets the compiler do a good deal of checking.> >> You are still stuck on doing everything with >> "cells", that are usually 16-bit or 32-bit, or double-cells - no >> standardised way of working with data of specific sizes. > > Unless you use a library for the purpose. Just like C.C has different sized types as part of the language, not just a library.> >> You are still >> stuck on a single word list, with 31 characters significance (the GA144 >> Forth is limited to "5 to 7" significant characters) - no modules, >> namespaces or other local naming. > > No, not me. We use 256 character significance. The base system has > about 20 named namesspaces.Very good. I was commenting here specifically on Forth as found on the GA144 toolchain, but I am glad you have namespaces and long identifiers.> >> Some details have changed, but the language has not. > > You persist in believing that colorForth represents the state > of Forth. It doesn't. It's a one-man system for one man's use > and Chuck Moore does not pretend anything else. >Again, the context has been Forth on the GA144 - and that /is/ colorForth. But again, I am glad to hear that it is not the state of Forth in general.> Stephen >
MCU mimicking a SPI flash slave
Started by ●June 14, 2017
Reply by ●June 21, 20172017-06-21
Reply by ●June 21, 20172017-06-21
On 21/06/17 17:50, Stephen Pelc wrote:> On Mon, 19 Jun 2017 00:47:31 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> You are still tied to blocks of 16x64 characters. > > I haven't used blocks for decades. You are deeply misinformed. >That was from information from the GA144 website.> Stephen >
Reply by ●June 21, 20172017-06-21
On 21/06/17 17:40, rickman wrote:> David Brown wrote on 6/21/2017 6:10 AM: >> Yes, you basically have a SERDES system for each of the I/O pins, and a >> whole array of hardware timers that can trigger the transfers. > > I think we are starting to see why the XMOS devices are so expensive, very > extensive dedicated hardware. Too bad they don't have a few programmable > digital blocks that can actually do something useful.The SERDES and timers are very simple, so I'm unconvinced they are the reason for any perceived expense. Have a look in the "ports" reference I previously gave you https://www.xmos.com/published/xs1-ports-introduction?version=latest You will see that the - SERDES is only a shift register plus buffer register, - each /port/ timer is only 16 bits and is constantly ticking, plus a register and comparator to enable timed i/o - there's a pinseq/pinsneq register and comparator Scarcely enough to dominate the chip area, especially when you consider the memory and xCONNECT switch fabric. Without knowledge, my guess is that the switch fabric will have a far larger area than the port logic, just as in FPGAs the interconnects are far larger than the IO cells.
Reply by ●June 21, 20172017-06-21
On 21/06/17 18:54, rickman wrote:> David Brown wrote on 6/20/2017 10:48 AM: >> On 20/06/17 14:12, Anton Ertl wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 19/06/17 16:44, Anton Ertl wrote: >>>>> A static checker might say that the DROP and the - access a value that >>>>> is not present in the stack effect, so they would be a little more >>>>> precise at pinpointing the problem, but stack depth issues are easy >>>>> enough that nobody found it worthwhile to write such a checker yet. >>>> >>>> I would be much happier to see the language supporting such static >>>> checks in some way (not as comments, but as part of the language), and >>>> tools doing the checking. Spotting such errors during testing is >>>> better >>>> than spotting them when running the program, but spotting them during >>>> compilation is far better. >>> >>> Why would that be? I can see that it's far better for programmers who >>> don't test their programs, but what is the advantage for programmers >>> who test their programs? >> >> Honestly? You can't see the advantage of spotting errors at as early a >> stage as possible? >> >> Why would someone bother writing test patterns to catch possible errors >> that the tools can see automatically? That is just a waste of >> everyone's time, and it's easy to forget some tests. > > You are showing your ignorance of Forth. The test code catches the > errors at compile time same as C.That is interesting to know, thank you. I have assumed that the tests being discussed were run-time tests. Do the compile time tests work correctly even for cross-compiled systems, where there may be different capabilities (say, different sizes for cells) from the host?> > If you are going to forget tests you are doomed. Every piece of code > should be written to a set of requirements, each of which must be > verified, usually by testing. Forget a test and you have unverified code.I did not suggest that tests should be omitted - I suggested that compile-time checks are useful in addition to run-time tests. And I still think that the kind of automatic compile-time checking that is possible with a language like C is better than having to manually write tests in Forth - quite simply, you need to write fewer test cases if the toolchain can check more things automatically.> > >> Errors of various sorts can happen when you write code. They can be >> everything from misunderstandings of the specifications, to small typos, >> to stylistic errors (which don't affect the running code, but can affect >> maintainability and lead to higher risk of errors in the future), to >> unwarranted assumptions about how the code is used. Producing a correct >> program involves a range of methods for avoiding errors, or detecting >> them as early as possible. Testing (of many different kinds) is /part/ >> of that - but it is most certainly not sufficient. It is /always/ >> cheaper and more productive to spot errors at an earlier stage than at a >> later stage - and detecting them at compilation time is earlier than >> detecting them at unit test time or system test time. > > See above... You don't understand Forth. > > >>>> (Better still is spotting them while editing >>>> - IDEs for C usually do a fair amount of checking while you write >>>> the code.) >>> >>> And I would especially hate it if an IDE is distracting me by nagging >>> me about minor details while I am focusing on something else. >> >> Incorrect code is not a minor detail. > > I've never seen a C editor that would catch anything more complex than > mismatched parentheses. Do editors look for missing variable > declarations now? >Yes. (As a technicality, the IDE might do this sort of thing by running a program like cppcheck in the background, but it appears the same to the user.)> >>>>> No! I have had lots of portability problems for C code when porting >>>>> between 32-bit and 64-bit systems, thanks to the integer type zoo of >>>>> C. In Forth I have had very few such problems, thanks to the fact >>>>> that we only have cells and occasionally double-cells (and when you >>>>> get a double-cell program right on 32-bit systems, it also works on >>>>> 64-bit systems). If you want a FLOOR5 variant that works for integers >>>>> that don't fit in a cell, you write DFLOOR5. And if it does not fit >>>>> in double cells (but would fit in 64 bits), you probably have the >>>>> wrong machine for what you are trying to do. C did not acquire 64-bit >>>>> integer types until 32-bit machines were mainstream. >>>>> >>>> >>>> And there you have illustrated my point, to some extent - C has >>>> progressed as a language, to include new features for more modern >>>> systems, such as support for 64-bit types. Now I can use a C compiler >>>> for an 8-bit microcontroller and have 64-bit datatypes. (OK, not all >>>> implementations have such support - but that is a quality of >>>> implementation issue, not a language failure.) >>> >>> If the language does not require the 64-bit types, you can hardly >>> claim them as a language feature. >> >> C /does/ require them (in C99), and they /are/ a language feature. >> (Technically, C requires an integer type that is at least 64 bits, but >> for most practical purposes, real implementations have exactly 64-bit >> types.) There are C compilers that don't support all of C99. >> >> And I have used 64-bit integers on an 8-bit microcontroller. It is a >> rare requirement, certainly, but not inconceivable. >> >>> >>> Anyway, if 64-bit integers were needed on 16-bit-cell systems, we >>> would add them to Forth. But in discussions about this subject, the >>> consensus emerged that we do not need them (at least not for >>> computations). >>> >>> By contrast, Gforth and PFE have provided 128-bit integers on 64-bit >>> systems since 1995, something that C compilers have not supported for >>> quite a while after that. And once GCC started supporting it, it was >>> quite buggy; I guess the static-checking-encouraged lack of testing >>> was at work here. >> >> Static checking is an addition to testing, not an alternative. >> >>> >>>> And it is perfectly possible to write C code that is portable across >>>> 32-bit and 64-bit systems >>> >>> There is a difference between "it is possible" and "it happens". My >>> experience is that, in C, if you have tested a program only on 32-bit >>> systems, it will likely not work on 64-bit systems; in Forth, it >>> likely will. >> >> I don't see a way to write portable code that works with known sizes of >> data in Forth. All I have seen so far is that you can use single cells >> for 16-bit data, and double cells for 32-bit data. This means if you >> want to use 32-bit values, your choice is between broken code on 16-bit >> systems or inefficient code on 32-bit systems. (And you can only tell >> if it is broken on 16-bit systems if you have remembered to include a >> test case with larger data values.) > > Again, you don't understand Forth. You use single cells or double > cells. Forth does not specify the cell size just as C does not specify > the size of an integer. >I understand that fine. And in a lot of C programming, it is a big pain that the language does not specify the size of an int - thus size-specific types are used (standardised in C99, but used long before that). So with C you have the choice to use efficient integers whose size depends on the target, or integers whose size is known and fixed.> >> I work on embedded systems. I need to be able to access memory with >> /specific/ sizes. I need to be able to make structures with /specific/ >> sizes. >> >> Can you show me how this is possible in Forth, in a clear, simple and >> portable manner? > > Forth has cells (a word) and chars (a byte). I don't find it to be a > problem, but then I don't typically jump back and forth between 32 and > 16 bit processors. What 16 bit processors do you actually use?msp430 and AVR (the AVR is 8-bit, but C "ints" and Forth cells are 16-bit). It looks like the answer is simply that Forth does not support convenient portable programming across different cell sizes in code where you need to be accurate about your data sizes. It is /possible/ (see Gerry's answers), but ugly and inconvenient. OK, that is an answer. It is not the only language with limitations like that. (It is quite possible that particular implementations of Forth, targeted specifically for embedded systems and cross-compilation, have extensions or additional word sets designed to make it easy to get exact sized types, to access memory in specific sized units, etc.)> > >>>> On the other hand, you don't seem to be able to write a FLOOR5 >>>> definition that will handle 32-bit values efficiently on both 16-bit >>>> cell systems and 32-bit cell systems. >>> >>> Tough luck. Why would I need a double FLOOR5 on a 16-bit platform? >>> >> >> That is not for you to worry about. Think of me as a customer asking >> for a piece of code written in Forth. I want a FLOOR5 function that >> handles 32-bit values, works correctly on 16-bit and 32-bit cell >> systems, and is efficient on both sizes of system. Can it be done? > > No one has customers asking for simple functions. >
Reply by ●June 21, 20172017-06-21
On Wed, 21 Jun 2017 19:16:08 +0200, David Brown <david.brown@hesbynett.no> wrote:>On 21/06/17 17:50, Stephen Pelc wrote: >> On Mon, 19 Jun 2017 00:47:31 +0200, David Brown >> <david.brown@hesbynett.no> wrote: >> >>> You are still tied to blocks of 16x64 characters. >> >> I haven't used blocks for decades. You are deeply misinformed. >> > >That was from information from the GA144 website.You are still deeply misinformed. Surely it's up to you to do your own research rather than blather "fake news" across the interwires. </g> Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
Reply by ●June 21, 20172017-06-21
Tom Gardner wrote on 6/21/2017 1:19 PM:> On 21/06/17 17:40, rickman wrote: >> David Brown wrote on 6/21/2017 6:10 AM: >>> Yes, you basically have a SERDES system for each of the I/O pins, and a >>> whole array of hardware timers that can trigger the transfers. >> >> I think we are starting to see why the XMOS devices are so expensive, very >> extensive dedicated hardware. Too bad they don't have a few programmable >> digital blocks that can actually do something useful. > > The SERDES and timers are very simple, so I'm unconvinced > they are the reason for any perceived expense. > > Have a look in the "ports" reference I previously gave you > https://www.xmos.com/published/xs1-ports-introduction?version=latest > You will see that the > - SERDES is only a shift register plus buffer register, > - each /port/ timer is only 16 bits and is constantly > ticking, plus a register and comparator to enable > timed i/o > - there's a pinseq/pinsneq register and comparator > > Scarcely enough to dominate the chip area, especially when > you consider the memory and xCONNECT switch fabric.So there is the equivalent of three 16 bit counter/timer/comparator/shifter/whatever for *each* port pin? That may not dominate the chip area, but it is going to add up fast. I'll bet it is larger than a set of fixed peripherals in low end MCUs that can be sold for $1. Just how much logic do you think is in an SPI port?> Without knowledge, my guess is that the switch fabric will > have a far larger area than the port logic, just as in FPGAs > the interconnects are far larger than the IO cells.Xilinx used to say they sell you the routing and give the logic away for free. What's your point? How do FPGAs come into the cost basis of the XMOS? The real issue is that they just can't compete in the low price end of MCUs where I feel they would be most useful. But they have their niche and I guess they aren't going anywhere soon. I wonder what it would take for the XMOS concept to be scaled up to cover more at the high end? -- Rick C
Reply by ●June 21, 20172017-06-21
David Brown wrote on 6/21/2017 1:29 PM:> On 21/06/17 18:54, rickman wrote: >> David Brown wrote on 6/20/2017 10:48 AM: >>> On 20/06/17 14:12, Anton Ertl wrote: >>>> David Brown <david.brown@hesbynett.no> writes: >>>>> On 19/06/17 16:44, Anton Ertl wrote: >>>>>> A static checker might say that the DROP and the - access a value that >>>>>> is not present in the stack effect, so they would be a little more >>>>>> precise at pinpointing the problem, but stack depth issues are easy >>>>>> enough that nobody found it worthwhile to write such a checker yet. >>>>> >>>>> I would be much happier to see the language supporting such static >>>>> checks in some way (not as comments, but as part of the language), and >>>>> tools doing the checking. Spotting such errors during testing is better >>>>> than spotting them when running the program, but spotting them during >>>>> compilation is far better. >>>> >>>> Why would that be? I can see that it's far better for programmers who >>>> don't test their programs, but what is the advantage for programmers >>>> who test their programs? >>> >>> Honestly? You can't see the advantage of spotting errors at as early a >>> stage as possible? >>> >>> Why would someone bother writing test patterns to catch possible errors >>> that the tools can see automatically? That is just a waste of >>> everyone's time, and it's easy to forget some tests. >> >> You are showing your ignorance of Forth. The test code catches the errors >> at compile time same as C. > > That is interesting to know, thank you. I have assumed that the tests being > discussed were run-time tests.What exactly is the difference? You compile a Forth program essentially by "running" the source code. So you run the code that defines new words and run the code that tests them. This is at such a basic level of Forth that I find it hard to believe you have actually given Forth anything but a cursory glance.> Do the compile time tests work correctly even for cross-compiled systems, > where there may be different capabilities (say, different sizes for cells) > from the host?More lack of knowledge of Forth. You can use a PC as a compiler for embedded Forth, but it is also very common to run Forth on the target with the PC just being for file storage and editing. If you can try not to tick off Steven you can go to his web site and download a copy that you can work with. Same at Forth, Inc.>> If you are going to forget tests you are doomed. Every piece of code >> should be written to a set of requirements, each of which must be >> verified, usually by testing. Forget a test and you have unverified code. > > I did not suggest that tests should be omitted -"it's easy to forget some tests." Does that refresh your memory?> I suggested that > compile-time checks are useful in addition to run-time tests. And I still > think that the kind of automatic compile-time checking that is possible with > a language like C is better than having to manually write tests in Forth - > quite simply, you need to write fewer test cases if the toolchain can check > more things automatically.Yeah, but when run time and compile time are hard to distinguish, the advantage goes away. You are writing applesauce about *more* tests. Which of the tests that Anton gave you were for catching the error you wrote in the code? None specifically and all in general. No extra tests needed. I would suggest at this point you stop trying to trash Forth based on what you thought you learned and instead give Forth a real go. Come here if you have questions and I'm sure you will get plenty of help. Oh, the only real reason I know of for not using Forth is the lack of Forth programmers for hire. Notice I said "for hire". There aren't many experts out there to bring in quickly if you have a problem. But it is not hard to train someone to use Forth, at least according to many here. The language is great and many have done lots with it.>>> Errors of various sorts can happen when you write code. They can be >>> everything from misunderstandings of the specifications, to small typos, >>> to stylistic errors (which don't affect the running code, but can affect >>> maintainability and lead to higher risk of errors in the future), to >>> unwarranted assumptions about how the code is used. Producing a correct >>> program involves a range of methods for avoiding errors, or detecting >>> them as early as possible. Testing (of many different kinds) is /part/ >>> of that - but it is most certainly not sufficient. It is /always/ >>> cheaper and more productive to spot errors at an earlier stage than at a >>> later stage - and detecting them at compilation time is earlier than >>> detecting them at unit test time or system test time. >> >> See above... You don't understand Forth. >> >> >>>>> (Better still is spotting them while editing >>>>> - IDEs for C usually do a fair amount of checking while you write the >>>>> code.) >>>> >>>> And I would especially hate it if an IDE is distracting me by nagging >>>> me about minor details while I am focusing on something else. >>> >>> Incorrect code is not a minor detail. >> >> I've never seen a C editor that would catch anything more complex than >> mismatched parentheses. Do editors look for missing variable declarations >> now? >> > > Yes.>> (As a technicality, the IDE might do this sort of thing by running a program > like cppcheck in the background, but it appears the same to the user.)Sounds like the territory someone here was complaining about of the false positives as code is typed in. I wonder how they keep from flagging stuff you are creating by going back and forth in code as you think?>>>>>> No! I have had lots of portability problems for C code when porting >>>>>> between 32-bit and 64-bit systems, thanks to the integer type zoo of >>>>>> C. In Forth I have had very few such problems, thanks to the fact >>>>>> that we only have cells and occasionally double-cells (and when you >>>>>> get a double-cell program right on 32-bit systems, it also works on >>>>>> 64-bit systems). If you want a FLOOR5 variant that works for integers >>>>>> that don't fit in a cell, you write DFLOOR5. And if it does not fit >>>>>> in double cells (but would fit in 64 bits), you probably have the >>>>>> wrong machine for what you are trying to do. C did not acquire 64-bit >>>>>> integer types until 32-bit machines were mainstream. >>>>>> >>>>> >>>>> And there you have illustrated my point, to some extent - C has >>>>> progressed as a language, to include new features for more modern >>>>> systems, such as support for 64-bit types. Now I can use a C compiler >>>>> for an 8-bit microcontroller and have 64-bit datatypes. (OK, not all >>>>> implementations have such support - but that is a quality of >>>>> implementation issue, not a language failure.) >>>> >>>> If the language does not require the 64-bit types, you can hardly >>>> claim them as a language feature. >>> >>> C /does/ require them (in C99), and they /are/ a language feature. >>> (Technically, C requires an integer type that is at least 64 bits, but >>> for most practical purposes, real implementations have exactly 64-bit >>> types.) There are C compilers that don't support all of C99. >>> >>> And I have used 64-bit integers on an 8-bit microcontroller. It is a >>> rare requirement, certainly, but not inconceivable. >>> >>>> >>>> Anyway, if 64-bit integers were needed on 16-bit-cell systems, we >>>> would add them to Forth. But in discussions about this subject, the >>>> consensus emerged that we do not need them (at least not for >>>> computations). >>>> >>>> By contrast, Gforth and PFE have provided 128-bit integers on 64-bit >>>> systems since 1995, something that C compilers have not supported for >>>> quite a while after that. And once GCC started supporting it, it was >>>> quite buggy; I guess the static-checking-encouraged lack of testing >>>> was at work here. >>> >>> Static checking is an addition to testing, not an alternative. >>> >>>> >>>>> And it is perfectly possible to write C code that is portable across >>>>> 32-bit and 64-bit systems >>>> >>>> There is a difference between "it is possible" and "it happens". My >>>> experience is that, in C, if you have tested a program only on 32-bit >>>> systems, it will likely not work on 64-bit systems; in Forth, it >>>> likely will. >>> >>> I don't see a way to write portable code that works with known sizes of >>> data in Forth. All I have seen so far is that you can use single cells >>> for 16-bit data, and double cells for 32-bit data. This means if you >>> want to use 32-bit values, your choice is between broken code on 16-bit >>> systems or inefficient code on 32-bit systems. (And you can only tell >>> if it is broken on 16-bit systems if you have remembered to include a >>> test case with larger data values.) >> >> Again, you don't understand Forth. You use single cells or double cells. >> Forth does not specify the cell size just as C does not specify the size >> of an integer. >> > > I understand that fine. And in a lot of C programming, it is a big pain > that the language does not specify the size of an int - thus size-specific > types are used (standardised in C99, but used long before that). So with C > you have the choice to use efficient integers whose size depends on the > target, or integers whose size is known and fixed. > >> >>> I work on embedded systems. I need to be able to access memory with >>> /specific/ sizes. I need to be able to make structures with /specific/ >>> sizes. >>> >>> Can you show me how this is possible in Forth, in a clear, simple and >>> portable manner? >> >> Forth has cells (a word) and chars (a byte). I don't find it to be a >> problem, but then I don't typically jump back and forth between 32 and 16 >> bit processors. What 16 bit processors do you actually use? > > msp430 and AVR (the AVR is 8-bit, but C "ints" and Forth cells are 16-bit). > > It looks like the answer is simply that Forth does not support convenient > portable programming across different cell sizes in code where you need to > be accurate about your data sizes. It is /possible/ (see Gerry's answers), > but ugly and inconvenient.Forth programmers often develop what they need. I don't see many discussing the issues of porting between AVR and ARM. I guess they don't often need that. Am I wrong? Mr. Pelc would be one to ask. He has developed Forth for a very wide range of systems with many different word sizes from 8051 to Pentiums. Same for Forth, Inc.> OK, that is an answer. It is not the only language with limitations like that. > > (It is quite possible that particular implementations of Forth, targeted > specifically for embedded systems and cross-compilation, have extensions or > additional word sets designed to make it easy to get exact sized types, to > access memory in specific sized units, etc.)See above.>>>>> On the other hand, you don't seem to be able to write a FLOOR5 >>>>> definition that will handle 32-bit values efficiently on both 16-bit >>>>> cell systems and 32-bit cell systems. >>>> >>>> Tough luck. Why would I need a double FLOOR5 on a 16-bit platform? >>>> >>> >>> That is not for you to worry about. Think of me as a customer asking >>> for a piece of code written in Forth. I want a FLOOR5 function that >>> handles 32-bit values, works correctly on 16-bit and 32-bit cell >>> systems, and is efficient on both sizes of system. Can it be done? >> >> No one has customers asking for simple functions. >> >-- Rick C
Reply by ●June 21, 20172017-06-21
On 21/06/17 20:05, rickman wrote:> Yeah, but when run time and compile time are hard to distinguish, the advantage > goes away.An interesting PoV, with some merit. However, having developed in both Smalltalk (=Forth for this argument) and Java (=C for this argument), I know I am /much/ more productive in Java. By "productive" I mean the time to find other people's libraries to do hard and complex tasks, use those libraries, compile and test until the program runs acceptably. A prime reason is that the "self-checking" built into the Java language enables both tool support (i.e. accurate refactoring and accurate "IDE control-space") and very rapid development of a wide range of libraries. Most other people agree with those sentiments; that's why Java is so dominant now, and Smalltalk and LISP are academic niche languages. (Annoyingly, some youngsters want to throw the advantages away in the interests of "programming with fewer keystrokes").
Reply by ●June 21, 20172017-06-21
On 21/06/17 19:34, rickman wrote:> Tom Gardner wrote on 6/21/2017 1:19 PM: >> On 21/06/17 17:40, rickman wrote: >>> David Brown wrote on 6/21/2017 6:10 AM: >>>> Yes, you basically have a SERDES system for each of the I/O pins, and a >>>> whole array of hardware timers that can trigger the transfers. >>> >>> I think we are starting to see why the XMOS devices are so expensive, very >>> extensive dedicated hardware. Too bad they don't have a few programmable >>> digital blocks that can actually do something useful. >> >> The SERDES and timers are very simple, so I'm unconvinced >> they are the reason for any perceived expense. >> >> Have a look in the "ports" reference I previously gave you >> https://www.xmos.com/published/xs1-ports-introduction?version=latest >> You will see that the >> - SERDES is only a shift register plus buffer register, >> - each /port/ timer is only 16 bits and is constantly >> ticking, plus a register and comparator to enable >> timed i/o >> - there's a pinseq/pinsneq register and comparator >> >> Scarcely enough to dominate the chip area, especially when >> you consider the memory and xCONNECT switch fabric. > > So there is the equivalent of three 16 bit > counter/timer/comparator/shifter/whatever for *each* port pin? That may not > dominate the chip area, but it is going to add up fast. I'll bet it is larger > than a set of fixed peripherals in low end MCUs that can be sold for $1. Just > how much logic do you think is in an SPI port?No. Read the reference supplied; the relevant bits are only 9 pages - and are in clear and simple English.>> Without knowledge, my guess is that the switch fabric will >> have a far larger area than the port logic, just as in FPGAs >> the interconnects are far larger than the IO cells. > > Xilinx used to say they sell you the routing and give the logic away for free. > What's your point? How do FPGAs come into the cost basis of the XMOS?It is the same principals and cost drivers at work. Your comment indicates you/Xilinx see the similarity.> The real issue is that they just can't compete in the low price end of MCUs > where I feel they would be most useful.... to you.> But they have their niche and I guess > they aren't going anywhere soon. I wonder what it would take for the XMOS > concept to be scaled up to cover more at the high end?A key decision for /all/ businesses is where /not/ to compete.
Reply by ●June 21, 20172017-06-21
> Just how much logic do you think is in an SPI port?I added the command port to my test code. In a real spi device, there should only be one serial chain, instead of three in mine. But i don't need to follow the standard spec. However, resource ultizations should be similar. Using elements: Max II: 67 / 240 ( 28 % ) Max 10: 154 / 8,064 ( 2 % ) I am using 60 cents of a $2 Max II, since i don't need anything else. Realistically, around 20 cents of a $10 Max 10. ---------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity ram is port( P7: in std_logic; -- preserve upper 9 bits for next shift P6: in std_logic; -- preserve upper 10 bits for next shift P5: in std_logic; -- preserve upper 11 bits for next shift ACLK, clear, pass : in std_logic; -- Address serial clock ASI: in std_logic; -- Address serial in ASO: buffer std_logic; -- Address serial out A: buffer std_logic_vector(16 downto 0); -- Address register AA: in std_logic_vector(16 downto 0); -- Address parallel in DCLK: in std_logic; -- Data serial clock DSI: in std_logic; -- Data serial in DSO: buffer std_logic; -- Data serial out D: buffer std_logic_vector(7 downto 0); -- Data register DD: in std_logic_vector(7 downto 0); -- Data parallel in CCLK: in std_logic; -- Command serial clock CSI: in std_logic; -- Command serial in CSO: buffer std_logic; -- Command serial out C: buffer std_logic_vector(7 downto 0); -- Command register CC: in std_logic_vector(7 downto 0) -- Command parallel in ); end ram; architecture arch of ram is begin process (ACLK, clear) begin if clear = '1' then A <= "00000000000000000"; elsif (P7 = '1') then A(9 downto 0) <= A(16 downto 7); elsif (P6 = '1') then A(10 downto 0) <= A(16 downto 6); elsif (P5 = '1') then A(11 downto 0) <= A(16 downto 5); elsif (pass = '1') then A <= AA; elsif (ACLK'event and ACLK='1') then ASO <= A(16); A(16 downto 1) <= A(15 downto 0); A(0) <= ASI; end if; end process; process (DCLK) begin if (pass = '1') then D <= DD; elsif (DCLK'event and DCLK='1') then DSO <= D(7); D(7 downto 1) <= D(6 downto 0); D(0) <= DSI; end if; end process; process (CCLK) begin if (pass = '1') then C <= CC; elsif (CCLK'event and CCLK='1') then CSO <= C(7); C(7 downto 1) <= C(6 downto 0); C(0) <= CSI; end if; end process; end arch;
