Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #26771 > unrolled thread
| Started by | John Speth <johnspeth@yahoo.com> |
|---|---|
| First post | 2017-06-14 10:44 -0700 |
| Last post | 2017-06-19 12:23 -0400 |
| Articles | 20 on this page of 121 — 18 participants |
Back to article view | Back to comp.arch.embedded
MCU mimicking a SPI flash slave John Speth <johnspeth@yahoo.com> - 2017-06-14 10:44 -0700
Re: MCU mimicking a SPI flash slave Don Y <blockedofcourse@foo.invalid> - 2017-06-14 16:30 -0700
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-14 21:54 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 08:01 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 12:13 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 18:01 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 16:52 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 23:37 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 18:15 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-16 09:25 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-16 13:52 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-18 22:56 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 00:21 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 09:02 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 08:36 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 14:47 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 09:23 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 15:34 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-20 00:16 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 09:49 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-20 22:44 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 12:10 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 12:40 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-21 18:19 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 14:34 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-21 21:41 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 17:14 -0400
Re: MCU mimicking a SPI flash slave edward.ming.lee@gmail.com - 2017-06-21 13:54 -0700
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 23:33 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 23:12 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-16 07:05 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-16 02:27 -0400
Re: MCU mimicking a SPI flash slave Tim Wescott <seemywebsite@myfooter.really> - 2017-06-14 23:17 -0500
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 08:03 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 09:14 +0200
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 08:25 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 10:02 +0200
Re: MCU mimicking a SPI flash slave Reinhardt Behm <rbehm@hushmail.com> - 2017-06-15 16:25 +0800
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 10:32 +0200
Re: MCU mimicking a SPI flash slave Reinhardt Behm <rbehm@hushmail.com> - 2017-06-15 21:48 +0800
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 10:09 +0100
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 09:41 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 13:04 +0200
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 12:31 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 14:20 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 17:46 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-16 13:21 +0200
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-16 13:55 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-16 16:34 +0200
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-16 15:40 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 00:47 +0200
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-21 15:47 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 19:15 +0200
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-21 15:50 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 19:16 +0200
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-21 18:00 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-22 11:24 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-22 12:12 -0400
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-16 14:22 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 03:15 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 00:54 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 10:30 +0200
Re: MCU mimicking a SPI flash slave albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-19 12:54 +0200
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 13:49 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 09:28 -0400
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 09:19 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 16:23 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 23:57 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 12:36 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-20 08:20 -0400
Re: MCU mimicking a SPI flash slave anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-19 14:44 +0000
Re: MCU mimicking a SPI flash slave albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-19 21:39 +0200
Re: MCU mimicking a SPI flash slave Cecil Bayona <cbayona@cbayona.com> - 2017-06-19 14:59 -0500
Re: MCU mimicking a SPI flash slave albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-20 09:25 +0200
Re: MCU mimicking a SPI flash slave Cecil Bayona <cbayona@cbayona.com> - 2017-06-20 11:50 -0500
Re: MCU mimicking a SPI flash slave anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-20 12:37 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 22:59 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-20 00:12 -0400
Re: MCU mimicking a SPI flash slave Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-20 10:25 +0300
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 10:44 +0200
Re: MCU mimicking a SPI flash slave dp <dp@tgi-sci.com> - 2017-06-20 02:36 -0700
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-20 11:25 +0100
Re: MCU mimicking a SPI flash slave Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-20 13:49 +0300
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-20 12:54 +0100
Re: MCU mimicking a SPI flash slave Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-20 16:09 +0300
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-20 15:24 +0100
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-20 17:46 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 22:28 +0200
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-21 00:58 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 13:08 +0200
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 16:28 +0200
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 12:58 +0200
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 12:57 +0200
Re: MCU mimicking a SPI flash slave Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-20 14:19 +0300
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 16:19 +0200
Re: MCU mimicking a SPI flash slave anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-20 12:12 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 16:48 +0200
Re: MCU mimicking a SPI flash slave Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-20 21:16 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 23:15 +0200
Re: MCU mimicking a SPI flash slave Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-21 07:30 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 12:54 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 19:29 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 15:05 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-21 21:34 +0100
Re: MCU mimicking a SPI flash slave "Elizabeth D. Rather" <erather@forth.com> - 2017-06-21 18:04 -1000
Re: MCU mimicking a SPI flash slave albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-22 10:26 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-22 11:56 -0400
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-22 09:20 +0000
Re: MCU mimicking a SPI flash slave Wasell <from_usenet@wasell.eu> - 2017-06-22 14:02 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-22 11:59 -0400
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-22 11:58 -0400
Re: MCU mimicking a SPI flash slave anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-22 08:19 +0000
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-19 09:53 +0100
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 10:16 +0100
Re: MCU mimicking a SPI flash slave John Speth <johnspeth@yahoo.com> - 2017-06-15 13:56 -0700
Re: MCU mimicking a SPI flash slave Don Y <blockedofcourse@foo.invalid> - 2017-06-15 14:41 -0700
Re: MCU mimicking a SPI flash slave John Speth <johnspeth@yahoo.com> - 2017-06-15 15:08 -0700
Re: MCU mimicking a SPI flash slave Don Y <blockedofcourse@foo.invalid> - 2017-06-16 11:34 -0700
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 18:20 -0400
Re: MCU mimicking a SPI flash slave edward.ming.lee@gmail.com - 2017-06-21 07:58 -0700
Re: MCU mimicking a SPI flash slave Walter Banks <walter@bytecraft.com> - 2017-06-19 12:23 -0400
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-06-15 10:09 +0100 |
| Message-ID | <b9s0B.63329$d13.37856@fx05.am4> |
| In reply to | #26780 |
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
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-06-15 09:41 +0100 |
| Message-ID | <gLr0B.74079$O06.57510@fx43.am4> |
| In reply to | #26779 |
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 :)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-15 13:04 +0200 |
| Message-ID | <ohtpct$91f$1@dont-email.me> |
| In reply to | #26782 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-06-15 12:31 +0100 |
| Message-ID | <Deu0B.62929$z%2.11532@fx27.am4> |
| In reply to | #26785 |
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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-15 14:20 +0200 |
| Message-ID | <ohttrn$nf0$1@dont-email.me> |
| In reply to | #26786 |
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!
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-06-15 17:46 -0400 |
| Message-ID | <ohuv1i$nlc$1@dont-email.me> |
| In reply to | #26785 |
David Brown wrote on 6/15/2017 7:04 AM: > 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. I think that depends on the design. Perhaps you are familiar with the GA144 with 144 processors at a cost of around $0.10 per CPU. They took a similar route with NO dedicated I/O hardware other than a SERDES receiver and transmitter pair. It is expected that all I/O would be through software. Along that line the chip boots through one of three I/O ports, async serial, SPI serial, a 2 wire interface and I believe there is a 1 wire interface but I'm not certain. Three of the CPUs can be ganged to form a parallel port/memory interface, two CPUs with 18 bits of I/O and the third 4 bits. All of this is controlled by software. I find the device has significant limitations overall, but certainly with a peak execution rate of 700 MIPS there is a lot of potential. Much like no one focuses on the idea that using the 4 input LUT of an FPGA as an inverter is excessively wasteful, the GA144 with its 10 cent CPUs gets us out of the thinking that using a CPU as a UART is wasteful. Not trying to be negative, but I see the $2 cost of an XMOS CPU as being excessive and wasteful. Heck, you can buy complete MCU devices for a fraction of that price. >> 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. The question is whether it is worth investing the time and energy into learning the chip if you don't focus your work in this realm. Personally I find the FPGA approach covers a *lot* of ground that others don't see and the region left that is not so easy to address with either FPGAs or more conventional CPUs is very limited. If the XMOS isn't a good price fit, I most likely would just go with a small FPGA. I saw the XMOS has a 12 bit, 1 MSPS ADC which is nice. But again, this only makes its range of good fit slightly larger. >>> 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. I prefer Forth for embedded work. I believe there is a Forth available. I don't know if it captures any of the flavor of CSP, mostly because I know little about CSP. I did use Occam some time ago. Mostly I recall it had a lot of constraints on what the programmer was allowed to do. The project we were using the Transputer on programmed it all in C. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-16 13:21 +0200 |
| Message-ID | <oi0eo5$2fr$1@dont-email.me> |
| In reply to | #26796 |
On 15/06/17 23:46, rickman wrote: > David Brown wrote on 6/15/2017 7:04 AM: >> On 15/06/17 10:41, Tom Gardner wrote: >>> On 15/06/17 09:02, David Brown wrote: > > I think that depends on the design. Perhaps you are familiar with the > GA144 with 144 processors at a cost of around $0.10 per CPU. They took > a similar route with NO dedicated I/O hardware other than a SERDES > receiver and transmitter pair. > > It is expected that all I/O would be through software. Along that line > the chip boots through one of three I/O ports, async serial, SPI serial, > a 2 wire interface and I believe there is a 1 wire interface but I'm not > certain. Three of the CPUs can be ganged to form a parallel port/memory > interface, two CPUs with 18 bits of I/O and the third 4 bits. All of > this is controlled by software. > > I find the device has significant limitations overall, but certainly > with a peak execution rate of 700 MIPS there is a lot of potential. > Much like no one focuses on the idea that using the 4 input LUT of an > FPGA as an inverter is excessively wasteful, the GA144 with its 10 cent > CPUs gets us out of the thinking that using a CPU as a UART is wasteful. > > Not trying to be negative, but I see the $2 cost of an XMOS CPU as being > excessive and wasteful. Heck, you can buy complete MCU devices for a > fraction of that price. I had a little look at the GreenArrays website for the GA144. It appears to be pretty much a dead company. There is almost nothing happening - no new products, no new roadmaps, no new software, no new application notes. It is a highly specialised device, with a very unusual development process (Forth is 50 years old, and it looks it - and these devices use a weird variant of Forth). I think it would be a very risky gamble to use these devices for a real project, even though there is a lot of interesting stuff in the technology. > > >>> 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. > > The question is whether it is worth investing the time and energy into > learning the chip if you don't focus your work in this realm. Certainly - working with XMOS means thinking a little differently. But it is not /nearly/ as different as the GA144. > Personally I find the FPGA approach covers a *lot* of ground that others > don't see and the region left that is not so easy to address with either > FPGAs or more conventional CPUs is very limited. If the XMOS isn't a > good price fit, I most likely would just go with a small FPGA. I saw > the XMOS has a 12 bit, 1 MSPS ADC which is nice. But again, this only > makes its range of good fit slightly larger. If you have lots of experience with FPGA development, it is natural to look to FPGAs for solutions to design problems - and that is absolutely fine. It is impossible to jump on every different development method and be an expert at them all - and most problems can be solved in a variety of ways. > > >>>> 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. > > I prefer Forth for embedded work. I believe there is a Forth > available. Available for what? The XMOS? I'd be surprised. > I don't know if it captures any of the flavor of CSP, mostly > because I know little about CSP. I did use Occam some time ago. Mostly > I recall it had a lot of constraints on what the programmer was allowed > to do. The project we were using the Transputer on programmed it all in C. > Occam has its own advantages and disadvantages independent of the use of CSP-style synchronisation and message passing. I have looked at Forth a few times over the years, but I have yet to see a version that has changed for the better since I played with it as a teenager some 30 years ago. The stuff on the GA144 website is absurd - their "innovation" is that their IDE has colour highlighting despite looking like a reject from the days of MSDOS 3.3. Words are apparently only sensitive to the first "5 to 7 characters" - so "block" and "blocks" are the same identifier. (You would think they would /know/ if the limit were 5, 6 or 7 characters.) Everything is still designed around punch card formats of 8 by 64 characters. I can appreciate that a stack machine design is ideal for a small processor, and can give very tight code. I can appreciate that this means a sort of Forth is the natural assembly language for the system. I can even appreciate that the RPN syntax, the interactivity, and the close-to-the-metal programming appeals to some people. But I cannot understand why this cannot be done with a modern language with decent typing, static checking, optimised compilation, structured syntax, etc.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-06-16 13:55 +0000 |
| Message-ID | <5943e208.127544966@news.eternal-september.org> |
| In reply to | #26809 |
On Fri, 16 Jun 2017 13:21:03 +0200, David Brown <david.brown@hesbynett.no> wrote: >I have looked at Forth a few times over the years, but I have yet to see >a version that has changed for the better since I played with it as a >teenager some 30 years ago. The versions shipped by the professional companies have changed a lot. The major commercial suppliers are Forth Inc and MicroProcessor Engineering. See http://www.forth.com http://www.mpeforth.com Forth does not suit everyone, but it has changed a lot since you were a teenager. 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
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-16 16:34 +0200 |
| Message-ID | <oi0q3l$954$1@dont-email.me> |
| In reply to | #26814 |
On 16/06/17 15:55, Stephen Pelc wrote: > On Fri, 16 Jun 2017 13:21:03 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> I have looked at Forth a few times over the years, but I have yet to see >> a version that has changed for the better since I played with it as a >> teenager some 30 years ago. > > The versions shipped by the professional companies have changed a lot. > The major commercial suppliers are Forth Inc and MicroProcessor > Engineering. See > http://www.forth.com > http://www.mpeforth.com > > Forth does not suit everyone, but it has changed a lot since you > were a teenager. > > Stephen > I had a look. No, FORTH has not progressed that I can see (unless you think adding colour to the editor is a revolution). Some FORTH compilers might be good at producing optimised code on microcontrollers, but that is an improvement in the implementations, not the language.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-06-16 15:40 +0000 |
| Message-ID | <5943f791.133057948@news.eternal-september.org> |
| In reply to | #26815 |
On Fri, 16 Jun 2017 16:34:55 +0200, David Brown <david.brown@hesbynett.no> wrote: >I had a look. No, FORTH has not progressed that I can see (unless you >think adding colour to the editor is a revolution). Some FORTH >compilers might be good at producing optimised code on microcontrollers, >but that is an improvement in the implementations, not the language. We use standard editors with syntax colouring files as we have done for decades. The professional Forth compilers, whether for microcontrollers or for the desktop, produce optimised native code. The current Forth standard is Forth-2012. See: http://www.forth200x.org/documents/forth-2012.pdf What you used 30 years ago did not include target code for USB stack FAT file system TCP/IP stack with HTTP, FTP and Telnet servers Embedded GUI and so on and so on Having been in the Forth compiler business for a very long time, I can assure you that the tools and libraries supplied in this decade are vastly superior to those of 30 years ago. 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
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-19 00:47 +0200 |
| Message-ID | <oi6vnb$qg6$1@dont-email.me> |
| In reply to | #26816 |
On 16/06/17 17:40, Stephen Pelc wrote: > On Fri, 16 Jun 2017 16:34:55 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> I had a look. No, FORTH has not progressed that I can see (unless you >> think adding colour to the editor is a revolution). Some FORTH >> compilers might be good at producing optimised code on microcontrollers, >> but that is an improvement in the implementations, not the language. > > We use standard editors with syntax colouring files as we have done > for decades. The professional Forth compilers, whether for > microcontrollers or for the desktop, produce optimised native > code. The reference to colour was for the "new" colorForth used by the GA144. I am not surprised you have syntax highlighting in your editors - /Forth/ may not have moved on, but your implementations of Forth toolchains seem top class and with modern features. > > The current Forth standard is Forth-2012. See: > http://www.forth200x.org/documents/forth-2012.pdf > > What you used 30 years ago did not include target code for > USB stack > FAT file system > TCP/IP stack with HTTP, FTP and Telnet servers > Embedded GUI > and so on and so on Those are all libraries provided by your implementation. That makes your implementation good and useful to users - it does not make the /language/ any better. > > Having been in the Forth compiler business for a very long time, > I can assure you that the tools and libraries supplied in this > decade are vastly superior to those of 30 years ago. > Again, you are missing my point entirely. The /language/ has not changed. You are still stuck with a typeless system relying on programmers writing comments to describe a function's inputs and outputs. 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. 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. You are still tied to blocks of 16x64 characters. Some details have changed, but the language has not.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-06-21 15:47 +0000 |
| Message-ID | <594a92eb.476520@news.eternal-september.org> |
| In reply to | #26829 |
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. > 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. > 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. >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. >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. 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
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-21 19:15 +0200 |
| Message-ID | <oie9cs$ohf$1@dont-email.me> |
| In reply to | #26903 |
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 >
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-06-21 15:50 +0000 |
| Message-ID | <594a9582.1138885@news.eternal-september.org> |
| In reply to | #26829 |
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. 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
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-21 19:16 +0200 |
| Message-ID | <oie9du$ohf$2@dont-email.me> |
| In reply to | #26904 |
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 >
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-06-21 18:00 +0000 |
| Message-ID | <594ab3c5.8886175@news.eternal-september.org> |
| In reply to | #26908 |
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
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-22 11:24 +0200 |
| Message-ID | <oig24v$r9p$1@dont-email.me> |
| In reply to | #26911 |
On 21/06/17 20:00, Stephen Pelc wrote: > 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> > It is safe on Usenet - it is the best self-correcting medium :-) I am quite happy to learn that modern mainstream Forth does not use blocks at all, and that the Forth used by the GA144 is a bit weird, old-fashioned, limited and niche compared to the Forth versions more commonly used in embedded programming. (Have you looked at the GA website and read their stuff?)
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-06-22 12:12 -0400 |
| Message-ID | <oigq38$9o3$1@dont-email.me> |
| In reply to | #26923 |
David Brown wrote on 6/22/2017 5:24 AM: > On 21/06/17 20:00, Stephen Pelc wrote: >> 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> >> > > It is safe on Usenet - it is the best self-correcting medium :-) > > I am quite happy to learn that modern mainstream Forth does not use > blocks at all, and that the Forth used by the GA144 is a bit weird, > old-fashioned, limited and niche compared to the Forth versions more > commonly used in embedded programming. It is odd that you rely so much on subjective/emotional words to describe what you like or don't like about a language. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-06-16 14:22 -0400 |
| Message-ID | <oi17eh$pgf$1@dont-email.me> |
| In reply to | #26809 |
David Brown wrote on 6/16/2017 7:21 AM: > On 15/06/17 23:46, rickman wrote: >> David Brown wrote on 6/15/2017 7:04 AM: >>> On 15/06/17 10:41, Tom Gardner wrote: >>>> On 15/06/17 09:02, David Brown wrote: >> >> I think that depends on the design. Perhaps you are familiar with the >> GA144 with 144 processors at a cost of around $0.10 per CPU. They took >> a similar route with NO dedicated I/O hardware other than a SERDES >> receiver and transmitter pair. >> >> It is expected that all I/O would be through software. Along that line >> the chip boots through one of three I/O ports, async serial, SPI serial, >> a 2 wire interface and I believe there is a 1 wire interface but I'm not >> certain. Three of the CPUs can be ganged to form a parallel port/memory >> interface, two CPUs with 18 bits of I/O and the third 4 bits. All of >> this is controlled by software. >> >> I find the device has significant limitations overall, but certainly >> with a peak execution rate of 700 MIPS there is a lot of potential. >> Much like no one focuses on the idea that using the 4 input LUT of an >> FPGA as an inverter is excessively wasteful, the GA144 with its 10 cent >> CPUs gets us out of the thinking that using a CPU as a UART is wasteful. >> >> Not trying to be negative, but I see the $2 cost of an XMOS CPU as being >> excessive and wasteful. Heck, you can buy complete MCU devices for a >> fraction of that price. > > I had a little look at the GreenArrays website for the GA144. It > appears to be pretty much a dead company. There is almost nothing > happening - no new products, no new roadmaps, no new software, no new > application notes. It is a highly specialised device, with a very > unusual development process (Forth is 50 years old, and it looks it - > and these devices use a weird variant of Forth). I think it would be a > very risky gamble to use these devices for a real project, even though > there is a lot of interesting stuff in the technology. Yeah, I don't know of any product using the GA144. I looked hard at using it in a production design where I needed to replace an EOL FPGA. Ignoring all the other issues, I wasn't sure it would meet the timing I've outlined in other posts in this thread. I needed info on the I/O timing and GA wouldn't provide it. They seemed to think I wanted to reverse engineer the transistor level design. Silly gooses. I don't know why the age of a computer language is even a factor. I don't think C is a newcomer and is the most widely used programming language in embedded devices, no? The GA144 is a stack processor and so the assembly language looks a lot like Forth which is based on a stack processor virtual machine. I'm not sure what is "weird" about it other than the fact that most programmers aren't familiar with stack programming other than Open Boot, Postscript, RPL and BibTeX. >>>> 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. >> >> The question is whether it is worth investing the time and energy into >> learning the chip if you don't focus your work in this realm. > > Certainly - working with XMOS means thinking a little differently. But > it is not /nearly/ as different as the GA144. "A little" is a *lot* larger learning curve than any other MCU I am aware of (the GA144 aside). My point is that can be worth it only if you do a lot of designs that would make use of its unique features. I'm not sure there really is a very large sweet spot given that the chips are not sold at the low end and other devices will do the same job using existing techniques and tools. >> Personally I find the FPGA approach covers a *lot* of ground that others >> don't see and the region left that is not so easy to address with either >> FPGAs or more conventional CPUs is very limited. If the XMOS isn't a >> good price fit, I most likely would just go with a small FPGA. I saw >> the XMOS has a 12 bit, 1 MSPS ADC which is nice. But again, this only >> makes its range of good fit slightly larger. > > If you have lots of experience with FPGA development, it is natural to > look to FPGAs for solutions to design problems - and that is absolutely > fine. It is impossible to jump on every different development method > and be an expert at them all - and most problems can be solved in a > variety of ways. Yes, but you don't need to know a "variety" of ways of solving problems. You only need to know ways that are highly effective for most design problems. The many misconceptions of FPGAs relegate them to situations where CPUs just can't cut the mustard. In reality they are very flexible and only limited by the lack of on chip peripherals. Microsemi adds more peripherals to their devices, but still don't compete directly with lower cost MCUs. >>>>> 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. >> >> I prefer Forth for embedded work. I believe there is a Forth >> available. > > Available for what? The XMOS? I'd be surprised. > >> I don't know if it captures any of the flavor of CSP, mostly >> because I know little about CSP. I did use Occam some time ago. Mostly >> I recall it had a lot of constraints on what the programmer was allowed >> to do. The project we were using the Transputer on programmed it all in C. >> > > Occam has its own advantages and disadvantages independent of the use of > CSP-style synchronisation and message passing. > > I have looked at Forth a few times over the years, but I have yet to see > a version that has changed for the better since I played with it as a > teenager some 30 years ago. The stuff on the GA144 website is absurd - > their "innovation" is that their IDE has colour highlighting despite > looking like a reject from the days of MSDOS 3.3. Words are apparently > only sensitive to the first "5 to 7 characters" - so "block" and > "blocks" are the same identifier. (You would think they would /know/ if > the limit were 5, 6 or 7 characters.) Everything is still designed > around punch card formats of 8 by 64 characters. You seem obsessed with your perceptions of the UI rather than utility. I don't have a problem with large fonts. Most of the designers of the system are older and have poorer eyesight (a feature I share with them). The use of color to indicate aspects of the language is pretty much the same as the color highlighting I see in nearly every modern editor. The difference is that in ColorForth the highlighting is *part* of the language as it distinguishes when commands are executed. Some commands in Forth are executed at compile time rather than being compiled. This is one of the many powerful features of Forth. ColorForth pushes further to allow some commands to be executed at edit time. I have not studied it in detail, so I can't give you details on this. I just want to explain how you are using very simplistic perceptions and expectations to "color" your impression of ColorForth without learning anything important about it. > I can appreciate that a stack machine design is ideal for a small > processor, and can give very tight code. I can appreciate that this > means a sort of Forth is the natural assembly language for the system. > I can even appreciate that the RPN syntax, the interactivity, and the > close-to-the-metal programming appeals to some people. But I cannot > understand why this cannot be done with a modern language with decent > typing, static checking, optimised compilation, structured syntax, etc. You can't understand because you have not tried to learn about Forth. I can assure you there are a number of optimizing compilers for Forth. I don't know what you are seeing that you think Forth doesn't have "structured syntax". Is this different from the control flow structures? I see Stephen Pelc responded to your posts. He is the primary author of VFX from MPE. Instead of throwing a tantrum about Forth "looking" like it is 30 years old, why not engage him and learn something? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-19 03:15 +0200 |
| Message-ID | <oi78d7$grp$1@dont-email.me> |
| In reply to | #26818 |
On 16/06/17 20:22, rickman wrote: > David Brown wrote on 6/16/2017 7:21 AM: >> On 15/06/17 23:46, rickman wrote: >>> David Brown wrote on 6/15/2017 7:04 AM: <snip> > > Yeah, I don't know of any product using the GA144. I looked hard at > using it in a production design where I needed to replace an EOL FPGA. > Ignoring all the other issues, I wasn't sure it would meet the timing > I've outlined in other posts in this thread. I needed info on the I/O > timing and GA wouldn't provide it. They seemed to think I wanted to > reverse engineer the transistor level design. Silly gooses. > > I don't know why the age of a computer language is even a factor. I > don't think C is a newcomer and is the most widely used programming > language in embedded devices, no? The age of a language itself is not important, of course. The type of features it has /are/ important. Many things in computing have changed in the last 4 decades. Features of a language that were simply impossible at that time due to limited host computing power are entirely possible today. So modern languages do far more compile-time checking and optimisation now than was possible at that time. Good languages evolve to take advantage of newer possibilities - the C of today is not the same as the pre-K&R C of that period. The Forth of today appears to me to be pretty much the same - albeit with more optimising compilers and additional libraries. > > The GA144 is a stack processor and so the assembly language looks a lot > like Forth which is based on a stack processor virtual machine. I'm not > sure what is "weird" about it other than the fact that most programmers > aren't familiar with stack programming other than Open Boot, Postscript, > RPL and BibTeX. > > Even for a stack machine, it is very limited. In some ways, the 4-bit MARC4 architecture was more powerful (it certainly had more program space). But this is all first impressions from me - I have not used the devices, and I am /very/ out of practice with Forth. >>>>> 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. >>> >>> The question is whether it is worth investing the time and energy into >>> learning the chip if you don't focus your work in this realm. >> >> Certainly - working with XMOS means thinking a little differently. But >> it is not /nearly/ as different as the GA144. > > "A little" is a *lot* larger learning curve than any other MCU I am > aware of (the GA144 aside). My point is that can be worth it only if > you do a lot of designs that would make use of its unique features. I'm > not sure there really is a very large sweet spot given that the chips > are not sold at the low end and other devices will do the same job using > existing techniques and tools. For a programmer who is completely unfamiliar with FPGA and programmable logic, the XMOS is likely to be less of a leap than moving to an FPGA. But I agree it is hard to find an application area for these devices - I have only had a couple of uses for them, and they probably were not ideal for those cases. > > >>> Personally I find the FPGA approach covers a *lot* of ground that others >>> don't see and the region left that is not so easy to address with either >>> FPGAs or more conventional CPUs is very limited. If the XMOS isn't a >>> good price fit, I most likely would just go with a small FPGA. I saw >>> the XMOS has a 12 bit, 1 MSPS ADC which is nice. But again, this only >>> makes its range of good fit slightly larger. >> >> If you have lots of experience with FPGA development, it is natural to >> look to FPGAs for solutions to design problems - and that is absolutely >> fine. It is impossible to jump on every different development method >> and be an expert at them all - and most problems can be solved in a >> variety of ways. > > Yes, but you don't need to know a "variety" of ways of solving problems. > You only need to know ways that are highly effective for most design > problems. > True. > The many misconceptions of FPGAs relegate them to situations where CPUs > just can't cut the mustard. In reality they are very flexible and only > limited by the lack of on chip peripherals. Microsemi adds more > peripherals to their devices, but still don't compete directly with > lower cost MCUs. FPGAs have their strengths and their weaknesses. There are lots of situations where they are far from ideal - but I agree that there are many misconceptions about them that might discourage people from starting to use them. > > >>>>>> 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. >>> >>> I prefer Forth for embedded work. I believe there is a Forth >>> available. >> >> Available for what? The XMOS? I'd be surprised. >> >>> I don't know if it captures any of the flavor of CSP, mostly >>> because I know little about CSP. I did use Occam some time ago. Mostly >>> I recall it had a lot of constraints on what the programmer was allowed >>> to do. The project we were using the Transputer on programmed it all >>> in C. >>> >> >> Occam has its own advantages and disadvantages independent of the use of >> CSP-style synchronisation and message passing. >> >> I have looked at Forth a few times over the years, but I have yet to see >> a version that has changed for the better since I played with it as a >> teenager some 30 years ago. The stuff on the GA144 website is absurd - >> their "innovation" is that their IDE has colour highlighting despite >> looking like a reject from the days of MSDOS 3.3. Words are apparently >> only sensitive to the first "5 to 7 characters" - so "block" and >> "blocks" are the same identifier. (You would think they would /know/ if >> the limit were 5, 6 or 7 characters.) Everything is still designed >> around punch card formats of 8 by 64 characters. > > You seem obsessed with your perceptions of the UI rather than utility. I am merely highlighting what the GA144 website seems to view as being modern innovations in the Forth toolchains. > I don't have a problem with large fonts. Most of the designers of the > system are older and have poorer eyesight (a feature I share with > them). If your eyesight is poor, use a bigger screen or a bigger or more legible font - that's fine. But it does not make sense to use that as the basis for designing your toolchain - just make the IDE configurable. > The use of color to indicate aspects of the language is pretty > much the same as the color highlighting I see in nearly every modern > editor. The difference is that in ColorForth the highlighting is *part* > of the language as it distinguishes when commands are executed. It is syntax highlighting. > Some > commands in Forth are executed at compile time rather than being > compiled. This is one of the many powerful features of Forth. You get that in other languages too. True, it is not always easy to determine what is done at compile time and what is done at run time, and the distinction may depend on optimisation flags. But really, what you are describing here is like C++ with constexpr code shown in a different colour. > ColorForth pushes further to allow some commands to be executed at edit > time. I have not studied it in detail, so I can't give you details on > this. > > I just want to explain how you are using very simplistic perceptions and > expectations to "color" your impression of ColorForth without learning > anything important about it. I've read the colorForth FAQ, such as it is. I also note that the website is dead. > > >> I can appreciate that a stack machine design is ideal for a small >> processor, and can give very tight code. I can appreciate that this >> means a sort of Forth is the natural assembly language for the system. >> I can even appreciate that the RPN syntax, the interactivity, and the >> close-to-the-metal programming appeals to some people. But I cannot >> understand why this cannot be done with a modern language with decent >> typing, static checking, optimised compilation, structured syntax, etc. > > You can't understand because you have not tried to learn about Forth. I > can assure you there are a number of optimizing compilers for Forth. I > don't know what you are seeing that you think Forth doesn't have > "structured syntax". Is this different from the control flow structures? I fully understand that there are good optimising Forth compilers and cross-compilers. But those are good /implementation/ - I am talking about the /language/. > > I see Stephen Pelc responded to your posts. He is the primary author of > VFX from MPE. Instead of throwing a tantrum about Forth "looking" like > it is 30 years old, why not engage him and learn something? > I am not "throwing a tantrum" - I /am/ engaging in discussion (including with Stephen). I am talking about how Forth appears to me. I have worked with a wide range of languages, including various functional programming languages, parallel programming languages, assembly languages, hardware design languages, high level languages, low level languages, and a little Forth long ago. I have worked through tutorials in APL and Prolog. I am not put off by strange syntaxes or having to think in a different manner. (It might put me off /using/ such languages for real work, however.) When I talk about how Forth appears to me, it is quite clear that the language has limited practicality for modern programming. And if that is /not/ the case, then it certainly has an image problem.
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web