On 15/06/17 10:25, Reinhardt Behm wrote:> AT Thursday 15 June 2017 16:02, David Brown wrote: > >> On 15/06/17 09:25, Tom Gardner wrote: >>> On 15/06/17 08:14, David Brown wrote: >>>> On 14/06/17 19:44, John Speth wrote: >>>>> Hi folks- >>>>> >>>>> I'm hoping to tap into your various experiences to see if what I'm >>>>> thinking is practical. >>>>> >>>>> Our customer has a device into which a Datakey is plugged to extract >>>>> data stored in the device. The Datakey is a really just a trade name >>>>> for a SPI flash with ergonomic features that resemble a real key (see >>>>> datakey.com). Our customer would like to replace the Datakey with a >>>>> new design that will transmit the data wirelessly instead of storing it >>>>> to the Datakey SPI flash. >>>>> >>>>> We're proposing a design based on an MCU which will appear as a SPI >>>>> slave flash device, store the data pumped to it from the customer's >>>>> device, and forward it wirelessly. I'm wondering if it's practical to >>>>> accomplish it. The firmware would have to be totally responsive >>>>> temporally and in data content. That sounds like a tough hill to climb >>>>> that requires getting the interface just right, nearly perfect. I see >>>>> a lot of pitfalls that could make the effort a dead end. >>>>> >>>>> Does anybody have any success or failure stories to relate that would >>>>> help us gauge the feasibility of the proposed design? >>>>> >>>>> Thanks - John Speth >>>> >>>> If you make sure you have a MCU with good slave SPI support and DMA, >>>> then the actual SPI transfers should not be an issue (assuming a sane >>>> SPI clock speed). The cpu would then not be involved in the >>>> back-to-back SPI moves at all. Pretty much any Cortex M3/4 device >>>> should cope fine. >>>> >>>> The key challenge is how to deal with the commands - the bits that need >>>> some processing. That will probably mean fast response to the first few >>>> incoming SPI bytes via an interrupt function. Your requirements here >>>> will depend on the protocol, the clock speed, the processing time >>>> required, etc. >>>> >>>> Write-style SPI commands are no problem - just buffer up the SPI command >>>> and data with DMA as it comes in. It's the read-style ones that are the >>>> killer. For very fast SPI interfaces, it is not uncommon that with a >>>> read command, the first byte returned is a dummy byte - that gives you >>>> the time to fill your DMA buffer with the real data for the reply. But >>>> not all SPI protocols use that, and they might have some reads that need >>>> immediate response. If you can get that under control, the rest should >>>> be (relatively) easy. >>>> >>>> If you can't build this from a normal microcontroller because you need >>>> too fast response, your options are FPGA (either as an assist to a >>>> microcontroller, or with a processor in the FPGA) or perhaps an XMOS >>>> microcontroller. XMOS programming is a bit different from normal >>>> microcontroller programming, but it will handle tasks like this easily. >>> >>> I'll just say that I find XMOS programming to be *very* >>> easy compared to C+RTOS -- doubly so for a hardware engineer. >>> >>> The "RTOS" is in hardware => very low API learning curve :) >>> >> >> XMOS programming is very easy for some things, but hard for other >> things. In particular, there is a limit to the scalability. It starts >> off easy splitting your work into lots of parallel tasks, putting them >> each in threads, and everything is fine - until you run out of hardware >> threads. Then you end up destroying your structure to get a several >> logically parallel tasks running in the same hardware thread, or running >> a software RTOS in one hardware thread. And when you have your multiple >> high-speed interfaces working, you find you don't have enough ram left >> for buffers. >> >> XMOS devices can be a lot of fun, and I would enjoy working with them >> again. For some tasks, they are an ideal solution (like for this one), >> once you have learned to use them. But not everything is easy with >> them, and you have to think in a somewhat different way. >> >>> The programming model (CSP) is *very* simple and also >>> comprehensive. It was invented in the 70s, and has stood >>> the test of time. >> >> Yes, CSP is a great tool. I was taught it by some of the folks behind >> it. (Tony Hoare himself was head of the department, but I didn't have >> him as a lecturer.) > > Just grabbing this thread. > > XMOS sounds like something interesting to play with. > How good is the development environment? > Runs on Linux? >Yes, it runs fine on Linux. When I last worked seriously with XMOS (which was when it was a relatively new company), I had a a fair number of issues with the tools and, in particular, with the sample code. My understanding is that it has improved a good deal since then. And there is certainly no doubt that they are interesting to play with!
MCU mimicking a SPI flash slave
Started by ●June 14, 2017
Reply by ●June 15, 20172017-06-15
Reply by ●June 15, 20172017-06-15
On 15/06/17 09:02, David Brown wrote:> On 15/06/17 09:25, Tom Gardner wrote: >> On 15/06/17 08:14, David Brown wrote: >>> On 14/06/17 19:44, John Speth wrote: >>>> Hi folks- >>>> >>>> I'm hoping to tap into your various experiences to see if what I'm >>>> thinking is practical. >>>> >>>> Our customer has a device into which a Datakey is plugged to extract >>>> data stored in the device. The Datakey is a really just a trade name >>>> for a SPI flash with ergonomic features that resemble a real key (see >>>> datakey.com). Our customer would like to replace the Datakey with a new >>>> design that will transmit the data wirelessly instead of storing it to >>>> the Datakey SPI flash. >>>> >>>> We're proposing a design based on an MCU which will appear as a SPI >>>> slave flash device, store the data pumped to it from the customer's >>>> device, and forward it wirelessly. I'm wondering if it's practical to >>>> accomplish it. The firmware would have to be totally responsive >>>> temporally and in data content. That sounds like a tough hill to climb >>>> that requires getting the interface just right, nearly perfect. I see a >>>> lot of pitfalls that could make the effort a dead end. >>>> >>>> Does anybody have any success or failure stories to relate that would >>>> help us gauge the feasibility of the proposed design? >>>> >>>> Thanks - John Speth >>> >>> If you make sure you have a MCU with good slave SPI support and DMA, >>> then the actual SPI transfers should not be an issue (assuming a sane >>> SPI clock speed). The cpu would then not be involved in the >>> back-to-back SPI moves at all. Pretty much any Cortex M3/4 device >>> should cope fine. >>> >>> The key challenge is how to deal with the commands - the bits that need >>> some processing. That will probably mean fast response to the first few >>> incoming SPI bytes via an interrupt function. Your requirements here >>> will depend on the protocol, the clock speed, the processing time >>> required, etc. >>> >>> Write-style SPI commands are no problem - just buffer up the SPI command >>> and data with DMA as it comes in. It's the read-style ones that are the >>> killer. For very fast SPI interfaces, it is not uncommon that with a >>> read command, the first byte returned is a dummy byte - that gives you >>> the time to fill your DMA buffer with the real data for the reply. But >>> not all SPI protocols use that, and they might have some reads that need >>> immediate response. If you can get that under control, the rest should >>> be (relatively) easy. >>> >>> If you can't build this from a normal microcontroller because you need >>> too fast response, your options are FPGA (either as an assist to a >>> microcontroller, or with a processor in the FPGA) or perhaps an XMOS >>> microcontroller. XMOS programming is a bit different from normal >>> microcontroller programming, but it will handle tasks like this easily. >> >> I'll just say that I find XMOS programming to be *very* >> easy compared to C+RTOS -- doubly so for a hardware engineer. >> >> The "RTOS" is in hardware => very low API learning curve :) >> > > XMOS programming is very easy for some things, but hard for other > things. In particular, there is a limit to the scalability. It starts > off easy splitting your work into lots of parallel tasks, putting them > each in threads, and everything is fine - until you run out of hardware > threads. Then you end up destroying your structure to get a several > logically parallel tasks running in the same hardware thread, or running > a software RTOS in one hardware thread. And when you have your multiple > high-speed interfaces working, you find you don't have enough ram left > for buffers.Agreed. But then there are cliffs in /everything/ so it is unsurprising if this toolset also has them :) A more interesting question is whether the limitations are significant in a given context - and that's less easy to quantify. XMOS does provide some techniques (e.g. composable and interfaces) to reduce the sharpness of the cliffs, but not to eliminate them. But then the same is true of ARM+RTOS etc etc. I wouldn't regard XMOS as being a replacement for a general-purpose processor, but there is a large overlap in many hard-realtime applications. Similarly I wouldn't regard an ARM as being a replacement for a CPLD/FPGA, but there can be an overlap in many soft-realtime applications The XMOS devices inhabit an interesting and important niche between those two.> XMOS devices can be a lot of fun, and I would enjoy working with them > again. For some tasks, they are an ideal solution (like for this one), > once you have learned to use them. But not everything is easy with > them, and you have to think in a somewhat different way.Yes, but the learning curve is very short and there are no unpleasant surprises. IMNSHO "thinking in CSP" will help structure thoughts for any realtime application, whether or not it is formally part of the implementation.>> The programming model (CSP) is *very* simple and also >> comprehensive. It was invented in the 70s, and has stood >> the test of time. > > Yes, CSP is a great tool. I was taught it by some of the folks behind > it. (Tony Hoare himself was head of the department, but I didn't have > him as a lecturer.)My only contact with him was via his Elliott 803 Algol-60 compiler - and thanking him for it ~30 years later :)
Reply by ●June 15, 20172017-06-15
On 15/06/17 09:25, Reinhardt Behm wrote:> AT Thursday 15 June 2017 16:02, David Brown wrote: > >> On 15/06/17 09:25, Tom Gardner wrote: >>> On 15/06/17 08:14, David Brown wrote: >>>> On 14/06/17 19:44, John Speth wrote: >>>>> Hi folks- >>>>> >>>>> I'm hoping to tap into your various experiences to see if what I'm >>>>> thinking is practical. >>>>> >>>>> Our customer has a device into which a Datakey is plugged to extract >>>>> data stored in the device. The Datakey is a really just a trade name >>>>> for a SPI flash with ergonomic features that resemble a real key (see >>>>> datakey.com). Our customer would like to replace the Datakey with a >>>>> new design that will transmit the data wirelessly instead of storing it >>>>> to the Datakey SPI flash. >>>>> >>>>> We're proposing a design based on an MCU which will appear as a SPI >>>>> slave flash device, store the data pumped to it from the customer's >>>>> device, and forward it wirelessly. I'm wondering if it's practical to >>>>> accomplish it. The firmware would have to be totally responsive >>>>> temporally and in data content. That sounds like a tough hill to climb >>>>> that requires getting the interface just right, nearly perfect. I see >>>>> a lot of pitfalls that could make the effort a dead end. >>>>> >>>>> Does anybody have any success or failure stories to relate that would >>>>> help us gauge the feasibility of the proposed design? >>>>> >>>>> Thanks - John Speth >>>> >>>> If you make sure you have a MCU with good slave SPI support and DMA, >>>> then the actual SPI transfers should not be an issue (assuming a sane >>>> SPI clock speed). The cpu would then not be involved in the >>>> back-to-back SPI moves at all. Pretty much any Cortex M3/4 device >>>> should cope fine. >>>> >>>> The key challenge is how to deal with the commands - the bits that need >>>> some processing. That will probably mean fast response to the first few >>>> incoming SPI bytes via an interrupt function. Your requirements here >>>> will depend on the protocol, the clock speed, the processing time >>>> required, etc. >>>> >>>> Write-style SPI commands are no problem - just buffer up the SPI command >>>> and data with DMA as it comes in. It's the read-style ones that are the >>>> killer. For very fast SPI interfaces, it is not uncommon that with a >>>> read command, the first byte returned is a dummy byte - that gives you >>>> the time to fill your DMA buffer with the real data for the reply. But >>>> not all SPI protocols use that, and they might have some reads that need >>>> immediate response. If you can get that under control, the rest should >>>> be (relatively) easy. >>>> >>>> If you can't build this from a normal microcontroller because you need >>>> too fast response, your options are FPGA (either as an assist to a >>>> microcontroller, or with a processor in the FPGA) or perhaps an XMOS >>>> microcontroller. XMOS programming is a bit different from normal >>>> microcontroller programming, but it will handle tasks like this easily. >>> >>> I'll just say that I find XMOS programming to be *very* >>> easy compared to C+RTOS -- doubly so for a hardware engineer. >>> >>> The "RTOS" is in hardware => very low API learning curve :) >>> >> >> XMOS programming is very easy for some things, but hard for other >> things. In particular, there is a limit to the scalability. It starts >> off easy splitting your work into lots of parallel tasks, putting them >> each in threads, and everything is fine - until you run out of hardware >> threads. Then you end up destroying your structure to get a several >> logically parallel tasks running in the same hardware thread, or running >> a software RTOS in one hardware thread. And when you have your multiple >> high-speed interfaces working, you find you don't have enough ram left >> for buffers. >> >> XMOS devices can be a lot of fun, and I would enjoy working with them >> again. For some tasks, they are an ideal solution (like for this one), >> once you have learned to use them. But not everything is easy with >> them, and you have to think in a somewhat different way. >> >>> The programming model (CSP) is *very* simple and also >>> comprehensive. It was invented in the 70s, and has stood >>> the test of time. >> >> Yes, CSP is a great tool. I was taught it by some of the folks behind >> it. (Tony Hoare himself was head of the department, but I didn't have >> him as a lecturer.) > > Just grabbing this thread. > > XMOS sounds like something interesting to play with. > How good is the development environment?Good, very usable, but I'm still exploring the degree of perfection :) Eclipse + LLVM + GDB based.> Runs on Linux?Yes. Download it and have a go. In the "run configurations" you choose between "hardware" and "emulator". I haven't tried "emulator", but I guess it means you don't need a devkit. Key documents are: - 30000 ft overview: http://www.xmos.com/published/xcore-architecture-flyer?version=latest - outline of concurrency: https://www.xmos.com/published/xc-concurrency - very readable xC tutorial: https://www.xmos.com/support/tools/programming?component=17653 -boards (also Farnell, and DigiKey): https://www.xmos.com/support/boards-selector -app notes: https://www.xmos.com/support/appnotes
Reply by ●June 15, 20172017-06-15
On 15/06/17 09:02, David Brown wrote:>> XMOS programming is very easy for some things, but hard for other > things. In particular, there is a limit to the scalability. It starts > off easy splitting your work into lots of parallel tasks, putting them > each in threads, and everything is fine - until you run out of hardware > threads. Then you end up destroying your structure to get a several > logically parallel tasks running in the same hardware thread, or running > a software RTOS in one hardware thread. And when you have your multiple > high-speed interfaces working, you find you don't have enough ram left > for buffers.I suppose I have a bias... I don't like creating a system then finding /a late stage/ during testing that it fails due to /occasionally/ missing timing constraints, or having livelock issues. I prefer a toolset that alerts me to those problems at the /earliest/ opportunity. If there's a cliff, then I can choose another route, or carefully walk along the clifftop or simply jump off :) The XMOS toolkit falls into the latter category.
Reply by ●June 15, 20172017-06-15
On 15/06/17 10:41, Tom Gardner wrote:> On 15/06/17 09:02, David Brown wrote: >> On 15/06/17 09:25, Tom Gardner wrote: >>> On 15/06/17 08:14, David Brown wrote: >>>> On 14/06/17 19:44, John Speth wrote: >>>>> Hi folks- >>>>> >>>>> I'm hoping to tap into your various experiences to see if what I'm >>>>> thinking is practical. >>>>> >>>>> Our customer has a device into which a Datakey is plugged to extract >>>>> data stored in the device. The Datakey is a really just a trade name >>>>> for a SPI flash with ergonomic features that resemble a real key (see >>>>> datakey.com). Our customer would like to replace the Datakey with >>>>> a new >>>>> design that will transmit the data wirelessly instead of storing it to >>>>> the Datakey SPI flash. >>>>> >>>>> We're proposing a design based on an MCU which will appear as a SPI >>>>> slave flash device, store the data pumped to it from the customer's >>>>> device, and forward it wirelessly. I'm wondering if it's practical to >>>>> accomplish it. The firmware would have to be totally responsive >>>>> temporally and in data content. That sounds like a tough hill to >>>>> climb >>>>> that requires getting the interface just right, nearly perfect. I >>>>> see a >>>>> lot of pitfalls that could make the effort a dead end. >>>>> >>>>> Does anybody have any success or failure stories to relate that would >>>>> help us gauge the feasibility of the proposed design? >>>>> >>>>> Thanks - John Speth >>>> >>>> If you make sure you have a MCU with good slave SPI support and DMA, >>>> then the actual SPI transfers should not be an issue (assuming a sane >>>> SPI clock speed). The cpu would then not be involved in the >>>> back-to-back SPI moves at all. Pretty much any Cortex M3/4 device >>>> should cope fine. >>>> >>>> The key challenge is how to deal with the commands - the bits that need >>>> some processing. That will probably mean fast response to the first >>>> few >>>> incoming SPI bytes via an interrupt function. Your requirements here >>>> will depend on the protocol, the clock speed, the processing time >>>> required, etc. >>>> >>>> Write-style SPI commands are no problem - just buffer up the SPI >>>> command >>>> and data with DMA as it comes in. It's the read-style ones that are >>>> the >>>> killer. For very fast SPI interfaces, it is not uncommon that with a >>>> read command, the first byte returned is a dummy byte - that gives you >>>> the time to fill your DMA buffer with the real data for the reply. But >>>> not all SPI protocols use that, and they might have some reads that >>>> need >>>> immediate response. If you can get that under control, the rest should >>>> be (relatively) easy. >>>> >>>> If you can't build this from a normal microcontroller because you need >>>> too fast response, your options are FPGA (either as an assist to a >>>> microcontroller, or with a processor in the FPGA) or perhaps an XMOS >>>> microcontroller. XMOS programming is a bit different from normal >>>> microcontroller programming, but it will handle tasks like this easily. >>> >>> I'll just say that I find XMOS programming to be *very* >>> easy compared to C+RTOS -- doubly so for a hardware engineer. >>> >>> The "RTOS" is in hardware => very low API learning curve :) >>> >> >> XMOS programming is very easy for some things, but hard for other >> things. In particular, there is a limit to the scalability. It starts >> off easy splitting your work into lots of parallel tasks, putting them >> each in threads, and everything is fine - until you run out of hardware >> threads. Then you end up destroying your structure to get a several >> logically parallel tasks running in the same hardware thread, or running >> a software RTOS in one hardware thread. And when you have your multiple >> high-speed interfaces working, you find you don't have enough ram left >> for buffers. > > Agreed. But then there are cliffs in /everything/ > so it is unsurprising if this toolset also has them :) > > A more interesting question is whether the limitations > are significant in a given context - and that's less > easy to quantify.Absolutely. One point to note is that when I worked with XMOS, one of their big features was that their architecture was so fast it could make a USB interface and an Ethernet interface in software. And yes, it /could/ work - but the cost in hardware threads and memory space (code and data go in the same ram) meant that there was very little left to do anything useful with the device. Since then, XMOS have realised that the big blocks are much more efficient in hardware - they now have devices with hardware Ethernet and USB rather than making them in software. The devices also have much more ram. I think XMOS should go further, and include hardware peripherals for common features - in particular, UARTs, I2C, SPI, timers. A simple hardware UART peripheral is a small and easy part to make in a chip design. With the XMOS, you can do it in software - you can write a nice, clear UART software block, without much coding space. But it takes two hardware threads - a quarter of your chip's power if you have a small device. Turned into cash, that's about $2 for a UART. On a chip microcontroller, you have lots of UARTs and they don't take significant resources - it's a "cost" of perhaps $0.02. For peripherals that you often need, it is /much/ cheaper to have dedicated hardware than to have them in software.> > XMOS does provide some techniques (e.g. composable > and interfaces) to reduce the sharpness of the cliffs, > but not to eliminate them. But then the same is true > of ARM+RTOS etc etc.Yes, there are learning curves everywhere. And scope for getting things wrong :-) XMOS gives a different balance amongst many of the challenges facing designers - it is better in some ways, worse in other ways.> > I wouldn't regard XMOS as being a replacement for > a general-purpose processor, but there is a large > overlap in many hard-realtime applications. > > Similarly I wouldn't regard an ARM as being a > replacement for a CPLD/FPGA, but there can be > an overlap in many soft-realtime applications > > The XMOS devices inhabit an interesting and important > niche between those two.Agreed.> > >> XMOS devices can be a lot of fun, and I would enjoy working with them >> again. For some tasks, they are an ideal solution (like for this one), >> once you have learned to use them. But not everything is easy with >> them, and you have to think in a somewhat different way. > > Yes, but the learning curve is very short and > there are no unpleasant surprises. > > IMNSHO "thinking in CSP" will help structure > thoughts for any realtime application, whether > or not it is formally part of the implementation. >Agreed.> >>> The programming model (CSP) is *very* simple and also >>> comprehensive. It was invented in the 70s, and has stood >>> the test of time. >> >> Yes, CSP is a great tool. I was taught it by some of the folks behind >> it. (Tony Hoare himself was head of the department, but I didn't have >> him as a lecturer.) > > My only contact with him was via his Elliott 803 > Algol-60 compiler - and thanking him for it ~30 > years later :)At the end of my degree course, I had the chance to stay and do a doctorate with Professor Hoare as one of my supervisors. But I choose to emigrate to Norway, get married, and try to find a job. It was the right choice.
Reply by ●June 15, 20172017-06-15
On 15/06/17 12:04, David Brown wrote:> On 15/06/17 10:41, Tom Gardner wrote: >> On 15/06/17 09:02, David Brown wrote: >>> On 15/06/17 09:25, Tom Gardner wrote: >>>> On 15/06/17 08:14, David Brown wrote: >>>>> On 14/06/17 19:44, John Speth wrote: >>>>>> Hi folks- >>>>>> >>>>>> I'm hoping to tap into your various experiences to see if what I'm >>>>>> thinking is practical. >>>>>> >>>>>> Our customer has a device into which a Datakey is plugged to extract >>>>>> data stored in the device. The Datakey is a really just a trade name >>>>>> for a SPI flash with ergonomic features that resemble a real key (see >>>>>> datakey.com). Our customer would like to replace the Datakey with >>>>>> a new >>>>>> design that will transmit the data wirelessly instead of storing it to >>>>>> the Datakey SPI flash. >>>>>> >>>>>> We're proposing a design based on an MCU which will appear as a SPI >>>>>> slave flash device, store the data pumped to it from the customer's >>>>>> device, and forward it wirelessly. I'm wondering if it's practical to >>>>>> accomplish it. The firmware would have to be totally responsive >>>>>> temporally and in data content. That sounds like a tough hill to >>>>>> climb >>>>>> that requires getting the interface just right, nearly perfect. I >>>>>> see a >>>>>> lot of pitfalls that could make the effort a dead end. >>>>>> >>>>>> Does anybody have any success or failure stories to relate that would >>>>>> help us gauge the feasibility of the proposed design? >>>>>> >>>>>> Thanks - John Speth >>>>> >>>>> If you make sure you have a MCU with good slave SPI support and DMA, >>>>> then the actual SPI transfers should not be an issue (assuming a sane >>>>> SPI clock speed). The cpu would then not be involved in the >>>>> back-to-back SPI moves at all. Pretty much any Cortex M3/4 device >>>>> should cope fine. >>>>> >>>>> The key challenge is how to deal with the commands - the bits that need >>>>> some processing. That will probably mean fast response to the first >>>>> few >>>>> incoming SPI bytes via an interrupt function. Your requirements here >>>>> will depend on the protocol, the clock speed, the processing time >>>>> required, etc. >>>>> >>>>> Write-style SPI commands are no problem - just buffer up the SPI >>>>> command >>>>> and data with DMA as it comes in. It's the read-style ones that are >>>>> the >>>>> killer. For very fast SPI interfaces, it is not uncommon that with a >>>>> read command, the first byte returned is a dummy byte - that gives you >>>>> the time to fill your DMA buffer with the real data for the reply. But >>>>> not all SPI protocols use that, and they might have some reads that >>>>> need >>>>> immediate response. If you can get that under control, the rest should >>>>> be (relatively) easy. >>>>> >>>>> If you can't build this from a normal microcontroller because you need >>>>> too fast response, your options are FPGA (either as an assist to a >>>>> microcontroller, or with a processor in the FPGA) or perhaps an XMOS >>>>> microcontroller. XMOS programming is a bit different from normal >>>>> microcontroller programming, but it will handle tasks like this easily. >>>> >>>> I'll just say that I find XMOS programming to be *very* >>>> easy compared to C+RTOS -- doubly so for a hardware engineer. >>>> >>>> The "RTOS" is in hardware => very low API learning curve :) >>>> >>> >>> XMOS programming is very easy for some things, but hard for other >>> things. In particular, there is a limit to the scalability. It starts >>> off easy splitting your work into lots of parallel tasks, putting them >>> each in threads, and everything is fine - until you run out of hardware >>> threads. Then you end up destroying your structure to get a several >>> logically parallel tasks running in the same hardware thread, or running >>> a software RTOS in one hardware thread. And when you have your multiple >>> high-speed interfaces working, you find you don't have enough ram left >>> for buffers. >> >> Agreed. But then there are cliffs in /everything/ >> so it is unsurprising if this toolset also has them :) >> >> A more interesting question is whether the limitations >> are significant in a given context - and that's less >> easy to quantify. > > Absolutely. > > One point to note is that when I worked with XMOS, one of their big > features was that their architecture was so fast it could make a USB > interface and an Ethernet interface in software. And yes, it /could/ > work - but the cost in hardware threads and memory space (code and data > go in the same ram) meant that there was very little left to do anything > useful with the device. Since then, XMOS have realised that the big > blocks are much more efficient in hardware - they now have devices with > hardware Ethernet and USB rather than making them in software. The > devices also have much more ram.Sounds very plausible, and answers one of the questions that was on my "to be answered" list. I don't think either of us are surprised.> I think XMOS should go further, and include hardware peripherals for > common features - in particular, UARTs, I2C, SPI, timers. A simple > hardware UART peripheral is a small and easy part to make in a chip > design. With the XMOS, you can do it in software - you can write a > nice, clear UART software block, without much coding space. But it > takes two hardware threads - a quarter of your chip's power if you have > a small device. Turned into cash, that's about $2 for a UART. On a > chip microcontroller, you have lots of UARTs and they don't take > significant resources - it's a "cost" of perhaps $0.02. For peripherals > that you often need, it is /much/ cheaper to have dedicated hardware > than to have them in software.Hmmm. I understand why you are saying that, but dayOfWeek%2==1, so I'll disagree. The questions with such peripherals are: - where do you stop - switch matrix connections - apis The last is an extra learning curve, especially w.r.t. configuration.>> XMOS does provide some techniques (e.g. composable >> and interfaces) to reduce the sharpness of the cliffs, >> but not to eliminate them. But then the same is true >> of ARM+RTOS etc etc. > > Yes, there are learning curves everywhere. And scope for getting things > wrong :-) XMOS gives a different balance amongst many of the challenges > facing designers - it is better in some ways, worse in other ways.Agreed. Horses for courses. I feel comfortable with XMOS for bit-banging, DSP and similar. I am unclear about having non-trivial ethernet protocol stacks and similar.>>> Yes, CSP is a great tool. I was taught it by some of the folks behind >>> it. (Tony Hoare himself was head of the department, but I didn't have >>> him as a lecturer.) >> >> My only contact with him was via his Elliott 803 >> Algol-60 compiler - and thanking him for it ~30 >> years later :) > > At the end of my degree course, I had the chance to stay and do a > doctorate with Professor Hoare as one of my supervisors. But I choose > to emigrate to Norway, get married, and try to find a job. It was the > right choice.Curiously I made similar choices, although the University (Southampton) and destination were different.
Reply by ●June 15, 20172017-06-15
On 15/06/17 13:31, Tom Gardner wrote:> On 15/06/17 12:04, David Brown wrote: >> On 15/06/17 10:41, Tom Gardner wrote: >>> On 15/06/17 09:02, David Brown wrote:<snip>>> I think XMOS should go further, and include hardware peripherals for >> common features - in particular, UARTs, I2C, SPI, timers. A simple >> hardware UART peripheral is a small and easy part to make in a chip >> design. With the XMOS, you can do it in software - you can write a >> nice, clear UART software block, without much coding space. But it >> takes two hardware threads - a quarter of your chip's power if you have >> a small device. Turned into cash, that's about $2 for a UART. On a >> chip microcontroller, you have lots of UARTs and they don't take >> significant resources - it's a "cost" of perhaps $0.02. For peripherals >> that you often need, it is /much/ cheaper to have dedicated hardware >> than to have them in software. > > Hmmm. I understand why you are saying that, but > dayOfWeek%2==1, so I'll disagree. The questions > with such peripherals are: > - where do you stop > - switch matrix connections > - apis > The last is an extra learning curve, especially > w.r.t. configuration. >I am not sure you really /are/ disagreeing - because I agree that there is a balance here, and "where do you stop?" is an important question. The answer is somewhere between "I use this peripheral a lot, it is cheap in hardware but expensive in software" and "I use this peripheral occasionally, it is expensive in hardware but cheap in software". I.e., no, there is no clear dividing point, and different developers will have wildly different opinions. And different hardware designers have had different opinions too - from FPGA, through XMOS, PSoC, 68332/MPC5xxx with TPUs, to microcontrollers with configurable pin selections. A common theme is that while the more flexible systems let you make marvellously complicated peripherals that fit just right for a specialised need, most of the time they are used for simple UARTs, SPI, timers with capture or PWM, etc., and they are mostly very inefficient for those uses. And I agree that a simple peripheral is easier to use than a complicated one, and gives an easier interface. So if you want an 11-bit UART, and you have an XMOS UART, it is an easy matter to change the "NUMBER_OF_BITS" from 8 in the sample code to 11. But a hardware UART that is that flexible is likely to have scores of pages of register definitions to wade through to find the right options.> >>> XMOS does provide some techniques (e.g. composable >>> and interfaces) to reduce the sharpness of the cliffs, >>> but not to eliminate them. But then the same is true >>> of ARM+RTOS etc etc. >> >> Yes, there are learning curves everywhere. And scope for getting things >> wrong :-) XMOS gives a different balance amongst many of the challenges >> facing designers - it is better in some ways, worse in other ways. > > Agreed. Horses for courses. > > I feel comfortable with XMOS for bit-banging, DSP and > similar. I am unclear about having non-trivial ethernet > protocol stacks and similar. > > > >>>> Yes, CSP is a great tool. I was taught it by some of the folks behind >>>> it. (Tony Hoare himself was head of the department, but I didn't have >>>> him as a lecturer.) >>> >>> My only contact with him was via his Elliott 803 >>> Algol-60 compiler - and thanking him for it ~30 >>> years later :) >> >> At the end of my degree course, I had the chance to stay and do a >> doctorate with Professor Hoare as one of my supervisors. But I choose >> to emigrate to Norway, get married, and try to find a job. It was the >> right choice. > > Curiously I made similar choices, although the > University (Southampton) and destination were > different.When you are the kind of nerd that is likely to end up in an ivory tower doing all your "programming" as symbolic manipulation on a blackboard, you don't let the chance of a lifetime with a good woman pass you by!
Reply by ●June 15, 20172017-06-15
AT Thursday 15 June 2017 16:32, David Brown wrote:> On 15/06/17 10:25, Reinhardt Behm wrote: >> AT Thursday 15 June 2017 16:02, David Brown wrote: >> >>> On 15/06/17 09:25, Tom Gardner wrote: >>>> On 15/06/17 08:14, David Brown wrote: >>>>> On 14/06/17 19:44, John Speth wrote: >>>>>> Hi folks- >>>>>> >>>>>> I'm hoping to tap into your various experiences to see if what I'm >>>>>> thinking is practical. >>>>>> >>>>>> Our customer has a device into which a Datakey is plugged to extract >>>>>> data stored in the device. The Datakey is a really just a trade name >>>>>> for a SPI flash with ergonomic features that resemble a real key (see >>>>>> datakey.com). Our customer would like to replace the Datakey with a >>>>>> new design that will transmit the data wirelessly instead of storing >>>>>> it to the Datakey SPI flash. >>>>>> >>>>>> We're proposing a design based on an MCU which will appear as a SPI >>>>>> slave flash device, store the data pumped to it from the customer's >>>>>> device, and forward it wirelessly. I'm wondering if it's practical >>>>>> to >>>>>> accomplish it. The firmware would have to be totally responsive >>>>>> temporally and in data content. That sounds like a tough hill to >>>>>> climb >>>>>> that requires getting the interface just right, nearly perfect. I >>>>>> see a lot of pitfalls that could make the effort a dead end. >>>>>> >>>>>> Does anybody have any success or failure stories to relate that would >>>>>> help us gauge the feasibility of the proposed design? >>>>>> >>>>>> Thanks - John Speth >>>>> >>>>> If you make sure you have a MCU with good slave SPI support and DMA, >>>>> then the actual SPI transfers should not be an issue (assuming a sane >>>>> SPI clock speed). The cpu would then not be involved in the >>>>> back-to-back SPI moves at all. Pretty much any Cortex M3/4 device >>>>> should cope fine. >>>>> >>>>> The key challenge is how to deal with the commands - the bits that >>>>> need >>>>> some processing. That will probably mean fast response to the first >>>>> few >>>>> incoming SPI bytes via an interrupt function. Your requirements here >>>>> will depend on the protocol, the clock speed, the processing time >>>>> required, etc. >>>>> >>>>> Write-style SPI commands are no problem - just buffer up the SPI >>>>> command >>>>> and data with DMA as it comes in. It's the read-style ones that are >>>>> the >>>>> killer. For very fast SPI interfaces, it is not uncommon that with a >>>>> read command, the first byte returned is a dummy byte - that gives you >>>>> the time to fill your DMA buffer with the real data for the reply. >>>>> But not all SPI protocols use that, and they might have some reads >>>>> that need >>>>> immediate response. If you can get that under control, the rest >>>>> should be (relatively) easy. >>>>> >>>>> If you can't build this from a normal microcontroller because you need >>>>> too fast response, your options are FPGA (either as an assist to a >>>>> microcontroller, or with a processor in the FPGA) or perhaps an XMOS >>>>> microcontroller. XMOS programming is a bit different from normal >>>>> microcontroller programming, but it will handle tasks like this >>>>> easily. >>>> >>>> I'll just say that I find XMOS programming to be *very* >>>> easy compared to C+RTOS -- doubly so for a hardware engineer. >>>> >>>> The "RTOS" is in hardware => very low API learning curve :) >>>> >>> >>> XMOS programming is very easy for some things, but hard for other >>> things. In particular, there is a limit to the scalability. It starts >>> off easy splitting your work into lots of parallel tasks, putting them >>> each in threads, and everything is fine - until you run out of hardware >>> threads. Then you end up destroying your structure to get a several >>> logically parallel tasks running in the same hardware thread, or running >>> a software RTOS in one hardware thread. And when you have your multiple >>> high-speed interfaces working, you find you don't have enough ram left >>> for buffers. >>> >>> XMOS devices can be a lot of fun, and I would enjoy working with them >>> again. For some tasks, they are an ideal solution (like for this one), >>> once you have learned to use them. But not everything is easy with >>> them, and you have to think in a somewhat different way. >>> >>>> The programming model (CSP) is *very* simple and also >>>> comprehensive. It was invented in the 70s, and has stood >>>> the test of time. >>> >>> Yes, CSP is a great tool. I was taught it by some of the folks behind >>> it. (Tony Hoare himself was head of the department, but I didn't have >>> him as a lecturer.) >> >> Just grabbing this thread. >> >> XMOS sounds like something interesting to play with. >> How good is the development environment? >> Runs on Linux? >> > > Yes, it runs fine on Linux. When I last worked seriously with XMOS > (which was when it was a relatively new company), I had a a fair number > of issues with the tools and, in particular, with the sample code. My > understanding is that it has improved a good deal since then. And there > is certainly no doubt that they are interesting to play with!Thanks David and Tom. I will give it try. Unfortunately today my latest shipping from Digikey has arrived.So it has to wait 'til the next time, but I am busy enough. -- Reinhardt
Reply by ●June 15, 20172017-06-15
Tom Gardner wrote on 6/15/2017 3:01 AM:> On 15/06/17 02:54, rickman wrote: >> John Speth wrote on 6/14/2017 1:44 PM: >>> Hi folks- >>> >>> I'm hoping to tap into your various experiences to see if what I'm thinking >>> is practical. >>> >>> Our customer has a device into which a Datakey is plugged to extract data >>> stored in the device. The Datakey is a really just a trade name for a SPI >>> flash with ergonomic features that resemble a real key (see datakey.com). >>> Our customer would like to replace the Datakey with a new design that will >>> transmit the data wirelessly instead of storing it to the Datakey SPI flash. >>> >>> We're proposing a design based on an MCU which will appear as a SPI slave >>> flash device, store the data pumped to it from the customer's device, and >>> forward it wirelessly. I'm wondering if it's practical to accomplish it. >>> The firmware would have to be totally responsive temporally and in data >>> content. That sounds like a tough hill to climb that requires getting the >>> interface just right, nearly perfect. I see a lot of pitfalls that could >>> make the effort a dead end. >>> >>> Does anybody have any success or failure stories to relate that would help >>> us gauge the feasibility of the proposed design? >> >> I have no experience in building such a product, but why not use an actual >> SPI >> data flash as the intermediate storage while the MCU monitors the action and >> forwards the data? This would require periods when the MCU could read the >> data >> flash. Is that possible or practical? >> >> I had a design that needed a 30 MHz SPI like interface (not entirely >> compatible >> though) which was designed to read/write registers. I considered using a >> fast >> CPU to emulate the interface in software, but it just couldn't meet the >> timing. >> Even with a 700 MIPS processor I wasn't sure it could receive the command to >> read a register and then get the data onto the output fast enough. I'm >> not sure >> of the timing of the SPI interface you have, but it will likely be hard to >> emulate the SPI in software. > > That sounds easy for the XMOS processors: > - multicore (up to 32 100MIPS cores) > - FPGA-like i/o, e.g. SERDES, buffers, programmable > clocks to 250Mb/s, separate timer for each port > - i/o timing changes can be specified/measured in > software with 4ns resolution > - guaranteed latencies <100ns > - *excellent* programming model based on CSP > (summary: of "Occam in C") > - Eclipse-based dev environmentAny yet the XMOS can't run fast enough to return a result in the time available. What a pity, all dressed up an nowhere to go.> Currently I'm managing to count transitions in > software on two 50Mb/s inputs, plus do > simultaneous USB comms to a host computer.Can you output a result before the next input transition?> Processors plus £10 devkit available from Farnell > and DigiKey.Not a very good processor to use in cost conscious applications. The lowest price at Digikey is $3 at qty 1000. They can't make a part in the sub-dollar range? -- Rick C
Reply by ●June 15, 20172017-06-15
On 15/06/17 17:13, rickman wrote:> Tom Gardner wrote on 6/15/2017 3:01 AM: >> On 15/06/17 02:54, rickman wrote: >>> John Speth wrote on 6/14/2017 1:44 PM: >>>> Hi folks- >>>> >>>> I'm hoping to tap into your various experiences to see if what I'm thinking >>>> is practical. >>>> >>>> Our customer has a device into which a Datakey is plugged to extract data >>>> stored in the device. The Datakey is a really just a trade name for a SPI >>>> flash with ergonomic features that resemble a real key (see datakey.com). >>>> Our customer would like to replace the Datakey with a new design that will >>>> transmit the data wirelessly instead of storing it to the Datakey SPI flash. >>>> >>>> We're proposing a design based on an MCU which will appear as a SPI slave >>>> flash device, store the data pumped to it from the customer's device, and >>>> forward it wirelessly. I'm wondering if it's practical to accomplish it. >>>> The firmware would have to be totally responsive temporally and in data >>>> content. That sounds like a tough hill to climb that requires getting the >>>> interface just right, nearly perfect. I see a lot of pitfalls that could >>>> make the effort a dead end. >>>> >>>> Does anybody have any success or failure stories to relate that would help >>>> us gauge the feasibility of the proposed design? >>> >>> I have no experience in building such a product, but why not use an actual >>> SPI >>> data flash as the intermediate storage while the MCU monitors the action and >>> forwards the data? This would require periods when the MCU could read the >>> data >>> flash. Is that possible or practical? >>> >>> I had a design that needed a 30 MHz SPI like interface (not entirely >>> compatible >>> though) which was designed to read/write registers. I considered using a >>> fast >>> CPU to emulate the interface in software, but it just couldn't meet the >>> timing. >>> Even with a 700 MIPS processor I wasn't sure it could receive the command to >>> read a register and then get the data onto the output fast enough. I'm >>> not sure >>> of the timing of the SPI interface you have, but it will likely be hard to >>> emulate the SPI in software. >> >> That sounds easy for the XMOS processors: >> - multicore (up to 32 100MIPS cores) >> - FPGA-like i/o, e.g. SERDES, buffers, programmable >> clocks to 250Mb/s, separate timer for each port >> - i/o timing changes can be specified/measured in >> software with 4ns resolution >> - guaranteed latencies <100ns >> - *excellent* programming model based on CSP >> (summary: of "Occam in C") >> - Eclipse-based dev environment > > Any yet the XMOS can't run fast enough to return a result in the time > available. What a pity, all dressed up an nowhere to go.You'll have to explain that, because I don't understand what you are referring to.>> Currently I'm managing to count transitions in >> software on two 50Mb/s inputs, plus do >> simultaneous USB comms to a host computer. > > Can you output a result before the next input transition?Yes and no. Yes: the output (to a host processor and/or LCD) proceeds in parallel with the next capture phase. No: in the current incarnation there is a short gap between capture phases as the results are passed from one core to another and the next capture phase is started. While it isn't important in my application, I may be able to remove that limitation in future incarnations.>> Processors plus £10 devkit available from Farnell >> and DigiKey. > > Not a very good processor to use in cost conscious applications. The lowest > price at Digikey is $3 at qty 1000. They can't make a part in the sub-dollar > range?Don't presume everybody has your constraints.
