Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #26896
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: MCU mimicking a SPI flash slave |
| Date | 2017-06-21 12:10 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <oidgfv$fa$1@dont-email.me> (permalink) |
| References | (15 earlier) <oi8j1u$p8t$2@dont-email.me> <oi8jn1$au$1@dont-email.me> <oia7bl$2oq$2@dont-email.me> <oiajrn$3ei$1@dont-email.me> <oicmbr$qh7$1@dont-email.me> |
On 21/06/17 04:44, rickman wrote: > David Brown wrote on 6/20/2017 3:49 AM: >> On 20/06/17 06:16, rickman wrote: >>> David Brown wrote on 6/19/2017 9:34 AM: >>>> On 19/06/17 15:23, rickman wrote: >>>>> David Brown wrote on 6/19/2017 8:47 AM: >>>>>> On 19/06/17 14:36, rickman wrote: >>>>>>> David Brown wrote on 6/19/2017 3:02 AM: >> <snip> >>>>>> What you get with the PSoC is a chip that can give you a couple of >>>>>> specialised custom-tuned peripherals if that is what your application >>>>>> needs, or 2 or 3 standard peripherals (timers, uarts, SPI, etc.) for >>>>>> the >>>>>> silicon, power and dollar cost of 20 standard peripherals on a >>>>>> "normal" >>>>>> microcontroller. A fixed UART or 16-bit timer is /much/ more >>>>>> efficient >>>>>> than one made from flexible digital cells and all the programmability >>>>>> needed to make them into the same type of peripheral. >>>>>> >>>>>> When you need a custom peripheral of some sort, then the >>>>>> flexibility of >>>>>> a PSoC is (presumably) great. But only then. >>>>> >>>>> So programmability in the PSOC is a niche feature while >>>>> programmability >>>>> in the XMega E is somehow a big feature? >>>> >>>> No, the small programmability of the XMega E is a nice addition to all >>>> the other peripherals. Without its timers, communications, ADCs, DMA, >>>> etc., it would be a very poor microcontroller. >>>> >>>> The small programmability of the PSoC is niche because it has its >>>> programmable blocks /instead of/ ordinary microcontroller peripherals. >>>> If they were on top of a base of solid standard peripherals, the >>>> programmable blocks would be much more interesting. >>> >>> I don't follow. What can the XMega E do that the PSOC devices can't in >>> terms of peripherals? >>> >> >> It is a good while since I have looked at PSoC devices, and my >> comparison was with the older 8-bit and 16-bit core devices (not >> entirely unreasonable, since the XMega is an 8-bit device). The key >> difference is that the PSoC can have a couple of UARTs /or/ a few PWM >> timers /or/ a couple of SPI interfaces /or/ other digital interfaces >> with customisation. The XMegaE can have a couple of UARTs /and/ some >> PWM timers /and/ a couple of SPI interfaces /and/ a bit of customer >> hardware. Now do you see the point? >> >> Now that I have looked at the PSoC website, I see that for their ARM >> Cortex devices, Cypress have figured this one out and have dedicated >> standard peripherals in additional to the programmable blocks - because, >> as I have said all along, these are /far/ more efficient. > > You are missing a lot. The original PSOC devices had a simple MCU which > was not any standard device. It had truly programmable digital blocks > and programmable analog blocks. So they were *much* more functional > than other MCUs with fixed peripherals. No, they were not much more useful. They had a few points where they were particularly good (I remember they were a good way of doing capacitive touch sensing when they were new). But you needed so many of the programmable digital blocks to do anything. If you wanted a UART, a 16-bit timer and an ADC, you had to get one of the bigger devices with more blocks - and that is for basic stuff that every other microcontroller had had for a decade. > If those fixed peripherals met > your need, then the PSOC was still better in situations where you had > modes where you would need these peripherals in this mode and those > peripherals in other operating modes. I think an example they promoted > was for making measurements in one mode and reporting the results in > another mode. Nope. It is much easier and cheaper to have dedicated peripherals for the standard tasks. /Then/ you can make use of the interesting programmable blocks to make specialised peripherals. > > The newer devices offer both 8 bit 8051 CPUs and ARM CM0, CM3 or CM4 > devices. I have not looked hard at them lately, but the 8051 based > PSOC3 has up to 24 digital blocks, > > 16 to 24 universal digital blocks (UDB), programmable to > create any number of functions: > • 8-, 16-, 24-, and 32-bit timers, counters, and PWMs > • I2C, UART, SPI, I2S, LIN 2.0 interfaces > • Cyclic redundancy check (CRC) > • Pseudo random sequence (PRS) generators > • Quadrature decoders > • Gate-level logic functions > > That totally blows away the totally wimpy XMega E programmability. The AVR in the XMega will do things like CRC and PRS in software - it is a much more powerful cpu than the 8051 of the early PSoC's. (But not nearly as fast as the Cortex-M cpus.) And since you have all these other peripherals in hardware already, you don't /need/ programmable blocks to implement them. (I am not suggesting that the XMega E has /programmability/ to compare with the PSoCs' - I have never suggested such a thing. I /am/ suggesting that they are more /useful/ than the early PSoC's because those PSoC's were far too limited.) Now the PSoC's have enough blocks to be useful - they did not originally. And the newer devices (Cortex based) have finally got things right - they have a proper cpu rather than a core that was outdated 30 years ago, and they have a full selection of normal fixed peripherals. The programmable blocks are an /addition/ to a solid microcontroller base, rather than instead of it. You see this process again and again. When the PSoC came out, the marketing was all about claims like yours - you don't need fixed hardware peripherals because you can use the flexible programmable blocks. Now modern PSoC's have lots of fixed hardware peripherals as well. When the XMOS came out, marketing talked about how their deterministic SMT and I/O blocks meant that you could make Ethernet and USB in software. Now you can buy XMOS chips with an Ethernet MAC or a USB interface. When FPGAs were younger, you apparently did not need a hard processor because soft processors could do such a good job. Now FPGAs with hard processor cores are much more common - even when the speed (such as SmartFusion2's 166 MHz Cortex-M3) would be achievable in a soft processor. And guess what? These devices come with a range of dedicated fixed hardware peripherals such as CAN controllers, I2C, SPI, Timers, etc. And that's on an /FPGA/ - making a timer block on an FPGA is about as simple a task for programmable logic as you can get. Again and again it is shown - a selection of dedicated hardware standard peripherals is important, and vastly more efficient than doing everything in programmable blocks, programmable logic, bit banging, etc. > > The Cypress web site has always been a PITA to find the info you want, > but in searching this I see they have come out with a very wide range of > new devices including other custom CPUs including 128 MHz RISC as well > as a line of ARM CR4 and 240 MHz CR5 devices. These seem to be more > conventional devices with no mention of the programmable hardware, > analog or digital. But then that is not surprising. The programmable > hardware allows a very cost competitive product. As mentioned in the > Wikipedia article, they use PSOC in toothbrushes and Adidas sneakers. > They have to be cheap to be used in sneakers. The CR5 devices are much > higher cost parts. > <snip> >>> Is an Ethernet interface an adequate indication of functionality? I >>> think that is more than "simple" operations, no? >>> >> >> OK, I admit to being impressed by that possibility. It is 10 Mb, needs >> external ram, and has little additional possibilities beyond simple UDP >> telegrams, but I am still impressed. >> >> (For comparison, the XMOS can do a software 100 Mb NIC in about half of >> a cpu, letting you run lwip and network software in the other half. But >> if you really want Ethernet on an XMOS device, you are better off with >> the chips that have a dedicated hardware Ethernet interface.) > > I assume it can do a NIC in software because of the hardware assist for > the I/O? Still, that's pretty good. > Yes, you basically have a SERDES system for each of the I/O pins, and a whole array of hardware timers that can trigger the transfers.
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