Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #26818
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: MCU mimicking a SPI flash slave |
| Date | 2017-06-16 14:22 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <oi17eh$pgf$1@dont-email.me> (permalink) |
| References | (3 earlier) <ohtena$7s5$1@dont-email.me> <gLr0B.74079$O06.57510@fx43.am4> <ohtpct$91f$1@dont-email.me> <ohuv1i$nlc$1@dont-email.me> <oi0eo5$2fr$1@dont-email.me> |
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
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web