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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-06-20 22:44 -0400 |
| Message-ID | <oicmbr$qh7$1@dont-email.me> |
| In reply to | #26866 |
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. 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. 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 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. >>>> I think you may have missed some of the PSOC devices, like 90%. One >>>> subfamily of about four devices have programmable peripherals. The >>>> others have programmable logic and analog blocks. Much more powerful. >>>> >>>> >>>>>>> Again, I don't know the numbers here. XMOS has been running for >>>>>>> quite a >>>>>>> few years, with regular new products and new versions of their >>>>>>> tools, so >>>>>>> they seem to be doing okay. >>>>>> >>>>>> The issue I have isn't that they aren't stable, but that they don't >>>>>> seem >>>>>> to be able to produce a device price competitive with the lower end >>>>>> device. For me that make FPGAs a more viable solution economically for >>>>>> the large majority of designs. Combine that with the large learning >>>>>> curve and we end up with many users never taking the time to become >>>>>> proficient with them. If they get priced down to the $1 range, they >>>>>> will get a *lot* more users and sales. >>>>>> >>>>> >>>>> I agree with you - and as I say, I don't really know why they can't >>>>> make >>>>> (or sell) the chips for a lower price. >>>>> >>>>>> Likewise, if they did a shrink to make the GA144 more cost >>>>>> competitive a >>>>>> lot more users would be interested in learning how to program the >>>>>> device. But it would still be a very ugly duckling requiring a whole >>>>>> new approach to complex systems. The inability to draw on the huge >>>>>> base >>>>>> of established software make the GA144 a non-starter for many apps. >>>>>> >>>>> >>>>> Nah, the GA144 would not be popular even if they /paid/ people to use >>>>> them. Less unpopular, perhaps, but not popular. >>>> >>>> That much processing power in a very low cost device would become useful >>>> in many apps. It is odd and difficult to learn, but it is not without >>>> functionality and application. >>>> >>> >>> Well, I disagree. I think the individual cpus are too weak to be >>> practical. It does not really matter if they can do simple operations >>> at 700 MHz if they can't do more than a few dozen lines of code. There >>> are not nearly enough processors on the chip, a far, far too little >>> communication channels between nodes, to be useful despite the small >>> memory size. >> >> 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. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-21 12:10 +0200 |
| Message-ID | <oidgfv$fa$1@dont-email.me> |
| In reply to | #26893 |
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.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-06-21 12:40 -0400 |
| Message-ID | <oie7at$h6f$1@dont-email.me> |
| In reply to | #26896 |
David Brown wrote on 6/21/2017 6:10 AM: > 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. I'm calling applesauce on this one. Again, you are talking in vague terms that mean little and trying to make comparisons without specifics. The PSOC 1 parts were designed for *very* low cost. They had two advantages over other devices. They could use the same die for a wide range of peripheral combinations making the part cost lower from higher production volumes. The other advantage is the peripherals could be changed on the fly being used for one set of peripherals in one mode of operations and another set of peripherals in another mode, again keeping the part cost low because you can use the smallest possible part. If you think there are other parts that can reach the same price point with the same capabilities, please point them out. Apple has used the PSOC 1 in their iPod Nano as well as other companies using them in high volume low margin applications where performance vs. cost is critical. Your criticism regarding the peripherals just doesn't hold water. >> 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 fact that you said "Nope" doesn't make it true. Dedicated peripherals are just that, dedicated. They can't be anything else. If you aren't using them they are wasted silicon. They tend to be added in proportion. Chips with more UARTs are likely to have more I2C and SPI as well, often wasted. PSOC 1 devices sold well enough to markets that needed to save every last penny. The only real issue with PSOC 1 was the design software. I scheduled a live remote class once which turned out to be me and the instructors. lol They were willing to teach the tools one on one in the early days because they hadn't gotten things working well enough to convey the knowledge any other way. That's why they revamped the line to PSOC 3 and 5 and now all the others with all new tools. Personally I don't care for the tools because they isolate the designer from what is going on, but they work at least. >> 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.) The "early PSOCs" didn't use an 8051, it was a custom M8C core. I don't recall the speed relative to other 8 bitters, but it runs at 24 MHz with a built in multiplier. To say the AVR blows it away I expect is rather an exaggeration. > 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 keep talking about devices purely from your perspective. The market says your criticisms are wrong. The original PSOC devices are still sold and are very cost effective. They offer a range of combinations that are much, much wider becoming optimal for a much wider range of applications. > 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. None of this makes the XMega E a useful part. Programmability is highly useful allowing devices to reach an optimum price point. The XMega E would have only a very, very tiny niche. >> 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. I think we are starting to see why the XMOS devices are so expensive, very extensive dedicated hardware. Too bad they don't have a few programmable digital blocks that can actually do something useful. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-06-21 18:19 +0100 |
| Message-ID | <mUx2B.4296$C96.3462@fx01.am4> |
| In reply to | #26905 |
On 21/06/17 17:40, rickman wrote:
> David Brown wrote on 6/21/2017 6:10 AM:
>> Yes, you basically have a SERDES system for each of the I/O pins, and a
>> whole array of hardware timers that can trigger the transfers.
>
> I think we are starting to see why the XMOS devices are so expensive, very
> extensive dedicated hardware. Too bad they don't have a few programmable
> digital blocks that can actually do something useful.
The SERDES and timers are very simple, so I'm unconvinced
they are the reason for any perceived expense.
Have a look in the "ports" reference I previously gave you
https://www.xmos.com/published/xs1-ports-introduction?version=latest
You will see that the
- SERDES is only a shift register plus buffer register,
- each /port/ timer is only 16 bits and is constantly
ticking, plus a register and comparator to enable
timed i/o
- there's a pinseq/pinsneq register and comparator
Scarcely enough to dominate the chip area, especially when
you consider the memory and xCONNECT switch fabric.
Without knowledge, my guess is that the switch fabric will
have a far larger area than the port logic, just as in FPGAs
the interconnects are far larger than the IO cells.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-06-21 14:34 -0400 |
| Message-ID | <oiee0s$8p9$1@dont-email.me> |
| In reply to | #26909 |
Tom Gardner wrote on 6/21/2017 1:19 PM: > On 21/06/17 17:40, rickman wrote: >> David Brown wrote on 6/21/2017 6:10 AM: >>> Yes, you basically have a SERDES system for each of the I/O pins, and a >>> whole array of hardware timers that can trigger the transfers. >> >> I think we are starting to see why the XMOS devices are so expensive, very >> extensive dedicated hardware. Too bad they don't have a few programmable >> digital blocks that can actually do something useful. > > The SERDES and timers are very simple, so I'm unconvinced > they are the reason for any perceived expense. > > Have a look in the "ports" reference I previously gave you > https://www.xmos.com/published/xs1-ports-introduction?version=latest > You will see that the > - SERDES is only a shift register plus buffer register, > - each /port/ timer is only 16 bits and is constantly > ticking, plus a register and comparator to enable > timed i/o > - there's a pinseq/pinsneq register and comparator > > Scarcely enough to dominate the chip area, especially when > you consider the memory and xCONNECT switch fabric. So there is the equivalent of three 16 bit counter/timer/comparator/shifter/whatever for *each* port pin? That may not dominate the chip area, but it is going to add up fast. I'll bet it is larger than a set of fixed peripherals in low end MCUs that can be sold for $1. Just how much logic do you think is in an SPI port? > Without knowledge, my guess is that the switch fabric will > have a far larger area than the port logic, just as in FPGAs > the interconnects are far larger than the IO cells. Xilinx used to say they sell you the routing and give the logic away for free. What's your point? How do FPGAs come into the cost basis of the XMOS? The real issue is that they just can't compete in the low price end of MCUs where I feel they would be most useful. But they have their niche and I guess they aren't going anywhere soon. I wonder what it would take for the XMOS concept to be scaled up to cover more at the high end? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-06-21 21:41 +0100 |
| Message-ID | <lSA2B.12416$hc7.5082@fx41.am4> |
| In reply to | #26912 |
On 21/06/17 19:34, rickman wrote: > Tom Gardner wrote on 6/21/2017 1:19 PM: >> On 21/06/17 17:40, rickman wrote: >>> David Brown wrote on 6/21/2017 6:10 AM: >>>> Yes, you basically have a SERDES system for each of the I/O pins, and a >>>> whole array of hardware timers that can trigger the transfers. >>> >>> I think we are starting to see why the XMOS devices are so expensive, very >>> extensive dedicated hardware. Too bad they don't have a few programmable >>> digital blocks that can actually do something useful. >> >> The SERDES and timers are very simple, so I'm unconvinced >> they are the reason for any perceived expense. >> >> Have a look in the "ports" reference I previously gave you >> https://www.xmos.com/published/xs1-ports-introduction?version=latest >> You will see that the >> - SERDES is only a shift register plus buffer register, >> - each /port/ timer is only 16 bits and is constantly >> ticking, plus a register and comparator to enable >> timed i/o >> - there's a pinseq/pinsneq register and comparator >> >> Scarcely enough to dominate the chip area, especially when >> you consider the memory and xCONNECT switch fabric. > > So there is the equivalent of three 16 bit > counter/timer/comparator/shifter/whatever for *each* port pin? That may not > dominate the chip area, but it is going to add up fast. I'll bet it is larger > than a set of fixed peripherals in low end MCUs that can be sold for $1. Just > how much logic do you think is in an SPI port? No. Read the reference supplied; the relevant bits are only 9 pages - and are in clear and simple English. >> Without knowledge, my guess is that the switch fabric will >> have a far larger area than the port logic, just as in FPGAs >> the interconnects are far larger than the IO cells. > > Xilinx used to say they sell you the routing and give the logic away for free. > What's your point? How do FPGAs come into the cost basis of the XMOS? It is the same principals and cost drivers at work. Your comment indicates you/Xilinx see the similarity. > The real issue is that they just can't compete in the low price end of MCUs > where I feel they would be most useful. ... to you. > But they have their niche and I guess > they aren't going anywhere soon. I wonder what it would take for the XMOS > concept to be scaled up to cover more at the high end? A key decision for /all/ businesses is where /not/ to compete.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-06-21 17:14 -0400 |
| Message-ID | <oience$art$1@dont-email.me> |
| In reply to | #26915 |
Tom Gardner wrote on 6/21/2017 4:41 PM: > On 21/06/17 19:34, rickman wrote: >> Tom Gardner wrote on 6/21/2017 1:19 PM: >>> On 21/06/17 17:40, rickman wrote: >>>> David Brown wrote on 6/21/2017 6:10 AM: >>>>> Yes, you basically have a SERDES system for each of the I/O pins, and a >>>>> whole array of hardware timers that can trigger the transfers. >>>> >>>> I think we are starting to see why the XMOS devices are so expensive, very >>>> extensive dedicated hardware. Too bad they don't have a few programmable >>>> digital blocks that can actually do something useful. >>> >>> The SERDES and timers are very simple, so I'm unconvinced >>> they are the reason for any perceived expense. >>> >>> Have a look in the "ports" reference I previously gave you >>> https://www.xmos.com/published/xs1-ports-introduction?version=latest >>> You will see that the >>> - SERDES is only a shift register plus buffer register, >>> - each /port/ timer is only 16 bits and is constantly >>> ticking, plus a register and comparator to enable >>> timed i/o >>> - there's a pinseq/pinsneq register and comparator >>> >>> Scarcely enough to dominate the chip area, especially when >>> you consider the memory and xCONNECT switch fabric. >> >> So there is the equivalent of three 16 bit >> counter/timer/comparator/shifter/whatever for *each* port pin? That may not >> dominate the chip area, but it is going to add up fast. I'll bet it is >> larger >> than a set of fixed peripherals in low end MCUs that can be sold for $1. >> Just >> how much logic do you think is in an SPI port? > > No. > > Read the reference supplied; the relevant bits are > only 9 pages - and are in clear and simple English. So what you wrote is not correct? >>> Without knowledge, my guess is that the switch fabric will >>> have a far larger area than the port logic, just as in FPGAs >>> the interconnects are far larger than the IO cells. >> >> Xilinx used to say they sell you the routing and give the logic away for >> free. >> What's your point? How do FPGAs come into the cost basis of the XMOS? > > It is the same principals and cost drivers at work. Your > comment indicates you/Xilinx see the similarity. This gets tiring. I don't know what "comment" of mine you mean and I *don't* see the similarity. The interconnect in an FPGA is at least an order of magnitude more complex than the I/O routing in an MCU. >> The real issue is that they just can't compete in the low price end of MCUs >> where I feel they would be most useful. > > .... to you. Ok, I'll spell it out. At the low end the multiple processors can implement separate tasks on separate processors. This works great simplifying the otherwise complex issues in emulating parallel processing on a sequential processor. Fine. A more complex set of tasks will typically require a more powerful processor although complexity is not synonymous with performance requirements. Once the XMOS device is fully utilized with one process per processor additional tasks require adding back in the complexity of emulating parallel processing on a single processor. So the primary advantage of the XMOS processor end once the tasking is complex enough, i.e. high end. So clearly the XMOS is less useful at the high end and more useful at the low end. If they make some adjustments to the design/architecture to allow low *cost* units to be sold, that would only open more markets for them. One nice thing about the low end is that while you don't make tons of money on even a fairly large number of units sold, it pays to keep the doors open and the machinery running. Then they can pursue other products that have different economics and may be less stable financially, good one year and not so good the next. >> But they have their niche and I guess >> they aren't going anywhere soon. I wonder what it would take for the XMOS >> concept to be scaled up to cover more at the high end? > > A key decision for /all/ businesses is where /not/ to compete. So a processor company shouldn't try to compete in the processor business. Good thing ARM didn't try that approach. They definitely started at the small end and worked upward. I understand they are making significant inroads to servers these days. I am feeling that this horse has been flogged quite enough. It's not going to get much deader and I don't think we are expressing much in the way of new thoughts. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | edward.ming.lee@gmail.com |
|---|---|
| Date | 2017-06-21 13:54 -0700 |
| Message-ID | <46da8b3d-0b38-4175-8b03-e2e063d39147@googlegroups.com> |
| In reply to | #26912 |
> Just how much logic do you think is in an SPI port? I added the command port to my test code. In a real spi device, there should only be one serial chain, instead of three in mine. But i don't need to follow the standard spec. However, resource ultizations should be similar. Using elements: Max II: 67 / 240 ( 28 % ) Max 10: 154 / 8,064 ( 2 % ) I am using 60 cents of a $2 Max II, since i don't need anything else. Realistically, around 20 cents of a $10 Max 10. ---------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity ram is port( P7: in std_logic; -- preserve upper 9 bits for next shift P6: in std_logic; -- preserve upper 10 bits for next shift P5: in std_logic; -- preserve upper 11 bits for next shift ACLK, clear, pass : in std_logic; -- Address serial clock ASI: in std_logic; -- Address serial in ASO: buffer std_logic; -- Address serial out A: buffer std_logic_vector(16 downto 0); -- Address register AA: in std_logic_vector(16 downto 0); -- Address parallel in DCLK: in std_logic; -- Data serial clock DSI: in std_logic; -- Data serial in DSO: buffer std_logic; -- Data serial out D: buffer std_logic_vector(7 downto 0); -- Data register DD: in std_logic_vector(7 downto 0); -- Data parallel in CCLK: in std_logic; -- Command serial clock CSI: in std_logic; -- Command serial in CSO: buffer std_logic; -- Command serial out C: buffer std_logic_vector(7 downto 0); -- Command register CC: in std_logic_vector(7 downto 0) -- Command parallel in ); end ram; architecture arch of ram is begin process (ACLK, clear) begin if clear = '1' then A <= "00000000000000000"; elsif (P7 = '1') then A(9 downto 0) <= A(16 downto 7); elsif (P6 = '1') then A(10 downto 0) <= A(16 downto 6); elsif (P5 = '1') then A(11 downto 0) <= A(16 downto 5); elsif (pass = '1') then A <= AA; elsif (ACLK'event and ACLK='1') then ASO <= A(16); A(16 downto 1) <= A(15 downto 0); A(0) <= ASI; end if; end process; process (DCLK) begin if (pass = '1') then D <= DD; elsif (DCLK'event and DCLK='1') then DSO <= D(7); D(7 downto 1) <= D(6 downto 0); D(0) <= DSI; end if; end process; process (CCLK) begin if (pass = '1') then C <= CC; elsif (CCLK'event and CCLK='1') then CSO <= C(7); C(7 downto 1) <= C(6 downto 0); C(0) <= CSI; end if; end process; end arch;
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-06-15 23:33 +0100 |
| Message-ID | <zWD0B.48374$y7.37664@fx15.am4> |
| In reply to | #26792 |
On 15/06/17 21:52, rickman wrote: > Tom Gardner wrote on 6/15/2017 1:01 PM: >> On 15/06/17 17:13, rickman wrote: >>> Tom Gardner wrote on 6/15/2017 3:01 AM: >>>> On 15/06/17 02:54, rickman wrote: >>>>> John Speth wrote on 6/14/2017 1:44 PM: >>>>>> Hi folks- >>>>>> >>>>>> I'm hoping to tap into your various experiences to see if what I'm >>>>>> thinking >>>>>> is practical. >>>>>> >>>>>> Our customer has a device into which a Datakey is plugged to extract data >>>>>> stored in the device. The Datakey is a really just a trade name for a SPI >>>>>> flash with ergonomic features that resemble a real key (see datakey.com). >>>>>> Our customer would like to replace the Datakey with a new design that will >>>>>> transmit the data wirelessly instead of storing it to the Datakey SPI >>>>>> flash. >>>>>> >>>>>> We're proposing a design based on an MCU which will appear as a SPI slave >>>>>> flash device, store the data pumped to it from the customer's device, and >>>>>> forward it wirelessly. I'm wondering if it's practical to accomplish it. >>>>>> The firmware would have to be totally responsive temporally and in data >>>>>> content. That sounds like a tough hill to climb that requires getting the >>>>>> interface just right, nearly perfect. I see a lot of pitfalls that could >>>>>> make the effort a dead end. >>>>>> >>>>>> Does anybody have any success or failure stories to relate that would help >>>>>> us gauge the feasibility of the proposed design? >>>>> >>>>> I have no experience in building such a product, but why not use an actual >>>>> SPI >>>>> data flash as the intermediate storage while the MCU monitors the action >>>>> and >>>>> forwards the data? This would require periods when the MCU could read the >>>>> data >>>>> flash. Is that possible or practical? >>>>> >>>>> I had a design that needed a 30 MHz SPI like interface (not entirely >>>>> compatible >>>>> though) which was designed to read/write registers. I considered using a >>>>> fast >>>>> CPU to emulate the interface in software, but it just couldn't meet the >>>>> timing. >>>>> Even with a 700 MIPS processor I wasn't sure it could receive the >>>>> command to >>>>> read a register and then get the data onto the output fast enough. I'm >>>>> not sure >>>>> of the timing of the SPI interface you have, but it will likely be hard to >>>>> emulate the SPI in software. >>>> >>>> That sounds easy for the XMOS processors: >>>> - multicore (up to 32 100MIPS cores) >>>> - FPGA-like i/o, e.g. SERDES, buffers, programmable >>>> clocks to 250Mb/s, separate timer for each port >>>> - i/o timing changes can be specified/measured in >>>> software with 4ns resolution >>>> - guaranteed latencies <100ns >>>> - *excellent* programming model based on CSP >>>> (summary: of "Occam in C") >>>> - Eclipse-based dev environment >>> >>> Any yet the XMOS can't run fast enough to return a result in the time >>> available. What a pity, all dressed up an nowhere to go. >> >> You'll have to explain that, because I don't understand >> what you are referring to. > > Maybe I don't understand the speed of the XMOS. A 30000ft opverview: http://www.xmos.com/published/xcore-architecture-flyer?version=latest > Nothing you write above says to > me it is any faster than the 700 MIPS processor I considered. Nothing written > above would allow it to perform the task any differently than the bit banging > approach I initially considered. What are the *guaranteed* timings and latencies? Include all possible disturbances due to cache/TLB misses, branch predictions and interrupts. Include simultaneous USB comms to a host PC. N.B. "guaranteed" /precludes/ measurements to see what is happening. "Guaranteed" requires accurate /prediction/ *before* the code executes. > So what are you confused about? > > Maybe you don't understand the problem. A bit serial data port (two bits wide > actually, but that is not relevant) provides data, address and a two bit command > word serially. The last bit of the command work is indicated by a "command" > signal going high during that bit. Data is clocked in on the rising edge of the > clock. When the command word is a read, the read data is provided serially > starting on the subsequent falling edge. This provides 15 ns from rising edge > to falling edge. It is possible to prefetch the read data based on the shifted > address on each rising edge until the command signal is asserted. This helps > with timing of the memory fetch, but still, that data has to be presented to the > serial port output in 15 ns and updated every 30 ns. > > I'd like to see code that will make this work. Or maybe you weren't addressing > my previous application? For the OP, can the XMOS emulate a 30 Mbps SPI port? Each i/o pin can be clocked at up to 250Mb/s. That clock can come from an internal clock (up to 500MHz) or an external pin. The latter sounds relevant for your case. (Strobed and master/slave interfaces are also directly supported in hardware and software). Each I/O pin has SERDES registers, so the data rate processed by a core can be reduced by a factor of 32. So yes, it does look like a /small/ fraction of an xCORE device could very comfortably support that speed. >>>> Currently I'm managing to count transitions in >>>> software on two 50Mb/s inputs, plus do >>>> simultaneous USB comms to a host computer. >>> >>> Can you output a result before the next input transition? >> >> Yes and no. >> >> Yes: the output (to a host processor and/or LCD) >> proceeds in parallel with the next capture phase. > > I'm referring to bit I/O using the same 50 MHz clock. > > >> No: in the current incarnation there is a short gap >> between capture phases as the results are passed >> from one core to another and the next capture phase >> is started. While it isn't important in my application, >> I may be able to remove that limitation in future >> incarnations. > > That's a lot more than a "short" gap in the context of a fast clock. Sigh. My application only stops for a few microseconds when it is convenient for my application, i.e. once every 1 or 10seconds at the end of a measurement cycle. At other times it chunters away continuously at full rate without interruption - as guaranteed by design. >>>> Processors plus £10 devkit available from Farnell >>>> and DigiKey. >>> >>> Not a very good processor to use in cost conscious applications. The lowest >>> price at Digikey is $3 at qty 1000. They can't make a part in the sub-dollar >>> range? >> >> Don't presume everybody has your constraints. > > I don't, but not everyone has *your* constraints. If a processor can't be sold > in a low cost product, it cuts off the largest volume parts of the market > including the app I am looking at presently. I don't think there are any surprises there. But, again, your (current) requirement is only one perspective.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-06-15 23:12 -0400 |
| Message-ID | <ohvi3e$gm6$1@dont-email.me> |
| In reply to | #26800 |
Tom Gardner wrote on 6/15/2017 6:33 PM: > On 15/06/17 21:52, rickman wrote: >> Tom Gardner wrote on 6/15/2017 1:01 PM: >>> On 15/06/17 17:13, rickman wrote: >>>> Tom Gardner wrote on 6/15/2017 3:01 AM: >>>>> >>>>> That sounds easy for the XMOS processors: >>>>> - multicore (up to 32 100MIPS cores) >>>>> - FPGA-like i/o, e.g. SERDES, buffers, programmable >>>>> clocks to 250Mb/s, separate timer for each port >>>>> - i/o timing changes can be specified/measured in >>>>> software with 4ns resolution >>>>> - guaranteed latencies <100ns >>>>> - *excellent* programming model based on CSP >>>>> (summary: of "Occam in C") >>>>> - Eclipse-based dev environment >>>> >>>> Any yet the XMOS can't run fast enough to return a result in the time >>>> available. What a pity, all dressed up an nowhere to go. >>> >>> You'll have to explain that, because I don't understand >>> what you are referring to. >> >> Maybe I don't understand the speed of the XMOS. > > A 30000ft opverview: > http://www.xmos.com/published/xcore-architecture-flyer?version=latest > >> Nothing you write above says to >> me it is any faster than the 700 MIPS processor I considered. Nothing written >> above would allow it to perform the task any differently than the bit banging >> approach I initially considered. > > What are the *guaranteed* timings and latencies? > Include all possible disturbances due to cache/TLB > misses, branch predictions and interrupts. > Include simultaneous USB comms to a host PC. > > N.B. "guaranteed" /precludes/ measurements to see > what is happening. "Guaranteed" requires accurate > /prediction/ *before* the code executes. I know this is clear to you, but I'm not sure what processor you are talking about. >> So what are you confused about? >> >> Maybe you don't understand the problem. A bit serial data port (two bits >> wide >> actually, but that is not relevant) provides data, address and a two bit >> command >> word serially. The last bit of the command work is indicated by a "command" >> signal going high during that bit. Data is clocked in on the rising edge >> of the >> clock. When the command word is a read, the read data is provided serially >> starting on the subsequent falling edge. This provides 15 ns from rising >> edge >> to falling edge. It is possible to prefetch the read data based on the >> shifted >> address on each rising edge until the command signal is asserted. This helps >> with timing of the memory fetch, but still, that data has to be presented >> to the >> serial port output in 15 ns and updated every 30 ns. >> >> I'd like to see code that will make this work. Or maybe you weren't >> addressing >> my previous application? For the OP, can the XMOS emulate a 30 Mbps SPI >> port? > > Each i/o pin can be clocked at up to 250Mb/s. > That clock can come from an internal clock > (up to 500MHz) or an external pin. The latter > sounds relevant for your case. (Strobed and > master/slave interfaces are also directly > supported in hardware and software). > > Each I/O pin has SERDES registers, so the data > rate processed by a core can be reduced by a factor > of 32. > > So yes, it does look like a /small/ fraction of an xCORE > device could very comfortably support that speed. You still are not addressing the issue at hand. You are talking about raw I/O speeds and the problem is not about raw I/O speeds. The issue is interactivity. Stimulus followed by response in very short order. I have seen nothing to indicate the XMOS will work for this problem. That's why I asked for a code snippet. >>>>> Currently I'm managing to count transitions in >>>>> software on two 50Mb/s inputs, plus do >>>>> simultaneous USB comms to a host computer. >>>> >>>> Can you output a result before the next input transition? >>> >>> Yes and no. >>> >>> Yes: the output (to a host processor and/or LCD) >>> proceeds in parallel with the next capture phase. >> >> I'm referring to bit I/O using the same 50 MHz clock. >> >> >>> No: in the current incarnation there is a short gap >>> between capture phases as the results are passed >>> from one core to another and the next capture phase >>> is started. While it isn't important in my application, >>> I may be able to remove that limitation in future >>> incarnations. >> >> That's a lot more than a "short" gap in the context of a fast clock. > > Sigh. > > My application only stops for a few microseconds when > it is convenient for my application, i.e. once every > 1 or 10seconds at the end of a measurement cycle. > > At other times it chunters away continuously at full > rate without interruption - as guaranteed by design. Fine, but the fact that it will work for your needs does not mean it will work for mine. Again the requirement is to read the inputs looking for a command strobe, on finding that retrieve the appropriate word from memory and outputting it. The clock cycle is 30 ns and the total I/O time from command strobe read on the positive edge of the clock to the input of the device monitoring the output pin (with a 5 ns setup time) 15 ns. You haven't even addressed the output delays in the I/O pins. >>>>> Processors plus £10 devkit available from Farnell >>>>> and DigiKey. >>>> >>>> Not a very good processor to use in cost conscious applications. The >>>> lowest >>>> price at Digikey is $3 at qty 1000. They can't make a part in the >>>> sub-dollar >>>> range? >>> >>> Don't presume everybody has your constraints. >> >> I don't, but not everyone has *your* constraints. If a processor can't be >> sold >> in a low cost product, it cuts off the largest volume parts of the market >> including the app I am looking at presently. > > I don't think there are any surprises there. > > But, again, your (current) requirement is only one > perspective. I can't argue with that. But that is the need I have and low cost is not a very minor requirement. Processors are sold at much higher volumes for the low cost products. The higher cost, lower volume products often can be built with a wide range of solutions, again the selected device is often chosen as the one that meets the requirements at the lowest price. So shrugging off the cost issue of *my* current need is rather disingenuous. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-06-16 07:05 +0100 |
| Message-ID | <5zK0B.74636$%h1.49112@fx11.am4> |
| In reply to | #26801 |
On 16/06/17 04:12, rickman wrote: > Tom Gardner wrote on 6/15/2017 6:33 PM: >> On 15/06/17 21:52, rickman wrote: >>> Tom Gardner wrote on 6/15/2017 1:01 PM: >>>> On 15/06/17 17:13, rickman wrote: >>>>> Tom Gardner wrote on 6/15/2017 3:01 AM: >>>>>> >>>>>> That sounds easy for the XMOS processors: >>>>>> - multicore (up to 32 100MIPS cores) >>>>>> - FPGA-like i/o, e.g. SERDES, buffers, programmable >>>>>> clocks to 250Mb/s, separate timer for each port >>>>>> - i/o timing changes can be specified/measured in >>>>>> software with 4ns resolution >>>>>> - guaranteed latencies <100ns >>>>>> - *excellent* programming model based on CSP >>>>>> (summary: of "Occam in C") >>>>>> - Eclipse-based dev environment >>>>> >>>>> Any yet the XMOS can't run fast enough to return a result in the time >>>>> available. What a pity, all dressed up an nowhere to go. >>>> >>>> You'll have to explain that, because I don't understand >>>> what you are referring to. >>> >>> Maybe I don't understand the speed of the XMOS. >> >> A 30000ft opverview: >> http://www.xmos.com/published/xcore-architecture-flyer?version=latest >> >>> Nothing you write above says to >>> me it is any faster than the 700 MIPS processor I considered. Nothing written >>> above would allow it to perform the task any differently than the bit banging >>> approach I initially considered. >> >> What are the *guaranteed* timings and latencies? >> Include all possible disturbances due to cache/TLB >> misses, branch predictions and interrupts. >> Include simultaneous USB comms to a host PC. >> >> N.B. "guaranteed" /precludes/ measurements to see >> what is happening. "Guaranteed" requires accurate >> /prediction/ *before* the code executes. > > I know this is clear to you, but I'm not sure what processor you are talking about. > > >>> So what are you confused about? >>> >>> Maybe you don't understand the problem. A bit serial data port (two bits >>> wide >>> actually, but that is not relevant) provides data, address and a two bit >>> command >>> word serially. The last bit of the command work is indicated by a "command" >>> signal going high during that bit. Data is clocked in on the rising edge >>> of the >>> clock. When the command word is a read, the read data is provided serially >>> starting on the subsequent falling edge. This provides 15 ns from rising >>> edge >>> to falling edge. It is possible to prefetch the read data based on the >>> shifted >>> address on each rising edge until the command signal is asserted. This helps >>> with timing of the memory fetch, but still, that data has to be presented >>> to the >>> serial port output in 15 ns and updated every 30 ns. >>> >>> I'd like to see code that will make this work. Or maybe you weren't >>> addressing >>> my previous application? For the OP, can the XMOS emulate a 30 Mbps SPI >>> port? >> >> Each i/o pin can be clocked at up to 250Mb/s. >> That clock can come from an internal clock >> (up to 500MHz) or an external pin. The latter >> sounds relevant for your case. (Strobed and >> master/slave interfaces are also directly >> supported in hardware and software). >> >> Each I/O pin has SERDES registers, so the data >> rate processed by a core can be reduced by a factor >> of 32. >> >> So yes, it does look like a /small/ fraction of an xCORE >> device could very comfortably support that speed. > > You still are not addressing the issue at hand. You are talking about raw I/O > speeds and the problem is not about raw I/O speeds. The issue is > interactivity. Stimulus followed by response in very short order. I have seen > nothing to indicate the XMOS will work for this problem. That's why I asked for > a code snippet. There are many interesting snippets, plus a description of how they fit together in the /very/ lucid xC tutuorial. https://www.xmos.com/support/tools/programming?component=17653 You might care to look for the "pinseq/pinsneq" attribute of i/o ports, in conjunction with the ways of combining i/o pins, and port timers. For more details of some i/o structures, see https://www.xmos.com/published/xs1-ports-introduction?version=latest >>>>>> Currently I'm managing to count transitions in >>>>>> software on two 50Mb/s inputs, plus do >>>>>> simultaneous USB comms to a host computer. >>>>> >>>>> Can you output a result before the next input transition? >>>> >>>> Yes and no. >>>> >>>> Yes: the output (to a host processor and/or LCD) >>>> proceeds in parallel with the next capture phase. >>> >>> I'm referring to bit I/O using the same 50 MHz clock. >>> >>> >>>> No: in the current incarnation there is a short gap >>>> between capture phases as the results are passed >>>> from one core to another and the next capture phase >>>> is started. While it isn't important in my application, >>>> I may be able to remove that limitation in future >>>> incarnations. >>> >>> That's a lot more than a "short" gap in the context of a fast clock. >> >> Sigh. >> >> My application only stops for a few microseconds when >> it is convenient for my application, i.e. once every >> 1 or 10seconds at the end of a measurement cycle. >> >> At other times it chunters away continuously at full >> rate without interruption - as guaranteed by design. > > Fine, but the fact that it will work for your needs does not mean it will work > for mine. Again the requirement is to read the inputs looking for a command > strobe, on finding that retrieve the appropriate word from memory and outputting > it. The clock cycle is 30 ns and the total I/O time from command strobe read on > the positive edge of the clock to the input of the device monitoring the output > pin (with a 5 ns setup time) 15 ns. You haven't even addressed the output > delays in the I/O pins. > > >>>>>> Processors plus £10 devkit available from Farnell >>>>>> and DigiKey. >>>>> >>>>> Not a very good processor to use in cost conscious applications. The >>>>> lowest >>>>> price at Digikey is $3 at qty 1000. They can't make a part in the >>>>> sub-dollar >>>>> range? >>>> >>>> Don't presume everybody has your constraints. >>> >>> I don't, but not everyone has *your* constraints. If a processor can't be >>> sold >>> in a low cost product, it cuts off the largest volume parts of the market >>> including the app I am looking at presently. >> >> I don't think there are any surprises there. >> >> But, again, your (current) requirement is only one >> perspective. > > I can't argue with that. But that is the need I have and low cost is not a very > minor requirement. Processors are sold at much higher volumes for the low cost > products. The higher cost, lower volume products often can be built with a wide > range of solutions, again the selected device is often chosen as the one that > meets the requirements at the lowest price. So shrugging off the cost issue of > *my* current need is rather disingenuous. Of course I will shrug them off; they are of no direct interest to me. You have a choice... You could look at the XMOS devices see where they might complement the existing design options (principally FPGAs and conventional MCUs), and blur the boundaries between them. Or you could find ways in which the devices couldn't /possibly/ do what existing options can do (cf the way h/w designers reacted to early microrocessors). I can imagine that FPGA designers might see them as a /bit/ of a threat, and react accordingly.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-06-16 02:27 -0400 |
| Message-ID | <ohvthp$cuh$1@dont-email.me> |
| In reply to | #26802 |
Tom Gardner wrote on 6/16/2017 2:05 AM: > On 16/06/17 04:12, rickman wrote: >> Tom Gardner wrote on 6/15/2017 6:33 PM: >>> On 15/06/17 21:52, rickman wrote: >>>> Tom Gardner wrote on 6/15/2017 1:01 PM: >>>>> On 15/06/17 17:13, rickman wrote: >>>>>> Tom Gardner wrote on 6/15/2017 3:01 AM: >>>>>>> >>>>>>> That sounds easy for the XMOS processors: >>>>>>> - multicore (up to 32 100MIPS cores) >>>>>>> - FPGA-like i/o, e.g. SERDES, buffers, programmable >>>>>>> clocks to 250Mb/s, separate timer for each port >>>>>>> - i/o timing changes can be specified/measured in >>>>>>> software with 4ns resolution >>>>>>> - guaranteed latencies <100ns >>>>>>> - *excellent* programming model based on CSP >>>>>>> (summary: of "Occam in C") >>>>>>> - Eclipse-based dev environment >>>>>> >>>>>> Any yet the XMOS can't run fast enough to return a result in the time >>>>>> available. What a pity, all dressed up an nowhere to go. >>>>> >>>>> You'll have to explain that, because I don't understand >>>>> what you are referring to. >>>> >>>> Maybe I don't understand the speed of the XMOS. >>> >>> A 30000ft opverview: >>> http://www.xmos.com/published/xcore-architecture-flyer?version=latest >>> >>>> Nothing you write above says to >>>> me it is any faster than the 700 MIPS processor I considered. Nothing >>>> written >>>> above would allow it to perform the task any differently than the bit >>>> banging >>>> approach I initially considered. >>> >>> What are the *guaranteed* timings and latencies? >>> Include all possible disturbances due to cache/TLB >>> misses, branch predictions and interrupts. >>> Include simultaneous USB comms to a host PC. >>> >>> N.B. "guaranteed" /precludes/ measurements to see >>> what is happening. "Guaranteed" requires accurate >>> /prediction/ *before* the code executes. >> >> I know this is clear to you, but I'm not sure what processor you are >> talking about. >> >> >>>> So what are you confused about? >>>> >>>> Maybe you don't understand the problem. A bit serial data port (two bits >>>> wide >>>> actually, but that is not relevant) provides data, address and a two bit >>>> command >>>> word serially. The last bit of the command work is indicated by a >>>> "command" >>>> signal going high during that bit. Data is clocked in on the rising edge >>>> of the >>>> clock. When the command word is a read, the read data is provided serially >>>> starting on the subsequent falling edge. This provides 15 ns from rising >>>> edge >>>> to falling edge. It is possible to prefetch the read data based on the >>>> shifted >>>> address on each rising edge until the command signal is asserted. This >>>> helps >>>> with timing of the memory fetch, but still, that data has to be presented >>>> to the >>>> serial port output in 15 ns and updated every 30 ns. >>>> >>>> I'd like to see code that will make this work. Or maybe you weren't >>>> addressing >>>> my previous application? For the OP, can the XMOS emulate a 30 Mbps SPI >>>> port? >>> >>> Each i/o pin can be clocked at up to 250Mb/s. >>> That clock can come from an internal clock >>> (up to 500MHz) or an external pin. The latter >>> sounds relevant for your case. (Strobed and >>> master/slave interfaces are also directly >>> supported in hardware and software). >>> >>> Each I/O pin has SERDES registers, so the data >>> rate processed by a core can be reduced by a factor >>> of 32. >>> >>> So yes, it does look like a /small/ fraction of an xCORE >>> device could very comfortably support that speed. >> >> You still are not addressing the issue at hand. You are talking about raw >> I/O >> speeds and the problem is not about raw I/O speeds. The issue is >> interactivity. Stimulus followed by response in very short order. I have >> seen >> nothing to indicate the XMOS will work for this problem. That's why I >> asked for >> a code snippet. > > There are many interesting snippets, plus a description > of how they fit together in the /very/ lucid xC tutuorial. > https://www.xmos.com/support/tools/programming?component=17653 > > You might care to look for the "pinseq/pinsneq" attribute > of i/o ports, in conjunction with the ways of combining i/o > pins, and port timers. > > For more details of some i/o structures, see > https://www.xmos.com/published/xs1-ports-introduction?version=latest > > > >>>>>>> Currently I'm managing to count transitions in >>>>>>> software on two 50Mb/s inputs, plus do >>>>>>> simultaneous USB comms to a host computer. >>>>>> >>>>>> Can you output a result before the next input transition? >>>>> >>>>> Yes and no. >>>>> >>>>> Yes: the output (to a host processor and/or LCD) >>>>> proceeds in parallel with the next capture phase. >>>> >>>> I'm referring to bit I/O using the same 50 MHz clock. >>>> >>>> >>>>> No: in the current incarnation there is a short gap >>>>> between capture phases as the results are passed >>>>> from one core to another and the next capture phase >>>>> is started. While it isn't important in my application, >>>>> I may be able to remove that limitation in future >>>>> incarnations. >>>> >>>> That's a lot more than a "short" gap in the context of a fast clock. >>> >>> Sigh. >>> >>> My application only stops for a few microseconds when >>> it is convenient for my application, i.e. once every >>> 1 or 10seconds at the end of a measurement cycle. >>> >>> At other times it chunters away continuously at full >>> rate without interruption - as guaranteed by design. >> >> Fine, but the fact that it will work for your needs does not mean it will >> work >> for mine. Again the requirement is to read the inputs looking for a command >> strobe, on finding that retrieve the appropriate word from memory and >> outputting >> it. The clock cycle is 30 ns and the total I/O time from command strobe >> read on >> the positive edge of the clock to the input of the device monitoring the >> output >> pin (with a 5 ns setup time) 15 ns. You haven't even addressed the output >> delays in the I/O pins. >> >> >>>>>>> Processors plus £10 devkit available from Farnell >>>>>>> and DigiKey. >>>>>> >>>>>> Not a very good processor to use in cost conscious applications. The >>>>>> lowest >>>>>> price at Digikey is $3 at qty 1000. They can't make a part in the >>>>>> sub-dollar >>>>>> range? >>>>> >>>>> Don't presume everybody has your constraints. >>>> >>>> I don't, but not everyone has *your* constraints. If a processor can't be >>>> sold >>>> in a low cost product, it cuts off the largest volume parts of the market >>>> including the app I am looking at presently. >>> >>> I don't think there are any surprises there. >>> >>> But, again, your (current) requirement is only one >>> perspective. >> >> I can't argue with that. But that is the need I have and low cost is not >> a very >> minor requirement. Processors are sold at much higher volumes for the low >> cost >> products. The higher cost, lower volume products often can be built with >> a wide >> range of solutions, again the selected device is often chosen as the one that >> meets the requirements at the lowest price. So shrugging off the cost >> issue of >> *my* current need is rather disingenuous. > > Of course I will shrug them off; they are of no direct > interest to me. > > You have a choice... > > You could look at the XMOS devices see where they > might complement the existing design options > (principally FPGAs and conventional MCUs), and > blur the boundaries between them. > > Or you could find ways in which the devices > couldn't /possibly/ do what existing options > can do (cf the way h/w designers reacted to > early microrocessors). > > I can imagine that FPGA designers might see them as > a /bit/ of a threat, and react accordingly. A threat??? That makes no sense. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| Date | 2017-06-14 23:17 -0500 |
| Message-ID | <9eednQXtmtLYl9_EnZ2dnUU7-YudnZ2d@giganews.com> |
| In reply to | #26771 |
On Wed, 14 Jun 2017 10:44:00 -0700, 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 Do you know the clock rate of the data, and how fast the turn-around needs to be? Maybe a CPLD or a small FPGA, if you don't like Rick's (probably spot-on) suggestion of using an EEPROM as an intermediate device. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-06-15 08:03 +0100 |
| Message-ID | <djq0B.196030$B23.103708@fx37.am4> |
| In reply to | #26771 |
On 14/06/17 18: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? If you want guaranteed timing and FPGA-like io, have a look at the XMOS processors. See my other post.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-15 09:14 +0200 |
| Message-ID | <ohtbt5$vh5$1@dont-email.me> |
| In reply to | #26771 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-06-15 08:25 +0100 |
| Message-ID | <9Eq0B.74561$7A4.41458@fx19.am4> |
| In reply to | #26777 |
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 :) The programming model (CSP) is *very* simple and also comprehensive. It was invented in the 70s, and has stood the test of time.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-15 10:02 +0200 |
| Message-ID | <ohtena$7s5$1@dont-email.me> |
| In reply to | #26778 |
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.)
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2017-06-15 16:25 +0800 |
| Message-ID | <ohtg3k$add$1@dont-email.me> |
| In reply to | #26779 |
AT Thursday 15 June 2017 16:02, David Brown wrote: > On 15/06/17 09:25, Tom Gardner wrote: >> On 15/06/17 08:14, David Brown wrote: >>> On 14/06/17 19:44, John Speth wrote: >>>> Hi folks- >>>> >>>> I'm hoping to tap into your various experiences to see if what I'm >>>> thinking is practical. >>>> >>>> Our customer has a device into which a Datakey is plugged to extract >>>> data stored in the device. The Datakey is a really just a trade name >>>> for a SPI flash with ergonomic features that resemble a real key (see >>>> datakey.com). Our customer would like to replace the Datakey with a >>>> new design that will transmit the data wirelessly instead of storing it >>>> to the Datakey SPI flash. >>>> >>>> We're proposing a design based on an MCU which will appear as a SPI >>>> slave flash device, store the data pumped to it from the customer's >>>> device, and forward it wirelessly. I'm wondering if it's practical to >>>> accomplish it. The firmware would have to be totally responsive >>>> temporally and in data content. That sounds like a tough hill to climb >>>> that requires getting the interface just right, nearly perfect. I see >>>> a lot of pitfalls that could make the effort a dead end. >>>> >>>> Does anybody have any success or failure stories to relate that would >>>> help us gauge the feasibility of the proposed design? >>>> >>>> Thanks - John Speth >>> >>> If you make sure you have a MCU with good slave SPI support and DMA, >>> then the actual SPI transfers should not be an issue (assuming a sane >>> SPI clock speed). The cpu would then not be involved in the >>> back-to-back SPI moves at all. Pretty much any Cortex M3/4 device >>> should cope fine. >>> >>> The key challenge is how to deal with the commands - the bits that need >>> some processing. That will probably mean fast response to the first few >>> incoming SPI bytes via an interrupt function. Your requirements here >>> will depend on the protocol, the clock speed, the processing time >>> required, etc. >>> >>> Write-style SPI commands are no problem - just buffer up the SPI command >>> and data with DMA as it comes in. It's the read-style ones that are the >>> killer. For very fast SPI interfaces, it is not uncommon that with a >>> read command, the first byte returned is a dummy byte - that gives you >>> the time to fill your DMA buffer with the real data for the reply. But >>> not all SPI protocols use that, and they might have some reads that need >>> immediate response. If you can get that under control, the rest should >>> be (relatively) easy. >>> >>> If you can't build this from a normal microcontroller because you need >>> too fast response, your options are FPGA (either as an assist to a >>> microcontroller, or with a processor in the FPGA) or perhaps an XMOS >>> microcontroller. XMOS programming is a bit different from normal >>> microcontroller programming, but it will handle tasks like this easily. >> >> I'll just say that I find XMOS programming to be *very* >> easy compared to C+RTOS -- doubly so for a hardware engineer. >> >> The "RTOS" is in hardware => very low API learning curve :) >> > > XMOS programming is very easy for some things, but hard for other > things. In particular, there is a limit to the scalability. It starts > off easy splitting your work into lots of parallel tasks, putting them > each in threads, and everything is fine - until you run out of hardware > threads. Then you end up destroying your structure to get a several > logically parallel tasks running in the same hardware thread, or running > a software RTOS in one hardware thread. And when you have your multiple > high-speed interfaces working, you find you don't have enough ram left > for buffers. > > XMOS devices can be a lot of fun, and I would enjoy working with them > again. For some tasks, they are an ideal solution (like for this one), > once you have learned to use them. But not everything is easy with > them, and you have to think in a somewhat different way. > >> The programming model (CSP) is *very* simple and also >> comprehensive. It was invented in the 70s, and has stood >> the test of time. > > Yes, CSP is a great tool. I was taught it by some of the folks behind > it. (Tony Hoare himself was head of the department, but I didn't have > him as a lecturer.) Just grabbing this thread. XMOS sounds like something interesting to play with. How good is the development environment? Runs on Linux? -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-15 10:32 +0200 |
| Message-ID | <ohtgf6$ch2$2@dont-email.me> |
| In reply to | #26780 |
On 15/06/17 10:25, Reinhardt Behm wrote: > AT Thursday 15 June 2017 16:02, David Brown wrote: > >> On 15/06/17 09:25, Tom Gardner wrote: >>> On 15/06/17 08:14, David Brown wrote: >>>> On 14/06/17 19:44, John Speth wrote: >>>>> Hi folks- >>>>> >>>>> I'm hoping to tap into your various experiences to see if what I'm >>>>> thinking is practical. >>>>> >>>>> Our customer has a device into which a Datakey is plugged to extract >>>>> data stored in the device. The Datakey is a really just a trade name >>>>> for a SPI flash with ergonomic features that resemble a real key (see >>>>> datakey.com). Our customer would like to replace the Datakey with a >>>>> new design that will transmit the data wirelessly instead of storing it >>>>> to the Datakey SPI flash. >>>>> >>>>> We're proposing a design based on an MCU which will appear as a SPI >>>>> slave flash device, store the data pumped to it from the customer's >>>>> device, and forward it wirelessly. I'm wondering if it's practical to >>>>> accomplish it. The firmware would have to be totally responsive >>>>> temporally and in data content. That sounds like a tough hill to climb >>>>> that requires getting the interface just right, nearly perfect. I see >>>>> a lot of pitfalls that could make the effort a dead end. >>>>> >>>>> Does anybody have any success or failure stories to relate that would >>>>> help us gauge the feasibility of the proposed design? >>>>> >>>>> Thanks - John Speth >>>> >>>> If you make sure you have a MCU with good slave SPI support and DMA, >>>> then the actual SPI transfers should not be an issue (assuming a sane >>>> SPI clock speed). The cpu would then not be involved in the >>>> back-to-back SPI moves at all. Pretty much any Cortex M3/4 device >>>> should cope fine. >>>> >>>> The key challenge is how to deal with the commands - the bits that need >>>> some processing. That will probably mean fast response to the first few >>>> incoming SPI bytes via an interrupt function. Your requirements here >>>> will depend on the protocol, the clock speed, the processing time >>>> required, etc. >>>> >>>> Write-style SPI commands are no problem - just buffer up the SPI command >>>> and data with DMA as it comes in. It's the read-style ones that are the >>>> killer. For very fast SPI interfaces, it is not uncommon that with a >>>> read command, the first byte returned is a dummy byte - that gives you >>>> the time to fill your DMA buffer with the real data for the reply. But >>>> not all SPI protocols use that, and they might have some reads that need >>>> immediate response. If you can get that under control, the rest should >>>> be (relatively) easy. >>>> >>>> If you can't build this from a normal microcontroller because you need >>>> too fast response, your options are FPGA (either as an assist to a >>>> microcontroller, or with a processor in the FPGA) or perhaps an XMOS >>>> microcontroller. XMOS programming is a bit different from normal >>>> microcontroller programming, but it will handle tasks like this easily. >>> >>> I'll just say that I find XMOS programming to be *very* >>> easy compared to C+RTOS -- doubly so for a hardware engineer. >>> >>> The "RTOS" is in hardware => very low API learning curve :) >>> >> >> XMOS programming is very easy for some things, but hard for other >> things. In particular, there is a limit to the scalability. It starts >> off easy splitting your work into lots of parallel tasks, putting them >> each in threads, and everything is fine - until you run out of hardware >> threads. Then you end up destroying your structure to get a several >> logically parallel tasks running in the same hardware thread, or running >> a software RTOS in one hardware thread. And when you have your multiple >> high-speed interfaces working, you find you don't have enough ram left >> for buffers. >> >> XMOS devices can be a lot of fun, and I would enjoy working with them >> again. For some tasks, they are an ideal solution (like for this one), >> once you have learned to use them. But not everything is easy with >> them, and you have to think in a somewhat different way. >> >>> The programming model (CSP) is *very* simple and also >>> comprehensive. It was invented in the 70s, and has stood >>> the test of time. >> >> Yes, CSP is a great tool. I was taught it by some of the folks behind >> it. (Tony Hoare himself was head of the department, but I didn't have >> him as a lecturer.) > > Just grabbing this thread. > > XMOS sounds like something interesting to play with. > How good is the development environment? > Runs on Linux? > Yes, it runs fine on Linux. When I last worked seriously with XMOS (which was when it was a relatively new company), I had a a fair number of issues with the tools and, in particular, with the sample code. My understanding is that it has improved a good deal since then. And there is certainly no doubt that they are interesting to play with!
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2017-06-15 21:48 +0800 |
| Message-ID | <ohu30p$6o7$3@dont-email.me> |
| In reply to | #26781 |
AT Thursday 15 June 2017 16:32, David Brown wrote: > On 15/06/17 10:25, Reinhardt Behm wrote: >> AT Thursday 15 June 2017 16:02, David Brown wrote: >> >>> On 15/06/17 09:25, Tom Gardner wrote: >>>> On 15/06/17 08:14, David Brown wrote: >>>>> On 14/06/17 19:44, John Speth wrote: >>>>>> Hi folks- >>>>>> >>>>>> I'm hoping to tap into your various experiences to see if what I'm >>>>>> thinking is practical. >>>>>> >>>>>> Our customer has a device into which a Datakey is plugged to extract >>>>>> data stored in the device. The Datakey is a really just a trade name >>>>>> for a SPI flash with ergonomic features that resemble a real key (see >>>>>> datakey.com). Our customer would like to replace the Datakey with a >>>>>> new design that will transmit the data wirelessly instead of storing >>>>>> it to the Datakey SPI flash. >>>>>> >>>>>> We're proposing a design based on an MCU which will appear as a SPI >>>>>> slave flash device, store the data pumped to it from the customer's >>>>>> device, and forward it wirelessly. I'm wondering if it's practical >>>>>> to >>>>>> accomplish it. The firmware would have to be totally responsive >>>>>> temporally and in data content. That sounds like a tough hill to >>>>>> climb >>>>>> that requires getting the interface just right, nearly perfect. I >>>>>> see a lot of pitfalls that could make the effort a dead end. >>>>>> >>>>>> Does anybody have any success or failure stories to relate that would >>>>>> help us gauge the feasibility of the proposed design? >>>>>> >>>>>> Thanks - John Speth >>>>> >>>>> If you make sure you have a MCU with good slave SPI support and DMA, >>>>> then the actual SPI transfers should not be an issue (assuming a sane >>>>> SPI clock speed). The cpu would then not be involved in the >>>>> back-to-back SPI moves at all. Pretty much any Cortex M3/4 device >>>>> should cope fine. >>>>> >>>>> The key challenge is how to deal with the commands - the bits that >>>>> need >>>>> some processing. That will probably mean fast response to the first >>>>> few >>>>> incoming SPI bytes via an interrupt function. Your requirements here >>>>> will depend on the protocol, the clock speed, the processing time >>>>> required, etc. >>>>> >>>>> Write-style SPI commands are no problem - just buffer up the SPI >>>>> command >>>>> and data with DMA as it comes in. It's the read-style ones that are >>>>> the >>>>> killer. For very fast SPI interfaces, it is not uncommon that with a >>>>> read command, the first byte returned is a dummy byte - that gives you >>>>> the time to fill your DMA buffer with the real data for the reply. >>>>> But not all SPI protocols use that, and they might have some reads >>>>> that need >>>>> immediate response. If you can get that under control, the rest >>>>> should be (relatively) easy. >>>>> >>>>> If you can't build this from a normal microcontroller because you need >>>>> too fast response, your options are FPGA (either as an assist to a >>>>> microcontroller, or with a processor in the FPGA) or perhaps an XMOS >>>>> microcontroller. XMOS programming is a bit different from normal >>>>> microcontroller programming, but it will handle tasks like this >>>>> easily. >>>> >>>> I'll just say that I find XMOS programming to be *very* >>>> easy compared to C+RTOS -- doubly so for a hardware engineer. >>>> >>>> The "RTOS" is in hardware => very low API learning curve :) >>>> >>> >>> XMOS programming is very easy for some things, but hard for other >>> things. In particular, there is a limit to the scalability. It starts >>> off easy splitting your work into lots of parallel tasks, putting them >>> each in threads, and everything is fine - until you run out of hardware >>> threads. Then you end up destroying your structure to get a several >>> logically parallel tasks running in the same hardware thread, or running >>> a software RTOS in one hardware thread. And when you have your multiple >>> high-speed interfaces working, you find you don't have enough ram left >>> for buffers. >>> >>> XMOS devices can be a lot of fun, and I would enjoy working with them >>> again. For some tasks, they are an ideal solution (like for this one), >>> once you have learned to use them. But not everything is easy with >>> them, and you have to think in a somewhat different way. >>> >>>> The programming model (CSP) is *very* simple and also >>>> comprehensive. It was invented in the 70s, and has stood >>>> the test of time. >>> >>> Yes, CSP is a great tool. I was taught it by some of the folks behind >>> it. (Tony Hoare himself was head of the department, but I didn't have >>> him as a lecturer.) >> >> Just grabbing this thread. >> >> XMOS sounds like something interesting to play with. >> How good is the development environment? >> Runs on Linux? >> > > Yes, it runs fine on Linux. When I last worked seriously with XMOS > (which was when it was a relatively new company), I had a a fair number > of issues with the tools and, in particular, with the sample code. My > understanding is that it has improved a good deal since then. And there > is certainly no doubt that they are interesting to play with! Thanks David and Tom. I will give it try. Unfortunately today my latest shipping from Digikey has arrived.So it has to wait 'til the next time, but I am busy enough. -- Reinhardt
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web