Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #29458 > unrolled thread
| Started by | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| First post | 2020-04-15 20:51 -0700 |
| Last post | 2020-04-20 18:02 +0200 |
| Articles | 20 on this page of 146 — 15 participants |
Back to article view | Back to comp.arch.embedded
Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-15 20:51 -0700
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-16 11:59 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-16 13:28 +0200
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-16 13:10 +0000
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-16 22:16 +0100
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-16 22:01 +0000
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-16 17:13 -0700
Re: Custom CPU Designs jim.brakefield@ieee.org - 2020-04-16 18:10 -0700
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 18:37 -0700
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-16 22:08 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-17 10:02 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-17 10:49 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-17 15:44 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-17 15:23 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-17 18:15 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-17 17:49 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-18 15:06 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-18 16:08 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 15:13 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 14:24 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 16:00 +0200
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-20 14:32 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 23:55 +0100
Re: Custom CPU Designs Reinhardt Behm <rbehm@hushmail.com> - 2020-04-21 15:14 +0800
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-18 16:51 +0100
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-18 18:06 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-18 14:53 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-19 10:11 +0100
Re: Custom CPU Designs upsidedown@downunder.com - 2020-04-19 13:19 +0300
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-19 11:33 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 15:26 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 14:59 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-19 13:37 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-19 22:02 +0100
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-19 22:15 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-19 15:02 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 02:03 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-18 14:44 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 15:20 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 14:57 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-18 12:38 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 15:58 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 16:27 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 17:36 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 14:02 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 06:15 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 17:25 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-21 16:56 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 12:42 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-21 23:16 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-22 11:10 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-22 08:09 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-22 20:07 +0200
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-18 13:09 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-18 21:28 +0100
Re: Custom CPU Designs upsidedown@downunder.com - 2020-04-21 20:29 +0300
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-21 18:10 +0000
Re: Custom CPU Designs upsidedown@downunder.com - 2020-04-22 09:54 +0300
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-22 13:19 +0000
Re: Custom CPU Designs upsidedown@downunder.com - 2020-04-22 18:09 +0300
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-22 17:03 +0000
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-22 11:16 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-17 10:48 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-18 16:57 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-18 14:21 -0700
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-18 14:50 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 16:32 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 18:12 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-21 10:09 +0100
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 16:31 +0100
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 16:42 +0100
Re: Custom CPU Designs upsidedown@downunder.com - 2020-04-18 00:43 +0300
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-18 17:07 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-17 09:11 -0700
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-17 12:17 -0700
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-17 13:22 -0700
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-17 14:48 -0700
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-17 15:27 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 16:53 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 17:03 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 19:39 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 21:25 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 18:27 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 17:58 +0200
Re: Custom CPU Designs Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-04-21 19:41 +0300
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 14:01 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-21 23:21 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-19 20:53 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-19 14:47 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 02:11 +0100
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-19 18:31 -0700
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-19 20:32 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 07:46 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 00:33 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 11:01 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 17:44 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 19:57 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 18:02 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 14:56 -0700
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-17 16:34 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 17:57 +0200
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-21 15:20 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 08:26 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 18:09 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 15:00 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-22 11:28 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-22 08:24 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-22 20:18 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-22 11:45 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-23 17:47 +0200
Re: Custom CPU Designs jim.brakefield@ieee.org - 2020-04-21 15:35 -0700
Re: Custom CPU Designs Przemek Klosowski <przemek@tux.dot.org> - 2020-04-19 18:52 +0000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-19 13:42 -0700
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-20 22:59 +1000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 17:01 -0700
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-21 10:23 +1000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 03:47 -0700
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-22 09:26 +1000
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-22 22:06 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-22 14:18 -0700
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-23 22:35 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 18:20 +0200
Re: Custom CPU Designs Dimiter_Popoff <dp@tgi-sci.com> - 2020-04-22 18:16 +0300
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-22 17:06 +0000
Re: Custom CPU Designs Dimiter_Popoff <dp@tgi-sci.com> - 2020-04-22 20:17 +0300
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-22 17:28 +0000
Re: Custom CPU Designs George Neuner <gneuner2@comcast.net> - 2020-04-23 04:59 -0400
Re: Custom CPU Designs jim.brakefield@ieee.org - 2020-04-20 17:27 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 17:58 +0200
Re: Custom CPU Designs pault.eg@googlemail.com - 2020-04-21 01:00 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 19:21 +0200
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-17 17:18 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 07:40 -0700
Re: Custom CPU Designs jim.brakefield@ieee.org - 2020-04-16 12:28 -0700
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 13:50 -0700
Re: Custom CPU Designs jim.brakefield@ieee.org - 2020-04-16 14:19 -0700
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-16 22:33 +0100
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-17 11:29 +1000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 18:42 -0700
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-17 12:35 +1000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 20:01 -0700
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-17 14:54 +1000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 23:54 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-17 10:38 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-17 09:13 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 18:02 +0200
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-18 12:38 -0700 |
| Message-ID | <8e393102-78ce-4e43-9a7e-4d1a8d201643@googlegroups.com> |
| In reply to | #29497 |
On Saturday, April 18, 2020 at 9:06:57 AM UTC-4, David Brown wrote: > On 17/04/2020 18:49, Tom Gardner wrote: > > On 17/04/20 17:15, David Brown wrote: > >> On 17/04/2020 16:23, Tom Gardner wrote: > >>> On 17/04/20 14:44, David Brown wrote: > >>>> On 17/04/2020 11:49, Tom Gardner wrote: > >>>>> On 17/04/20 09:02, David Brown wrote: > >> > >>>>> As you say, the XMOS /ecosystem/ is far more compelling, > >>>>> partly because it has excellent /integration/ between the > >>>>> hardware, the software and the toolchain. The latter two > >>>>> are usually missing. > >>>> > >>>> Agreed. And the XMOS folk have learned and improved. With the > >>>> first chips, they proudly showed off that you could make a 100 MBit > >>>> Ethernet controller in software on an XMOS chip. Then it was > >>>> pointed out to them that - impressive achievement though it was - it > >>>> was basically useless because you didn't have the resources left to > >>>> use it for much, and hardware Ethernet controllers were much > >>>> cheaper. So they brought out new XMOS chips with hardware Ethernet > >>>> controllers. The same thing happened with USB. > >>> > >>> It looks like a USB controller needs ~8 cores, which isn't > >>> a problem on a 16 core device :) > >>> > >> > >> I've had another look, and I was mistaken - these devices only have > >> the USB and Ethernet PHYs, not the MACs, and thus require a lot of > >> processor power, pins, memory and other resources. It doesn't need 8 > >> cores, but the whole thing just seems so inefficient. No one is going > >> to spend the extra cost for an XMOS with a USB PHY, so why not put a > >> hardware USB controller on the chip? The silicon costs would surely > >> be minor, and it would save a lot of development effort and release > >> resources that are useful for other tasks. The same goes for > >> Ethernet. Just because you /can/ make these things in software on the > >> XMOS devices, does not make it a good idea. > > > > Oh I agree! However, being able to do it in software is a > > good demonstration of the device's unique characteristics, > > and that "you aren't in Kansas anymore" > > > > Indeed. > > The real power comes from when you want to do something that is /not/ > standard, or at least not common. > > Implementing a standard UART in a couple of XMOS cores is a pointless > waste of silicon. Implementing a UART that uses Manchester encoding for > the UART signals so that you can use it on a balanced line without > keeping track of which line is which - /then/ you've got something that > can be done just as easily on an XMOS and is a big pain to do on a > standard microcontroller. I take your point even if I don't agree with your example. I don't follow your comment about "which line is which". Manchester encoding uses the polarity of transitions for the data being transmitted. To set up for the correct polarity data transition there are extra transitions which should be ignored. To properly decode the data requires having the correct polarity of the signal at the input. Swap lines and you get wrong data. It's not hard to receive Manchester encoded data on a typical MCU. They virtually all have transition based interrupts on I/O pins. Enable the interrupts and on each transition grab a timer value. It would even be easy to have it auto-baud rate detect as the values should have two primary modes. Why do you say this is a hard thing to do??? > Implementing an Ethernet MAC on an XMOS is pointless. Implementing an > EtherCAT slave is not going to be much harder for the XMOS than a normal > Ethernet MAC, but is impossible on any microcontroller without > specialised peripherals. That is exactly the point of the MCU market, the huge variety of combinations of hard peripherals available these days. Nearly every maker of MCUs will have an almost perfect match for your needs. Peripherals may use some real estate on a chip, but the lion's share is simply the memory. These days MCU chips are more memory chips with built in CPUs and peripherals than CPU chips. So your point of adding an external Ethernet MAC to MCUs is a red herring. I just noticed you said "EtherCAT" which I was not aware of. Seems this is some other protocol than Ethernet. Ok, maybe that will be just as easy on either type of MCU since it is a relatively niche application. Once the market grows you can be assured MCUs will be commonly available with EtherCAT in hard peripherals. > >> Overall, the thing that bugs me about XMOS is that you can write very > >> simple, elegant tasks for the cores to do various tasks. But when you > >> do that, you run out of cores almost immediately. So you have to > >> write your code in a way that implements your own scheduler, losing a > >> major part of the point of the whole system. Or you use the XMOS > >> FreeRTOS port on one of the virtual cores - in which case you could > >> just switch to a Cortex-M microcontroller with hardware USB, Ethernet, > >> PWM, UART, etc. and a fraction of the price. > > > > I didn't know they had a FreeRTOS port, and it sounds > > like having a dog and barking :) Sounds like it would > > combine the disadvantages and negate the advantages! > > > > Some real-time stuff needs microsecond or sub-microsecond precision - > XMOS lets you do that in software on a core, while normally you'd do it > in dedicated peripherals on a microcontroller. But a lot needs > millisecond or sub-second precision, and FreeRTOS is absolutely fine for > that. (As are other methods, such as software timers.) We have hashed this out many times. XMOS is a better solution for a very small range of applications in a niche area between FPGAs and MCUs. It is a small area because MCUs are very popular, well understood and available with a very wide range of memory and peripherals to suit nearly every application where the speed of the processor is not the limitation. Once you exceed that range there is only a small increment before the requirements outpace the XMOS capabilities and FPGAs are much better solutions. One big advantage FPGAs have over XMOS is flexibility. Need one small processor plus fast logic, boom! Need lots of small processors and not so much logic, boom! Need really fast processors plug lots of logic tightly integrated, boom! The XMOS shoe really only fits one size of feet. > > Having said that, they did have a chip where one of the > > processors was an ARM. Perhaps it was intended that the > > ARM run FreeRTOS? > > I haven't seen such a chip. Do you have a link? It could be an > interesting device. > > > > > > >> If the XMOS devices and software had a way of neatly multi-tasking > >> /within/ a single virtual core, while keeping the same kind of > >> inter-task communication and other benefits, then they would have > >> something I could see being very nice. > > > > There is a half-way house. > > > > If you adopt a certain coding style, the IDE will combine > > several processes to run on a single processor. > > > > Basically it is equivalent to appending all the process' > > "startup" code into a single block, and all the "forever > > loop" code into a single block. The key bit is combining > > all the process' select statements into as single select > > statement. > > > > With that understanding, the coding style requirements > > become obvious, not onerous, and they are checked by the > > compiler. > > I understand the principle, but you'd lose some of the modularity here. > How well does it work if you want to have your UART, your CAN, your PWM, > etc., defined in different files - and then you want to put them on the > same core? I guess it will be possible. > > > > > > >>>> There is a lot to like about XMOS devices and tools, but they still > >>>> strike me as a solution in search of a problem. An elegant > >>>> solution, perhaps, but still missing a problem. We used them for a > >>>> project many years ago for a USB Audio Class 2 device. There simply > >>>> were no realistic alternatives at the time, but I can't say the XMOS > >>>> solution was a good one. The device has far too little memory to > >>>> make sensible buffers (this still applies to XMOS devices, last I > >>>> looked), and the software at the time was painful (this I believe > >>>> has improved significantly). If we were making a new version of the > >>>> product, we'd drop the XMOS device in an instant and use an > >>>> off-the-shelf chip instead. > >>> > >>> I certainly wouldn't want to comment on your use case. > >> > >> As I said, it was a while ago, when XMOS were relatively new - I > >> assume the software, libraries and examples are better now than at > >> that time. But for applications like ours, you can just get a CMedia > >> chip and wire it up - no matter how good XMOS tools have become, they > >> don't beat that. > >> > >> (And then all the development budget can be spent on trying to get > >> drivers to work on idiotic Windows systems...) > > > > What is this "Windows" of which you speak? > > > > Something some customers have. It is a system designed to be as > inconvenient for developers as humanly possible. > > > > >>> To me a large part of the attraction is that you can > >>> /predict/ the /worst/ case latency and jitter (and hence > >>> throughput), in a way that is difficult in a standard MCU > >>> and easy in an FPGA. > >> > >> For standard MCU's, you aim to do this by using hardware peripherals > >> (timers, PWM blocks, communication controllers, etc.) for the most > >> timing-critical stuff. Then you don't need it in the software. > > > > Yebbut, the toolset won't analyse and predict worst case > > performance. So you are back to "run it and hope we stumble > > upon the worst case". > > > > The peripherals are independent, and specified in documentation. If the > PWM timer block can do 16-bit precision at 120 MHz, then you know its > limits - and it doesn't matter how many UARTs you use or how fast you > want your SPI bus to run. You don't need to analyse the timings - that > was done when the chip was designed. > > You need to check the speeds of your high-level software that uses the > modules, but that applies to XMOS code too. This is an area where FPGAs excel. Timing is relatively easy to verify and the details of coordinating the various processes is trivial. It's an area where MCUs can be very difficult to analyze. -- Rick C. ++- Get 1,000 miles of free Supercharging ++- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-20 15:58 +0200 |
| Message-ID | <r7k9pe$t55$1@dont-email.me> |
| In reply to | #29503 |
On 18/04/2020 21:38, Rick C wrote: > On Saturday, April 18, 2020 at 9:06:57 AM UTC-4, David Brown wrote: >> On 17/04/2020 18:49, Tom Gardner wrote: >>> On 17/04/20 17:15, David Brown wrote: >>>> On 17/04/2020 16:23, Tom Gardner wrote: >>>>> On 17/04/20 14:44, David Brown wrote: >>>>>> On 17/04/2020 11:49, Tom Gardner wrote: >>>>>>> On 17/04/20 09:02, David Brown wrote: >>>> >>>>>>> As you say, the XMOS /ecosystem/ is far more compelling, >>>>>>> partly because it has excellent /integration/ between >>>>>>> the hardware, the software and the toolchain. The latter >>>>>>> two are usually missing. >>>>>> >>>>>> Agreed. And the XMOS folk have learned and improved. With >>>>>> the first chips, they proudly showed off that you could >>>>>> make a 100 MBit Ethernet controller in software on an XMOS >>>>>> chip. Then it was pointed out to them that - impressive >>>>>> achievement though it was - it was basically useless >>>>>> because you didn't have the resources left to use it for >>>>>> much, and hardware Ethernet controllers were much cheaper. >>>>>> So they brought out new XMOS chips with hardware Ethernet >>>>>> controllers. The same thing happened with USB. >>>>> >>>>> It looks like a USB controller needs ~8 cores, which isn't a >>>>> problem on a 16 core device :) >>>>> >>>> >>>> I've had another look, and I was mistaken - these devices only >>>> have the USB and Ethernet PHYs, not the MACs, and thus require >>>> a lot of processor power, pins, memory and other resources. It >>>> doesn't need 8 cores, but the whole thing just seems so >>>> inefficient. No one is going to spend the extra cost for an >>>> XMOS with a USB PHY, so why not put a hardware USB controller >>>> on the chip? The silicon costs would surely be minor, and it >>>> would save a lot of development effort and release resources >>>> that are useful for other tasks. The same goes for Ethernet. >>>> Just because you /can/ make these things in software on the >>>> XMOS devices, does not make it a good idea. >>> >>> Oh I agree! However, being able to do it in software is a good >>> demonstration of the device's unique characteristics, and that >>> "you aren't in Kansas anymore" >>> >> >> Indeed. >> >> The real power comes from when you want to do something that is >> /not/ standard, or at least not common. >> >> Implementing a standard UART in a couple of XMOS cores is a >> pointless waste of silicon. Implementing a UART that uses >> Manchester encoding for the UART signals so that you can use it on >> a balanced line without keeping track of which line is which - >> /then/ you've got something that can be done just as easily on an >> XMOS and is a big pain to do on a standard microcontroller. > > I take your point even if I don't agree with your example. > > I don't follow your comment about "which line is which". Manchester > encoding uses the polarity of transitions for the data being > transmitted. To set up for the correct polarity data transition > there are extra transitions which should be ignored. To properly > decode the data requires having the correct polarity of the signal at > the input. Swap lines and you get wrong data. Sorry, it is /differential/ Manchester encoding that is polarity independent. But as you say, it is the principle of the point that matters, rather than the details. > > It's not hard to receive Manchester encoded data on a typical MCU. > They virtually all have transition based interrupts on I/O pins. > Enable the interrupts and on each transition grab a timer value. It > would even be easy to have it auto-baud rate detect as the values > should have two primary modes. Why do you say this is a hard thing > to do??? > Of course it can all be done in software on an MCU, using timers and interrupts. But the more timing-critical things you do in pure software, the harder it gets to keep everything in specification in the worst case. The way the XMOS is built up with its IO ports connected to timers and buffers, it's easy to make such features with extremely low jitter - even if you have many of them at high speed. And more importantly, the way the software tools are designed it can check that your code is within your specifications for this kind of thing. > >> Implementing an Ethernet MAC on an XMOS is pointless. Implementing >> an EtherCAT slave is not going to be much harder for the XMOS than >> a normal Ethernet MAC, but is impossible on any microcontroller >> without specialised peripherals. > > That is exactly the point of the MCU market, the huge variety of > combinations of hard peripherals available these days. Nearly every > maker of MCUs will have an almost perfect match for your needs. I need an MCU with 4 EtherCAT slave channels. There are exactly 0 on the market. There are only two or three in total - from all manufacturers together - with even /one/ EtherCAT slave. If there were an XMOS EtherCAT slave peripheral, perhaps I could have used one of their devices. (There are FPGA EtherCAT cores available, but the price of the cores, the price of the required FPGAs, and other complications rule that out.) > Peripherals may use some real estate on a chip, but the lion's share > is simply the memory. These days MCU chips are more memory chips > with built in CPUs and peripherals than CPU chips. I agree entirely, for "standard" peripherals. But some peripherals are too unusual to turn up on MCUs. (There is, of course, not clear definition of what a "standard peripheral" might be.) > > So your point of adding an external Ethernet MAC to MCUs is a red > herring. > > I just noticed you said "EtherCAT" which I was not aware of. Seems > this is some other protocol than Ethernet. Ah, that explains things. Roughly speaking, an EtherCAT slave takes Ethernet packets as they come in, reads and writes to them as they go past, and sends the packets on towards the next slave on the bus with the least possible delay (they do not wait for the packet to be fully received). The master side can run on a normal Ethernet MAC, but the slave side requires special hardware. > Ok, maybe that will be > just as easy on either type of MCU since it is a relatively niche > application. Once the market grows you can be assured MCUs will be > commonly available with EtherCAT in hard peripherals. > EtherCAT has been around for a long time - it is not new. But it is quite niche. <snip> >> >> You need to check the speeds of your high-level software that uses >> the modules, but that applies to XMOS code too. > > This is an area where FPGAs excel. Timing is relatively easy to > verify and the details of coordinating the various processes is > trivial. > Yes, especially for the fine details. But it gets harder again if there can be a varying number of clock cycles in events. You do have the big advantage with FPGAs that timing of different parts is usually independent, unlike on MCUs. > It's an area where MCUs can be very difficult to analyze. > Absolutely. You could say that XMOS devices and tools are a middle ground here.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-20 16:27 +0100 |
| Message-ID | <zbjnG.59686$oS7.3745@fx39.am4> |
| In reply to | #29535 |
On 20/04/20 14:58, David Brown wrote: > On 18/04/2020 21:38, Rick C wrote: > Yes, especially for the fine details. But it gets harder again if there can be > a varying number of clock cycles in events. You do have the big advantage with > FPGAs that timing of different parts is usually independent, unlike on MCUs. > >> It's an area where MCUs can be very difficult to analyze. >> > > Absolutely. > > You could say that XMOS devices and tools are a middle ground here. Precisely. Maybe Rick will get there, if he bothers to put in the effort :)
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-20 17:36 -0700 |
| Message-ID | <d2d3e626-5606-435b-890a-981f97707484@googlegroups.com> |
| In reply to | #29535 |
On Monday, April 20, 2020 at 9:58:09 AM UTC-4, David Brown wrote: > On 18/04/2020 21:38, Rick C wrote: > > On Saturday, April 18, 2020 at 9:06:57 AM UTC-4, David Brown wrote: > >> > >> The real power comes from when you want to do something that is > >> /not/ standard, or at least not common. > >> > >> Implementing a standard UART in a couple of XMOS cores is a > >> pointless waste of silicon. Implementing a UART that uses > >> Manchester encoding for the UART signals so that you can use it on > >> a balanced line without keeping track of which line is which - > >> /then/ you've got something that can be done just as easily on an > >> XMOS and is a big pain to do on a standard microcontroller. > > > > I take your point even if I don't agree with your example. > > > > I don't follow your comment about "which line is which". Manchester > > encoding uses the polarity of transitions for the data being > > transmitted. To set up for the correct polarity data transition > > there are extra transitions which should be ignored. To properly > > decode the data requires having the correct polarity of the signal at > > the input. Swap lines and you get wrong data. > > Sorry, it is /differential/ Manchester encoding that is polarity > independent. But as you say, it is the principle of the point that > matters, rather than the details. Ok, got it. > > It's not hard to receive Manchester encoded data on a typical MCU. > > They virtually all have transition based interrupts on I/O pins. > > Enable the interrupts and on each transition grab a timer value. It > > would even be easy to have it auto-baud rate detect as the values > > should have two primary modes. Why do you say this is a hard thing > > to do??? > > > > Of course it can all be done in software on an MCU, using timers and > interrupts. But the more timing-critical things you do in pure > software, the harder it gets to keep everything in specification in the > worst case. The way the XMOS is built up with its IO ports connected to > timers and buffers, it's easy to make such features with extremely low > jitter - even if you have many of them at high speed. And more > importantly, the way the software tools are designed it can check that > your code is within your specifications for this kind of thing. That's interesting. > >> Implementing an Ethernet MAC on an XMOS is pointless. Implementing > >> an EtherCAT slave is not going to be much harder for the XMOS than > >> a normal Ethernet MAC, but is impossible on any microcontroller > >> without specialised peripherals. > > > > That is exactly the point of the MCU market, the huge variety of > > combinations of hard peripherals available these days. Nearly every > > maker of MCUs will have an almost perfect match for your needs. > > I need an MCU with 4 EtherCAT slave channels. There are exactly 0 on > the market. There are only two or three in total - from all > manufacturers together - with even /one/ EtherCAT slave. Yes, because EtherCAT is not widely used at the moment. I had never heard of it. When I read about it I see some car makers are looking at adopting it. Once that happens there will be MCUs supporting the interface. Until then it is a niche market. Am I wrong? I don't see any indication there is much out there either in the supply or demand side. > If there were an XMOS EtherCAT slave peripheral, perhaps I could have > used one of their devices. (There are FPGA EtherCAT cores available, > but the price of the cores, the price of the required FPGAs, and other > complications rule that out.) Huh? I'm not familiar with the details of EtherCAT. Is this a rather complex protocol on a level with Ethernet? I haven't looked at core prices for FPGAs. Is an Ethernet MAC expensive? Is this something you can't design yourself? Get me an adequate specification and I will give you a price estimate for a four channel EtherCAT interface in an FPGA. I'm not really sure of your point. You are talking about a limitation of a new interface which is not supported in the market. How does this have anything to do with any of the technologies involved? > > Peripherals may use some real estate on a chip, but the lion's share > > is simply the memory. These days MCU chips are more memory chips > > with built in CPUs and peripherals than CPU chips. > > I agree entirely, for "standard" peripherals. But some peripherals are > too unusual to turn up on MCUs. (There is, of course, not clear > definition of what a "standard peripheral" might be.) That was exactly the reason I initially used an FPGA on the board I'm currently selling. The customer had a custom control interface that was just enough different that an SPI could not be used and too fast to bit bang it. The FPGA turned out to be fortunate because they came back later with other requirements that would also have been hard in a reasonable MCU. A GA144 would have been a good choice but not available at the time. > > So your point of adding an external Ethernet MAC to MCUs is a red > > herring. > > > > I just noticed you said "EtherCAT" which I was not aware of. Seems > > this is some other protocol than Ethernet. > > Ah, that explains things. > > Roughly speaking, an EtherCAT slave takes Ethernet packets as they come > in, reads and writes to them as they go past, and sends the packets on > towards the next slave on the bus with the least possible delay (they do > not wait for the packet to be fully received). The master side can run > on a normal Ethernet MAC, but the slave side requires special hardware. So is this then a superset of the Ethernet MAC or a separate interface that then requires an Ethernet MAC for this same node? > > Ok, maybe that will be > > just as easy on either type of MCU since it is a relatively niche > > application. Once the market grows you can be assured MCUs will be > > commonly available with EtherCAT in hard peripherals. > > > > EtherCAT has been around for a long time - it is not new. But it is > quite niche. New, not new. Not relevant. Newly received by a larger audience. > >> You need to check the speeds of your high-level software that uses > >> the modules, but that applies to XMOS code too. > > > > This is an area where FPGAs excel. Timing is relatively easy to > > verify and the details of coordinating the various processes is > > trivial. > > > > Yes, especially for the fine details. But it gets harder again if there > can be a varying number of clock cycles in events. You do have the big > advantage with FPGAs that timing of different parts is usually > independent, unlike on MCUs. > > > It's an area where MCUs can be very difficult to analyze. > > > > Absolutely. > > You could say that XMOS devices and tools are a middle ground here. Yes, I have mentioned before that XMOS sits in a small area where conventional CPUS are difficult, but the problem is still simple enough to run on the XMOS. Outside of MCUs it isn't far to get to the point where only FPGAs will do the job easily. At least that's my experience. I don't see XMOS taking many design wins from FPGAs or MCUs. You seem to be saying they haven't worked very often for you. -- Rick C. +--+ Get 1,000 miles of free Supercharging +--+ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-21 14:02 +0200 |
| Message-ID | <r7mnc7$h84$1@dont-email.me> |
| In reply to | #29555 |
On 21/04/2020 02:36, Rick C wrote: > On Monday, April 20, 2020 at 9:58:09 AM UTC-4, David Brown wrote: >> On 18/04/2020 21:38, Rick C wrote: >>> On Saturday, April 18, 2020 at 9:06:57 AM UTC-4, David Brown >>> wrote: >>>> >> I need an MCU with 4 EtherCAT slave channels. There are exactly 0 >> on the market. There are only two or three in total - from all >> manufacturers together - with even /one/ EtherCAT slave. > > Yes, because EtherCAT is not widely used at the moment. I had never > heard of it. When I read about it I see some car makers are looking > at adopting it. Once that happens there will be MCUs supporting the > interface. Until then it is a niche market. Am I wrong? I don't > see any indication there is much out there either in the supply or > demand side. > EtherCAT has been increasingly popular in industrial automation (the world of Programmable Logic Controllers, Profibus, Frequency Converters, etc.). It's the stuff that runs factories, and programmed and set up by automation engineers that are a kind of cross between electricians and software developers. Characteristics of electronics in this field are that they are often quite expensive, but designed to fit together and "just work" even when made by different companies. Most of the stuff is made by relatively few large companies, rather than small companies. Implementing many of the protocols involved are quite horrible - badly specified (with large fees to be paid before you can even see the documents), overly complex, and typically require complicated XML-based "descriptors" that make USB descriptors look simple. But while that stuff makes them unpleasant to implement, it makes them very easy to use for the people actually making the automation setups. EtherCAT is also quite complicated, but a lot of it is handled by dedicated slave controller chips and software stacks that are available. I believe you are right that if it takes off in the automotive world, we'll see more microcontrollers that support them. Certainly there is more normal Ethernet in the car world. Normal Ethernet has big advantages of flexibility, familiarity and existing software and hardware. EtherCAT is unfamiliar to most people, and is suitable for different types of network - it's good for very predictable timing (you can get 0.1 microsecond synchronisation between nodes), deterministic transfers and low latency, but throughput is lower and transfer of large amounts of data is awkward. > >> If there were an XMOS EtherCAT slave peripheral, perhaps I could >> have used one of their devices. (There are FPGA EtherCAT cores >> available, but the price of the cores, the price of the required >> FPGAs, and other complications rule that out.) > > Huh? I'm not familiar with the details of EtherCAT. Is this a > rather complex protocol on a level with Ethernet? > > I haven't looked at core prices for FPGAs. Is an Ethernet MAC > expensive? Is this something you can't design yourself? Get me an > adequate specification and I will give you a price estimate for a > four channel EtherCAT interface in an FPGA. > There are lots of Ethernet cores available for FPGAs. Some are free, some cost, some are very efficient, some less so, some flexible, some more dedicated. The ubiquity of Ethernet means cores are cheap and well supported. There are very few EtherCAT cores available. They are expensive, and quite specialised - just like microcontrollers with EtherCAT, and external stand-alone peripherals. And if they take off in cars, then we can expect that situation to change. > I'm not really sure of your point. You are talking about a > limitation of a new interface which is not supported in the market. > How does this have anything to do with any of the technologies > involved? My point was that XMOS could have made something /different/. Something that is known well enough for people to see the point even if they hadn't thought of using EtherCAT themselves (there is a Wikipedia entry, and plenty of Youtube videos on EtherCAT), but not so standard that everyone and their cat has support. (XMOS /have/ done that with the audio stuff.) > > >>> Peripherals may use some real estate on a chip, but the lion's >>> share is simply the memory. These days MCU chips are more memory >>> chips with built in CPUs and peripherals than CPU chips. >> >> I agree entirely, for "standard" peripherals. But some peripherals >> are too unusual to turn up on MCUs. (There is, of course, not >> clear definition of what a "standard peripheral" might be.) > > That was exactly the reason I initially used an FPGA on the board I'm > currently selling. The customer had a custom control interface that > was just enough different that an SPI could not be used and too fast > to bit bang it. The FPGA turned out to be fortunate because they > came back later with other requirements that would also have been > hard in a reasonable MCU. > > A GA144 would have been a good choice but not available at the time. > > >>> So your point of adding an external Ethernet MAC to MCUs is a >>> red herring. >>> >>> I just noticed you said "EtherCAT" which I was not aware of. >>> Seems this is some other protocol than Ethernet. >> >> Ah, that explains things. >> >> Roughly speaking, an EtherCAT slave takes Ethernet packets as they >> come in, reads and writes to them as they go past, and sends the >> packets on towards the next slave on the bus with the least >> possible delay (they do not wait for the packet to be fully >> received). The master side can run on a normal Ethernet MAC, but >> the slave side requires special hardware. > > So is this then a superset of the Ethernet MAC or a separate > interface that then requires an Ethernet MAC for this same node? > It is a type of MAC, but not a normal Ethernet MAC. The physical side (the PHY) is the same. But where an Ethernet MAC reads incoming packets in and stores them in ram somewhere, and collects outgoing packets from ram and sends them out, an EtherCAT MAC reads and writes bits of the packet while passing it on towards the next node. > >>> Ok, maybe that will be just as easy on either type of MCU since >>> it is a relatively niche application. Once the market grows you >>> can be assured MCUs will be commonly available with EtherCAT in >>> hard peripherals. >>> >> >> EtherCAT has been around for a long time - it is not new. But it >> is quite niche. > > New, not new. Not relevant. Newly received by a larger audience. > > >>>> You need to check the speeds of your high-level software that >>>> uses the modules, but that applies to XMOS code too. >>> >>> This is an area where FPGAs excel. Timing is relatively easy to >>> verify and the details of coordinating the various processes is >>> trivial. >>> >> >> Yes, especially for the fine details. But it gets harder again if >> there can be a varying number of clock cycles in events. You do >> have the big advantage with FPGAs that timing of different parts is >> usually independent, unlike on MCUs. >> >>> It's an area where MCUs can be very difficult to analyze. >>> >> >> Absolutely. >> >> You could say that XMOS devices and tools are a middle ground >> here. > > Yes, I have mentioned before that XMOS sits in a small area where > conventional CPUS are difficult, but the problem is still simple > enough to run on the XMOS. Outside of MCUs it isn't far to get to > the point where only FPGAs will do the job easily. > > At least that's my experience. I don't see XMOS taking many design > wins from FPGAs or MCUs. > > You seem to be saying they haven't worked very often for you. > I said I haven't needed them, except for one project a fair number of years ago. It is even longer since I have needed an FPGA (though a number of our customers have FPGA boards).
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-21 06:15 -0700 |
| Message-ID | <aa2676b6-4b95-4eea-85eb-0a473a0961f9@googlegroups.com> |
| In reply to | #29563 |
On Tuesday, April 21, 2020 at 8:02:18 AM UTC-4, David Brown wrote: > On 21/04/2020 02:36, Rick C wrote: > > On Monday, April 20, 2020 at 9:58:09 AM UTC-4, David Brown wrote: > >> On 18/04/2020 21:38, Rick C wrote: > >>> On Saturday, April 18, 2020 at 9:06:57 AM UTC-4, David Brown > >>> wrote: > >>>> > > >> I need an MCU with 4 EtherCAT slave channels. There are exactly 0 > >> on the market. There are only two or three in total - from all > >> manufacturers together - with even /one/ EtherCAT slave. > > > > Yes, because EtherCAT is not widely used at the moment. I had never > > heard of it. When I read about it I see some car makers are looking > > at adopting it. Once that happens there will be MCUs supporting the > > interface. Until then it is a niche market. Am I wrong? I don't > > see any indication there is much out there either in the supply or > > demand side. > > > > EtherCAT has been increasingly popular in industrial automation (the > world of Programmable Logic Controllers, Profibus, Frequency Converters, > etc.). You say "increasingly popular" but if it were being used in higher volumes MCUs with EtherCAT interfaces would be available. MCU makers aren't stupid and love to have any advantage over the competition they can find. So "popular" has to be something other than unit volume. > It's the stuff that runs factories, and programmed and set up by > automation engineers that are a kind of cross between electricians and > software developers. Characteristics of electronics in this field are > that they are often quite expensive, but designed to fit together and > "just work" even when made by different companies. Most of the stuff is > made by relatively few large companies, rather than small companies. > Implementing many of the protocols involved are quite horrible - badly > specified (with large fees to be paid before you can even see the > documents), overly complex, and typically require complicated XML-based > "descriptors" that make USB descriptors look simple. But while that > stuff makes them unpleasant to implement, it makes them very easy to use > for the people actually making the automation setups. > > EtherCAT is also quite complicated, but a lot of it is handled by > dedicated slave controller chips and software stacks that are available. So what sort of price premium are these peripheral chips adding to the BoM? > I believe you are right that if it takes off in the automotive world, > we'll see more microcontrollers that support them. Certainly there is > more normal Ethernet in the car world. Normal Ethernet has big > advantages of flexibility, familiarity and existing software and > hardware. EtherCAT is unfamiliar to most people, and is suitable for > different types of network - it's good for very predictable timing (you > can get 0.1 microsecond synchronisation between nodes), deterministic > transfers and low latency, but throughput is lower and transfer of large > amounts of data is awkward. > > > > >> If there were an XMOS EtherCAT slave peripheral, perhaps I could > >> have used one of their devices. (There are FPGA EtherCAT cores > >> available, but the price of the cores, the price of the required > >> FPGAs, and other complications rule that out.) > > > > Huh? I'm not familiar with the details of EtherCAT. Is this a > > rather complex protocol on a level with Ethernet? > > > > I haven't looked at core prices for FPGAs. Is an Ethernet MAC > > expensive? Is this something you can't design yourself? Get me an > > adequate specification and I will give you a price estimate for a > > four channel EtherCAT interface in an FPGA. > > > > There are lots of Ethernet cores available for FPGAs. Some are free, > some cost, some are very efficient, some less so, some flexible, some > more dedicated. The ubiquity of Ethernet means cores are cheap and well > supported. > > There are very few EtherCAT cores available. They are expensive, and > quite specialised - just like microcontrollers with EtherCAT, and > external stand-alone peripherals. And if they take off in cars, then we > can expect that situation to change. > > > I'm not really sure of your point. You are talking about a > > limitation of a new interface which is not supported in the market. > > How does this have anything to do with any of the technologies > > involved? > > My point was that XMOS could have made something /different/. Something > that is known well enough for people to see the point even if they > hadn't thought of using EtherCAT themselves (there is a Wikipedia entry, > and plenty of Youtube videos on EtherCAT), but not so standard that > everyone and their cat has support. (XMOS /have/ done that with the > audio stuff.) You are suggesting that EtherCAT could be the "killer app" for XMOS? I don't know. But as with virtually every other type of peripheral, once the demand increases it will be part of everything from 8051s to high end ARMs. > >>> Peripherals may use some real estate on a chip, but the lion's > >>> share is simply the memory. These days MCU chips are more memory > >>> chips with built in CPUs and peripherals than CPU chips. > >> > >> I agree entirely, for "standard" peripherals. But some peripherals > >> are too unusual to turn up on MCUs. (There is, of course, not > >> clear definition of what a "standard peripheral" might be.) > > > > That was exactly the reason I initially used an FPGA on the board I'm > > currently selling. The customer had a custom control interface that > > was just enough different that an SPI could not be used and too fast > > to bit bang it. The FPGA turned out to be fortunate because they > > came back later with other requirements that would also have been > > hard in a reasonable MCU. > > > > A GA144 would have been a good choice but not available at the time. > > > > > >>> So your point of adding an external Ethernet MAC to MCUs is a > >>> red herring. > >>> > >>> I just noticed you said "EtherCAT" which I was not aware of. > >>> Seems this is some other protocol than Ethernet. > >> > >> Ah, that explains things. > >> > >> Roughly speaking, an EtherCAT slave takes Ethernet packets as they > >> come in, reads and writes to them as they go past, and sends the > >> packets on towards the next slave on the bus with the least > >> possible delay (they do not wait for the packet to be fully > >> received). The master side can run on a normal Ethernet MAC, but > >> the slave side requires special hardware. > > > > So is this then a superset of the Ethernet MAC or a separate > > interface that then requires an Ethernet MAC for this same node? > > > > It is a type of MAC, but not a normal Ethernet MAC. The physical side > (the PHY) is the same. But where an Ethernet MAC reads incoming packets > in and stores them in ram somewhere, and collects outgoing packets from > ram and sends them out, an EtherCAT MAC reads and writes bits of the > packet while passing it on towards the next node. Ok, sounds like there is a lot more to it. I guess I'll have to read up about it at some point. I'm happy to work on an EtherCAT design for an FPGA. I'm not really in the business of selling IP but it's a possibility. Maybe program it into an Ice40 chip and sell it as a product. They have non-volatile, one time programmable config memory. So they can work as preprogrammed devices. > >>> Ok, maybe that will be just as easy on either type of MCU since > >>> it is a relatively niche application. Once the market grows you > >>> can be assured MCUs will be commonly available with EtherCAT in > >>> hard peripherals. > >>> > >> > >> EtherCAT has been around for a long time - it is not new. But it > >> is quite niche. > > > > New, not new. Not relevant. Newly received by a larger audience. > > > > > >>>> You need to check the speeds of your high-level software that > >>>> uses the modules, but that applies to XMOS code too. > >>> > >>> This is an area where FPGAs excel. Timing is relatively easy to > >>> verify and the details of coordinating the various processes is > >>> trivial. > >>> > >> > >> Yes, especially for the fine details. But it gets harder again if > >> there can be a varying number of clock cycles in events. You do > >> have the big advantage with FPGAs that timing of different parts is > >> usually independent, unlike on MCUs. > >> > >>> It's an area where MCUs can be very difficult to analyze. > >>> > >> > >> Absolutely. > >> > >> You could say that XMOS devices and tools are a middle ground > >> here. > > > > Yes, I have mentioned before that XMOS sits in a small area where > > conventional CPUS are difficult, but the problem is still simple > > enough to run on the XMOS. Outside of MCUs it isn't far to get to > > the point where only FPGAs will do the job easily. > > > > At least that's my experience. I don't see XMOS taking many design > > wins from FPGAs or MCUs. > > > > You seem to be saying they haven't worked very often for you. > > > > I said I haven't needed them, except for one project a fair number of > years ago. It is even longer since I have needed an FPGA (though a > number of our customers have FPGA boards). I've realized for a number of years FPGAs are underutilized. It's largely a matter of unfamiliarity or misconceptions. I still run into people who think they have to be high power consumption devices. They can be small, power efficient and high performance all in a single chip. Development difficulty is overstated a lot too. I find them much easier to work with than MCUs. That's why I feel the XMOS has a limited niche between MCUs and FPGAs. They really aren't general purpose because they are pricey. An FPGA can be cheaper in many situations. But FPGAs aren't great for a full TCP/IP stack, etc. So different horses for different courses. -- Rick C. +++- Get 1,000 miles of free Supercharging +++- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-21 17:25 +0200 |
| Message-ID | <r7n39e$8fo$1@dont-email.me> |
| In reply to | #29564 |
On 21/04/2020 15:15, Rick C wrote: > On Tuesday, April 21, 2020 at 8:02:18 AM UTC-4, David Brown wrote: >> On 21/04/2020 02:36, Rick C wrote: >>> On Monday, April 20, 2020 at 9:58:09 AM UTC-4, David Brown wrote: >>>> On 18/04/2020 21:38, Rick C wrote: >>>>> On Saturday, April 18, 2020 at 9:06:57 AM UTC-4, David Brown >>>>> wrote: >>>>>> >> >>>> I need an MCU with 4 EtherCAT slave channels. There are exactly 0 >>>> on the market. There are only two or three in total - from all >>>> manufacturers together - with even /one/ EtherCAT slave. >>> >>> Yes, because EtherCAT is not widely used at the moment. I had never >>> heard of it. When I read about it I see some car makers are looking >>> at adopting it. Once that happens there will be MCUs supporting the >>> interface. Until then it is a niche market. Am I wrong? I don't >>> see any indication there is much out there either in the supply or >>> demand side. >>> >> >> EtherCAT has been increasingly popular in industrial automation (the >> world of Programmable Logic Controllers, Profibus, Frequency Converters, >> etc.). > > You say "increasingly popular" but if it were being used in higher volumes MCUs with EtherCAT interfaces would be available. MCU makers aren't stupid and love to have any advantage over the competition they can find. > > So "popular" has to be something other than unit volume. I wrote "increasingly popular", because it is becoming increasingly popular. That means both that more and more people are using EtherCAT devices, more and more EtherCAT devices are being installed, more and more EtherCAT devices are being developed, more and more EtherCAT MCUs, standand-alone peripherals, and FPGA cores have become available in recent years. In the big picture of MCU sales, EtherCAT usage is tiny. /Really/ tiny. Less tiny than five years ago, but still tiny. Making an EtherCAT peripheral in a MCU is not an insignificant investment for an MCU company - it would be a very big investment. They won't do that until they foresee a sizeable market - far greater than the automation market. Until then, it will be left to the few who are heavily involved in this sort of thing, such as Infineon (Siemens has always been a big player in the automation world). > > >> It's the stuff that runs factories, and programmed and set up by >> automation engineers that are a kind of cross between electricians and >> software developers. Characteristics of electronics in this field are >> that they are often quite expensive, but designed to fit together and >> "just work" even when made by different companies. Most of the stuff is >> made by relatively few large companies, rather than small companies. >> Implementing many of the protocols involved are quite horrible - badly >> specified (with large fees to be paid before you can even see the >> documents), overly complex, and typically require complicated XML-based >> "descriptors" that make USB descriptors look simple. But while that >> stuff makes them unpleasant to implement, it makes them very easy to use >> for the people actually making the automation setups. >> >> EtherCAT is also quite complicated, but a lot of it is handled by >> dedicated slave controller chips and software stacks that are available. > > So what sort of price premium are these peripheral chips adding to the BoM? > I don't deal with prices at that level, but Digikey puts them at about $10. >> >> My point was that XMOS could have made something /different/. Something >> that is known well enough for people to see the point even if they >> hadn't thought of using EtherCAT themselves (there is a Wikipedia entry, >> and plenty of Youtube videos on EtherCAT), but not so standard that >> everyone and their cat has support. (XMOS /have/ done that with the >> audio stuff.) > > You are suggesting that EtherCAT could be the "killer app" for XMOS? I don't know. But as with virtually every other type of peripheral, once the demand increases it will be part of everything from 8051s to high end ARMs. > No, I have /not/ been suggesting EtherCAT would be a killer app for XMOS. You seem to have combined various posts, adding 2 plus 3 to get 17. I said it would be a good example of the kind of thing you could do with an XMOS that you could not easily do with a standard MCU. Of course /some/ people might buy an XMOS because they want EtherCAT. But demo applications and examples are primarily marketing - it's about showing how great the chip and tools are at doing one thing, so that customers will use the device for their own strange needs. Far more people would use a standard Ethernet core than an EtherCAT core, but the EtherCAT core would be a better advertisement for the chip and toolset. >>> >> >> It is a type of MAC, but not a normal Ethernet MAC. The physical side >> (the PHY) is the same. But where an Ethernet MAC reads incoming packets >> in and stores them in ram somewhere, and collects outgoing packets from >> ram and sends them out, an EtherCAT MAC reads and writes bits of the >> packet while passing it on towards the next node. > > Ok, sounds like there is a lot more to it. I guess I'll have to read up about it at some point. > > I'm happy to work on an EtherCAT design for an FPGA. I'm not really in the business of selling IP but it's a possibility. Maybe program it into an Ice40 chip and sell it as a product. They have non-volatile, one time programmable config memory. So they can work as preprogrammed devices. > I have no doubt that you have the ability to make an EtherCAT core in an FPGA. But I have absolutely no idea whether it would be a good economic investment for you to do so. And while you will probably find it interesting to read a little about it, I would not think making an EtherCAT core is the kind of project you might do for fun. >> I said I haven't needed them, except for one project a fair number of >> years ago. It is even longer since I have needed an FPGA (though a >> number of our customers have FPGA boards). > > I've realized for a number of years FPGAs are underutilized. It's largely a matter of unfamiliarity or misconceptions. I still run into people who think they have to be high power consumption devices. They can be small, power efficient and high performance all in a single chip. Development difficulty is overstated a lot too. I find them much easier to work with than MCUs. > Habit and familiarity is the key. Very few people find them easier to work with than MCUs, even though /you/ do. > That's why I feel the XMOS has a limited niche between MCUs and FPGAs. They really aren't general purpose because they are pricey. An FPGA can be cheaper in many situations. But FPGAs aren't great for a full TCP/IP stack, etc. So different horses for different courses. > On that last sentiment, I hope we can all agree!
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-21 16:56 +0100 |
| Message-ID | <UIEnG.169463$e16.52704@fx41.am4> |
| In reply to | #29566 |
On 21/04/20 16:25, David Brown wrote: > On 21/04/2020 15:15, Rick C wrote: >> On Tuesday, April 21, 2020 at 8:02:18 AM UTC-4, David Brown wrote: >> You are suggesting that EtherCAT could be the "killer app" for XMOS? I don't >> know. But as with virtually every other type of peripheral, once the demand >> increases it will be part of everything from 8051s to high end ARMs. >> > > No, I have /not/ been suggesting EtherCAT would be a killer app for XMOS. You > seem to have combined various posts, adding 2 plus 3 to get 17. Yes. Rick's assertion caused my eyebrows to go up as well! >> I've realized for a number of years FPGAs are underutilized. It's largely a >> matter of unfamiliarity or misconceptions. I still run into people who think >> they have to be high power consumption devices. They can be small, power >> efficient and high performance all in a single chip. Development difficulty >> is overstated a lot too. I find them much easier to work with than MCUs. >> > > Habit and familiarity is the key. Very few people find them easier to work with > than MCUs, even though /you/ do. Precisely. Not many people have designed everything from analogue electronics, vanilla digital electronics, FPGA and similar, hard realtime mission critical programs, soft realtime telecom systems, and CRUD applications. I've done all of those (and more) and know their relative strengths and weaknesses. Far too many people have only done one or two of those, and then use hammers to insert screws. >> That's why I feel the XMOS has a limited niche between MCUs and FPGAs. They >> really aren't general purpose because they are pricey. An FPGA can be cheaper >> in many situations. But FPGAs aren't great for a full TCP/IP stack, etc. So >> different horses for different courses. >> > > On that last sentiment, I hope we can all agree! I certainly can :)
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-21 12:42 -0700 |
| Message-ID | <bd177c18-7faa-495c-bbcd-bc5b26c7110e@googlegroups.com> |
| In reply to | #29566 |
On Tuesday, April 21, 2020 at 11:25:37 AM UTC-4, David Brown wrote: > On 21/04/2020 15:15, Rick C wrote: > > On Tuesday, April 21, 2020 at 8:02:18 AM UTC-4, David Brown wrote: > >> On 21/04/2020 02:36, Rick C wrote: > >>> On Monday, April 20, 2020 at 9:58:09 AM UTC-4, David Brown wrote: > >>>> On 18/04/2020 21:38, Rick C wrote: > >>>>> On Saturday, April 18, 2020 at 9:06:57 AM UTC-4, David Brown > >>>>> wrote: > >>>>>> > >> > >>>> I need an MCU with 4 EtherCAT slave channels. There are exactly 0 > >>>> on the market. There are only two or three in total - from all > >>>> manufacturers together - with even /one/ EtherCAT slave. > >>> > >>> Yes, because EtherCAT is not widely used at the moment. I had never > >>> heard of it. When I read about it I see some car makers are looking > >>> at adopting it. Once that happens there will be MCUs supporting the > >>> interface. Until then it is a niche market. Am I wrong? I don't > >>> see any indication there is much out there either in the supply or > >>> demand side. > >>> > >> > >> EtherCAT has been increasingly popular in industrial automation (the > >> world of Programmable Logic Controllers, Profibus, Frequency Converters, > >> etc.). > > > > You say "increasingly popular" but if it were being used in higher volumes MCUs with EtherCAT interfaces would be available. MCU makers aren't stupid and love to have any advantage over the competition they can find. > > > > So "popular" has to be something other than unit volume. > > I wrote "increasingly popular", because it is becoming increasingly > popular. That means both that more and more people are using EtherCAT > devices, more and more EtherCAT devices are being installed, more and > more EtherCAT devices are being developed, more and more EtherCAT MCUs, > standand-alone peripherals, and FPGA cores have become available in > recent years. > > In the big picture of MCU sales, EtherCAT usage is tiny. /Really/ tiny. > Less tiny than five years ago, but still tiny. Making an EtherCAT > peripheral in a MCU is not an insignificant investment for an MCU > company - it would be a very big investment. They won't do that until > they foresee a sizeable market - far greater than the automation market. > Until then, it will be left to the few who are heavily involved in > this sort of thing, such as Infineon (Siemens has always been a big > player in the automation world). So your use of "more and more" is not relevant to the MCU market which is what I've been talking about. I don't know anything about the automation market, so I have to assume it is not so large if the MCU makers are ignoring a peripheral that is used "more and more" in that market for some value of "more and more". I know designing a CPU chip is costly, but the cost depends greatly on the process used. The CPUs in a cell phone cost millions just for the mask set. CPUs on the 150 nm node with 256 kB of flash, not so much. What level of CPU is married to a EtherCAT interface in the designs you see? I was thinking a CM4 would be appropriate. > >> It's the stuff that runs factories, and programmed and set up by > >> automation engineers that are a kind of cross between electricians and > >> software developers. Characteristics of electronics in this field are > >> that they are often quite expensive, but designed to fit together and > >> "just work" even when made by different companies. Most of the stuff is > >> made by relatively few large companies, rather than small companies. > >> Implementing many of the protocols involved are quite horrible - badly > >> specified (with large fees to be paid before you can even see the > >> documents), overly complex, and typically require complicated XML-based > >> "descriptors" that make USB descriptors look simple. But while that > >> stuff makes them unpleasant to implement, it makes them very easy to use > >> for the people actually making the automation setups. > >> > >> EtherCAT is also quite complicated, but a lot of it is handled by > >> dedicated slave controller chips and software stacks that are available. > > > > So what sort of price premium are these peripheral chips adding to the BoM? > > > > I don't deal with prices at that level, but Digikey puts them at about $10. That's pretty significant compared to a $5 XMOS or a $3 MCU chip. > >> My point was that XMOS could have made something /different/. Something > >> that is known well enough for people to see the point even if they > >> hadn't thought of using EtherCAT themselves (there is a Wikipedia entry, > >> and plenty of Youtube videos on EtherCAT), but not so standard that > >> everyone and their cat has support. (XMOS /have/ done that with the > >> audio stuff.) > > > > You are suggesting that EtherCAT could be the "killer app" for XMOS? I don't know. But as with virtually every other type of peripheral, once the demand increases it will be part of everything from 8051s to high end ARMs. > > > > No, I have /not/ been suggesting EtherCAT would be a killer app for > XMOS. You seem to have combined various posts, adding 2 plus 3 to get 17. Ok, whatever. I asked a question. > I said it would be a good example of the kind of thing you could do with > an XMOS that you could not easily do with a standard MCU. Of course > /some/ people might buy an XMOS because they want EtherCAT. But demo > applications and examples are primarily marketing - it's about showing > how great the chip and tools are at doing one thing, so that customers > will use the device for their own strange needs. Far more people would > use a standard Ethernet core than an EtherCAT core, but the EtherCAT > core would be a better advertisement for the chip and toolset. Not sure why you say demo apps are about marketing. Provide a reference design and people will use it. If the EtherCAT chip is $10 and the XMOS is $5 and you can put one on a single CPU in the chip, that's a slam dunk. The market may not be large for the MCU world, but it sounds large for XMOS. > >> It is a type of MAC, but not a normal Ethernet MAC. The physical side > >> (the PHY) is the same. But where an Ethernet MAC reads incoming packets > >> in and stores them in ram somewhere, and collects outgoing packets from > >> ram and sends them out, an EtherCAT MAC reads and writes bits of the > >> packet while passing it on towards the next node. > > > > Ok, sounds like there is a lot more to it. I guess I'll have to read up about it at some point. > > > > I'm happy to work on an EtherCAT design for an FPGA. I'm not really in the business of selling IP but it's a possibility. Maybe program it into an Ice40 chip and sell it as a product. They have non-volatile, one time programmable config memory. So they can work as preprogrammed devices. > > > > I have no doubt that you have the ability to make an EtherCAT core in an > FPGA. But I have absolutely no idea whether it would be a good economic > investment for you to do so. And while you will probably find it > interesting to read a little about it, I would not think making an > EtherCAT core is the kind of project you might do for fun. The problem I usually have with this sort of thing is finding enough spec to be able to have confidence I can produce something that will work well. If the EtherCAT interface is as large as a Ethernet MAC I'm not sure I could put more than one in a small, $3 FPGA. It's been a long time since I worked with Ethernet at a low level and I can't recall much of the detail. I think I was working more with ATM over T/E networks. One of the other engineers on the team was doing an Ethernet design and I was advising him. He was funny. He knew what he was doing, but every once in a while he wanted to be assured he was on the right track I think. He'd come to my office, ask a few questions. Then as I started to sink my teeth into the problem he'd pack up and leave. lol Other people's designs are always more fun. > >> I said I haven't needed them, except for one project a fair number of > >> years ago. It is even longer since I have needed an FPGA (though a > >> number of our customers have FPGA boards). > > > > I've realized for a number of years FPGAs are underutilized. It's largely a matter of unfamiliarity or misconceptions. I still run into people who think they have to be high power consumption devices. They can be small, power efficient and high performance all in a single chip. Development difficulty is overstated a lot too. I find them much easier to work with than MCUs. > > > > Habit and familiarity is the key. Very few people find them easier to > work with than MCUs, even though /you/ do. Yep. I don't restrict myself to any given techniques. I don't find the XMOS good for much other than a small set of apps that can utilize the independent cores and at the same time need the complexity of larger bodies of software. Anything that doesn't need the multiprocessing can be done on an MCU and anything that doesn't need a larger code base can be done in an FPGA, likely for less money in both cases. I like the idea of the GA144 and have a couple of design ideas where it would be a good fit, I just haven't bothered to explore them much more than proving they could work. I would like to get back to my soft processor designs. But I have some real work on my test fixture I've put off for some time now. > > That's why I feel the XMOS has a limited niche between MCUs and FPGAs. They really aren't general purpose because they are pricey. An FPGA can be cheaper in many situations. But FPGAs aren't great for a full TCP/IP stack, etc. So different horses for different courses. > > > > On that last sentiment, I hope we can all agree! I've never said anything different. I just don't find a wide range of apps for the XMOS and apparently the market doesn't either. I was really surprised they only had 8 million in revenue a year or two ago. That doesn't even show up on the semiconductor radar. -- Rick C. ----- Get 1,000 miles of free Supercharging ----- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-21 23:16 +0100 |
| Message-ID | <4hKnG.42671$hQ3.31216@fx26.am4> |
| In reply to | #29577 |
On 21/04/20 20:42, Rick C wrote: > Yep. I don't restrict myself to any given techniques. I don't find the XMOS > good for much other than a small set of apps that can utilize the independent > cores and at the same time need the complexity of larger bodies of software. > Anything that doesn't need the multiprocessing can be done on an MCU and > anything that doesn't need a larger code base can be done in an FPGA, likely > for less money in both cases. It is noteworthy that you are able to confidently state that, even though you can't be bothered to read a four page article summarising the XMOS ecosystem's unique features and benefits. If you don't read, you can't understand, and statements become highly dubious.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-22 11:10 +0200 |
| Message-ID | <r7p1mi$grr$1@dont-email.me> |
| In reply to | #29577 |
On 21/04/2020 21:42, Rick C wrote: > On Tuesday, April 21, 2020 at 11:25:37 AM UTC-4, David Brown wrote: >> On 21/04/2020 15:15, Rick C wrote: >>> On Tuesday, April 21, 2020 at 8:02:18 AM UTC-4, David Brown >>> wrote: >>>> On 21/04/2020 02:36, Rick C wrote: >>>>> On Monday, April 20, 2020 at 9:58:09 AM UTC-4, David Brown >>>>> wrote: >>>>>> On 18/04/2020 21:38, Rick C wrote: >>>>>>> On Saturday, April 18, 2020 at 9:06:57 AM UTC-4, David >>>>>>> Brown wrote: >>>>>>>> >>>> >>>>>> I need an MCU with 4 EtherCAT slave channels. There are >>>>>> exactly 0 on the market. There are only two or three in >>>>>> total - from all manufacturers together - with even /one/ >>>>>> EtherCAT slave. >>>>> >>>>> Yes, because EtherCAT is not widely used at the moment. I >>>>> had never heard of it. When I read about it I see some car >>>>> makers are looking at adopting it. Once that happens there >>>>> will be MCUs supporting the interface. Until then it is a >>>>> niche market. Am I wrong? I don't see any indication there >>>>> is much out there either in the supply or demand side. >>>>> >>>> >>>> EtherCAT has been increasingly popular in industrial automation >>>> (the world of Programmable Logic Controllers, Profibus, >>>> Frequency Converters, etc.). >>> >>> You say "increasingly popular" but if it were being used in >>> higher volumes MCUs with EtherCAT interfaces would be available. >>> MCU makers aren't stupid and love to have any advantage over the >>> competition they can find. >>> >>> So "popular" has to be something other than unit volume. >> >> I wrote "increasingly popular", because it is becoming >> increasingly popular. That means both that more and more people >> are using EtherCAT devices, more and more EtherCAT devices are >> being installed, more and more EtherCAT devices are being >> developed, more and more EtherCAT MCUs, standand-alone peripherals, >> and FPGA cores have become available in recent years. >> >> In the big picture of MCU sales, EtherCAT usage is tiny. /Really/ >> tiny. Less tiny than five years ago, but still tiny. Making an >> EtherCAT peripheral in a MCU is not an insignificant investment for >> an MCU company - it would be a very big investment. They won't do >> that until they foresee a sizeable market - far greater than the >> automation market. Until then, it will be left to the few who are >> heavily involved in this sort of thing, such as Infineon (Siemens >> has always been a big player in the automation world). > > So your use of "more and more" is not relevant to the MCU market > which is what I've been talking about. I am not sure how I could have been clearer. > > I don't know anything about the automation market, so I have to > assume it is not so large if the MCU makers are ignoring a peripheral > that is used "more and more" in that market for some value of "more > and more". Relatively speaking, it is not a big market - numbers are a lot smaller than automotive or consumer markets. And it is quite a conservative market, with people using the same devices for decades. (This also means manufacturers have to commit to very long product lifetimes in this branch.) I also did not say, or imply, that MCU makers are ignoring this peripheral. I said they don't make many devices that support it - and I said that the number of devices supporting EtherCAT has been increasing in recent years. I am sure the big MCU makers are following EtherCAT closely, and I am sure they have devices under development. When Ford, or Toyota, or Volkswagen tells NXP and Texas Instruments that they are interested in small microcontrollers with EtherCAT slave devices, the MCU makers are /not/ going to say "EtherCAT? What's that?". They are going to say "We've got some ideas under development. What combination of cpu, memories and peripherals do you want? We'll put the bricks together and do some samples". For all I know, some of these companies already have devices for their big customers - these can be made years before mere mortals get to hear about them. > > I know designing a CPU chip is costly, but the cost depends greatly > on the process used. The CPUs in a cell phone cost millions just for > the mask set. CPUs on the 150 nm node with 256 kB of flash, not so > much. What level of CPU is married to a EtherCAT interface in the > designs you see? I was thinking a CM4 would be appropriate. > A Cortex-M4 would be fine for simpler EtherCAT slaves. It's possible to use them with even smaller devices (or no microcontroller at all - EtherCAT slave peripherals usually support a "remote digital I/O" mode). But based on the size and speed needed for a EtherCAT module it would be silly /not/ to have something like an M4. (We are using an M7 chip with them.) > >>>> It's the stuff that runs factories, and programmed and set up >>>> by automation engineers that are a kind of cross between >>>> electricians and software developers. Characteristics of >>>> electronics in this field are that they are often quite >>>> expensive, but designed to fit together and "just work" even >>>> when made by different companies. Most of the stuff is made by >>>> relatively few large companies, rather than small companies. >>>> Implementing many of the protocols involved are quite horrible >>>> - badly specified (with large fees to be paid before you can >>>> even see the documents), overly complex, and typically require >>>> complicated XML-based "descriptors" that make USB descriptors >>>> look simple. But while that stuff makes them unpleasant to >>>> implement, it makes them very easy to use for the people >>>> actually making the automation setups. >>>> >>>> EtherCAT is also quite complicated, but a lot of it is handled >>>> by dedicated slave controller chips and software stacks that >>>> are available. >>> >>> So what sort of price premium are these peripheral chips adding >>> to the BoM? >>> >> >> I don't deal with prices at that level, but Digikey puts them at >> about $10. > > That's pretty significant compared to a $5 XMOS or a $3 MCU chip. > Yes. But development costs, development time, development resources are all important too. BOM prices are rarely irrelevant, but not always the most important factor. Also, those chips do a good deal more than we can get from a tiny XMOS - we'd need a much bigger XMOS and external PHY's. Maybe XMOS with EtherCAT modules would be a BOM cost win, maybe not. >> No, I have /not/ been suggesting EtherCAT would be a killer app >> for XMOS. You seem to have combined various posts, adding 2 plus 3 >> to get 17. > > Ok, whatever. I asked a question. You did - but that question showed that you badly misunderstood other things I wrote. Perhaps the quantity of posts here, and their lengths, has simply got out of hand. It becomes impossible to track everything that is said. I know that I have to snip and skimp on posts.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-22 08:09 -0700 |
| Message-ID | <146b58d2-ba8a-424c-a88c-560132597cbb@googlegroups.com> |
| In reply to | #29586 |
On Wednesday, April 22, 2020 at 5:10:47 AM UTC-4, David Brown wrote: > On 21/04/2020 21:42, Rick C wrote: > > On Tuesday, April 21, 2020 at 11:25:37 AM UTC-4, David Brown wrote: > >> On 21/04/2020 15:15, Rick C wrote: > >>> On Tuesday, April 21, 2020 at 8:02:18 AM UTC-4, David Brown > >>> wrote: > >>>> On 21/04/2020 02:36, Rick C wrote: > >>>>> On Monday, April 20, 2020 at 9:58:09 AM UTC-4, David Brown > >>>>> wrote: > >>>>>> On 18/04/2020 21:38, Rick C wrote: > >>>>>>> On Saturday, April 18, 2020 at 9:06:57 AM UTC-4, David > >>>>>>> Brown wrote: > >>>>>>>> > >>>> > >>>>>> I need an MCU with 4 EtherCAT slave channels. There are > >>>>>> exactly 0 on the market. There are only two or three in > >>>>>> total - from all manufacturers together - with even /one/ > >>>>>> EtherCAT slave. > >>>>> > >>>>> Yes, because EtherCAT is not widely used at the moment. I > >>>>> had never heard of it. When I read about it I see some car > >>>>> makers are looking at adopting it. Once that happens there > >>>>> will be MCUs supporting the interface. Until then it is a > >>>>> niche market. Am I wrong? I don't see any indication there > >>>>> is much out there either in the supply or demand side. > >>>>> > >>>> > >>>> EtherCAT has been increasingly popular in industrial automation > >>>> (the world of Programmable Logic Controllers, Profibus, > >>>> Frequency Converters, etc.). > >>> > >>> You say "increasingly popular" but if it were being used in > >>> higher volumes MCUs with EtherCAT interfaces would be available. > >>> MCU makers aren't stupid and love to have any advantage over the > >>> competition they can find. > >>> > >>> So "popular" has to be something other than unit volume. > >> > >> I wrote "increasingly popular", because it is becoming > >> increasingly popular. That means both that more and more people > >> are using EtherCAT devices, more and more EtherCAT devices are > >> being installed, more and more EtherCAT devices are being > >> developed, more and more EtherCAT MCUs, standand-alone peripherals, > >> and FPGA cores have become available in recent years. > >> > >> In the big picture of MCU sales, EtherCAT usage is tiny. /Really/ > >> tiny. Less tiny than five years ago, but still tiny. Making an > >> EtherCAT peripheral in a MCU is not an insignificant investment for > >> an MCU company - it would be a very big investment. They won't do > >> that until they foresee a sizeable market - far greater than the > >> automation market. Until then, it will be left to the few who are > >> heavily involved in this sort of thing, such as Infineon (Siemens > >> has always been a big player in the automation world). > > > > So your use of "more and more" is not relevant to the MCU market > > which is what I've been talking about. > > I am not sure how I could have been clearer. That is certainly less clear. > > I don't know anything about the automation market, so I have to > > assume it is not so large if the MCU makers are ignoring a peripheral > > that is used "more and more" in that market for some value of "more > > and more". > > Relatively speaking, it is not a big market - numbers are a lot smaller > than automotive or consumer markets. And it is quite a conservative > market, with people using the same devices for decades. (This also > means manufacturers have to commit to very long product lifetimes in > this branch.) We were discussing this in the context of an application for the XMOS device. Meanwhile it seems to have taken on a life of it's own. Bottom line is if it were much of a market at all there would be MCU with EtherCAT built in. Since there is not a very significant market, external chips are used to add EtherCAT to MCUs. It seems XMOS doesn't have sufficient resources to develop an EtherCAT library to promote their devices. > I also did not say, or imply, that MCU makers are ignoring this > peripheral. I said they don't make many devices that support it - and I > said that the number of devices supporting EtherCAT has been increasing > in recent years. I am sure the big MCU makers are following EtherCAT > closely, and I am sure they have devices under development. When Ford, > or Toyota, or Volkswagen tells NXP and Texas Instruments that they are > interested in small microcontrollers with EtherCAT slave devices, the > MCU makers are /not/ going to say "EtherCAT? What's that?". They are > going to say "We've got some ideas under development. What combination > of cpu, memories and peripherals do you want? We'll put the bricks > together and do some samples". For all I know, some of these companies > already have devices for their big customers - these can be made years > before mere mortals get to hear about them. I have zero info on what R&D the various MCU makers are doing. I don't care much either. I'm discussing what is done currently. > > I know designing a CPU chip is costly, but the cost depends greatly > > on the process used. The CPUs in a cell phone cost millions just for > > the mask set. CPUs on the 150 nm node with 256 kB of flash, not so > > much. What level of CPU is married to a EtherCAT interface in the > > designs you see? I was thinking a CM4 would be appropriate. > > > > A Cortex-M4 would be fine for simpler EtherCAT slaves. It's possible to > use them with even smaller devices (or no microcontroller at all - > EtherCAT slave peripherals usually support a "remote digital I/O" mode). > But based on the size and speed needed for a EtherCAT module it would > be silly /not/ to have something like an M4. (We are using an M7 chip > with them.) > > > > >>>> It's the stuff that runs factories, and programmed and set up > >>>> by automation engineers that are a kind of cross between > >>>> electricians and software developers. Characteristics of > >>>> electronics in this field are that they are often quite > >>>> expensive, but designed to fit together and "just work" even > >>>> when made by different companies. Most of the stuff is made by > >>>> relatively few large companies, rather than small companies. > >>>> Implementing many of the protocols involved are quite horrible > >>>> - badly specified (with large fees to be paid before you can > >>>> even see the documents), overly complex, and typically require > >>>> complicated XML-based "descriptors" that make USB descriptors > >>>> look simple. But while that stuff makes them unpleasant to > >>>> implement, it makes them very easy to use for the people > >>>> actually making the automation setups. > >>>> > >>>> EtherCAT is also quite complicated, but a lot of it is handled > >>>> by dedicated slave controller chips and software stacks that > >>>> are available. > >>> > >>> So what sort of price premium are these peripheral chips adding > >>> to the BoM? > >>> > >> > >> I don't deal with prices at that level, but Digikey puts them at > >> about $10. > > > > That's pretty significant compared to a $5 XMOS or a $3 MCU chip. > > > > Yes. But development costs, development time, development resources are > all important too. BOM prices are rarely irrelevant, but not always the > most important factor. Also, those chips do a good deal more than we > can get from a tiny XMOS - we'd need a much bigger XMOS and external > PHY's. Maybe XMOS with EtherCAT modules would be a BOM cost win, maybe not. Again, this indicates the market for these designs is not very large. It doesn't take a lot of volume, compared to what it takes for MCU makers to address a need, to amortize the development costs of a board design. If your amortized development time is a significant part of your unit costs, you are not on the MCU designer's radar for deciding what interfaces to include in devices. > >> No, I have /not/ been suggesting EtherCAT would be a killer app > >> for XMOS. You seem to have combined various posts, adding 2 plus 3 > >> to get 17. > > > > Ok, whatever. I asked a question. > > You did - but that question showed that you badly misunderstood other > things I wrote. > > Perhaps the quantity of posts here, and their lengths, has simply got > out of hand. It becomes impossible to track everything that is said. I > know that I have to snip and skimp on posts. I think you are addressing things I haven't been talking about. I'm just comparing XMOS to other devices for use in the different applications. EtherCAT came up and it seems to still be a relatively niche market for MCU makers. Actually, the whole XMOS thing was thread drift from the topic of soft CPU designs in FPGAs. -- Rick C. --+-- Get 1,000 miles of free Supercharging --+-- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-22 20:07 +0200 |
| Message-ID | <r7q15s$8kq$2@dont-email.me> |
| In reply to | #29590 |
On 22/04/2020 17:09, Rick C wrote: > Actually, the whole XMOS thing was thread drift from the topic of soft CPU designs in FPGAs. > There has been a great deal of drift in this thread! I don't know if you ever got much of an answer to your original question, but I think some of the branches have been interesting.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2020-04-18 13:09 -0700 |
| Message-ID | <87zhb8blo5.fsf@nightsong.com> |
| In reply to | #29497 |
David Brown <david.brown@hesbynett.no> writes: > I'd like a good way to do CSP stuff in C or C++. https://seastar.io ?
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-18 21:28 +0100 |
| Message-ID | <8qJmG.83474$e1n.2050@fx36.am4> |
| In reply to | #29504 |
On 18/04/20 21:09, Paul Rubin wrote: > David Brown <david.brown@hesbynett.no> writes: >> I'd like a good way to do CSP stuff in C or C++. > > https://seastar.io ? We are thinking of Tony Hoare's Concurrent Sequential Processes calculus. It doesn't look like that is the seastar offering. There are many many frameworks that split jobs across cores. They are trivial in Java, and I implemented a highly performant one for telecoms applications 16 years ago (gulp). The half-sync-half-async design pattern works very well in such applications.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2020-04-21 20:29 +0300 |
| Message-ID | <gq9u9fd265q2731ggfnajnlstvon0p8pk7@4ax.com> |
| In reply to | #29497 |
On Sat, 18 Apr 2020 15:06:53 +0200, David Brown <david.brown@hesbynett.no> wrote: > >Implementing an Ethernet MAC on an XMOS is pointless. Implementing an >EtherCAT slave is not going to be much harder for the XMOS than a normal >Ethernet MAC, but is impossible on any microcontroller without >specialised peripherals. Traditional industrial protocols, like Profibus and Modbus (with all their variants) have a quite high overhead Thus, if a slave only wants to communicate a few bits or a single byte over the network, it will suffer a very low transfer efficiency using standard protocols. With EtherCAT, it is possible to make very small nodes with only a few bits added/removed from the frame circulating around the industrial plants with only a few bit time additional propagation delay in each node. So it looks good. However, EtherCAT nodes are still quite expensive and if you add/drop only a few bits in each node doesn't make economical sense. What is the point of using multicore processors, if a single core can perform the basic EtherCAT node functionality. You can't cut the multicore chip and distribute it to multiple physically separate nodes:-). In addition, if there are dozens of series connected twisted pair connectors, what is the electromechanical reliability of each connection ? A single fault will prevent the Ethernet frame circulating back to the master. I much more prefer a dual layer approach, with CANbus (or CAN FD) up to a few meters transferring a few bits or a byte or two around the CAN bus and using concentrator nodes with communicate to a higher level systems using some traditional protocols, transferring perhaps 100 bytes in a single transaction.
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2020-04-21 18:10 +0000 |
| Message-ID | <r7ncv1$ggu$1@reader2.panix.com> |
| In reply to | #29575 |
On 2020-04-21, upsidedown@downunder.com <upsidedown@downunder.com> wrote: > With EtherCAT, it is possible to make very small nodes with only a few > bits added/removed from the frame circulating around the industrial > plants with only a few bit time additional propagation delay in each > node. So it looks good. For something like simple digital I/O, you don't need a uController at all, the Beckhoff ET1100 EtherCAT controller can act as a stand-alone slave device. > What is the point of using multicore processors, if a single core can > perform the basic EtherCAT node functionality. What if you also want to run a web server and some other heavy-duty, encrypted, protocols under Linux in your EtherCAT slave? The most practical way to do that is with something like the Renesas RZ/N1D which has an EtherCAT controller, a Cortex M3 optimized for real-time stuff, and a couple Cortex A7 cores for running Linux. [There are other vendors with similar mult-core uControllers.] > In addition, if there are dozens of series connected twisted pair > connectors, what is the electromechanical reliability of each > connection ? A single fault will prevent the Ethernet frame > circulating back to the master. If single point of failure is an issue, then you can connect the EtherCAT devices in a loop to get some redundancy. -- Grant
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2020-04-22 09:54 +0300 |
| Message-ID | <igov9f9aptfvsvb1ihpbecnps1ud6uhs1h@4ax.com> |
| In reply to | #29576 |
On Tue, 21 Apr 2020 18:10:41 +0000 (UTC), Grant Edwards <invalid@invalid.invalid> wrote: >On 2020-04-21, upsidedown@downunder.com <upsidedown@downunder.com> wrote: > >> With EtherCAT, it is possible to make very small nodes with only a few >> bits added/removed from the frame circulating around the industrial >> plants with only a few bit time additional propagation delay in each >> node. So it looks good. > >For something like simple digital I/O, you don't need a uController at >all, the Beckhoff ET1100 EtherCAT controller can act as a stand-alone >slave device. With Beckhoff bus terminals, you can stack a number of simple I/O modules together. The module could be as simple as a 2 digital input or an other with 2 digital outputs or more complicated I/O modules. At the end of the stack you just attach a fieldbus module. This could be e.g. Modbus, CAN bus or in your case an EtherCAT module. You can change e.g. from CAN to EtherCAT by simply replacing the fieldbus module at the end. No need to disassemble the I/O module stack. Even this example shows the problem of interfacing only a few I/O bits to a higher level system. It doesn't make sense to make fieldbus interfaces if you just need say 2 digital inputs. In this case, the Beckhoff bus terminal stack acts as a concentrator, so that discrete signals from a larger area is wired into the module stack. While logically the EtherCAT protocol would allow nodes to effectively handle only a few digital I/O on each node, it is not economically practical. Of course, if EtherCAT I(O controllers can be made into 8 to 14 pin chips, the situation would be different (2 x power, 2 x Ethernet, 2-4 digital I/O pins), the situation would be different. But you would still need two magnetics. > >> What is the point of using multicore processors, if a single core can >> perform the basic EtherCAT node functionality. > >What if you also want to run a web server and some other heavy-duty, >encrypted, protocols under Linux in your EtherCAT slave? Would one really want to have a large number of such stations all around a plant, each exchanging only a few at bits ? Use some hierarchical system, but the expected advantage of EtherCAT is lost. >The most >practical way to do that is with something like the Renesas RZ/N1D >which has an EtherCAT controller, a Cortex M3 optimized for real-time >stuff, and a couple Cortex A7 cores for running Linux. [There are >other vendors with similar mult-core uControllers.] > >> In addition, if there are dozens of series connected twisted pair >> connectors, what is the electromechanical reliability of each >> connection ? A single fault will prevent the Ethernet frame >> circulating back to the master. > >If single point of failure is an issue, then you can connect the >EtherCAT devices in a loop to get some redundancy. The EtherCAT has the same reliability issues as 10Base2 and 10Base5 coaxial Ethernets with a large number of connections to a single bus.
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2020-04-22 13:19 +0000 |
| Message-ID | <r7pg9h$9av$1@reader2.panix.com> |
| In reply to | #29585 |
On 2020-04-22, upsidedown@downunder.com <upsidedown@downunder.com> wrote: > >>> What is the point of using multicore processors, if a single core >>> can perform the basic EtherCAT node functionality. >> >>What if you also want to run a web server and some other heavy-duty, >>encrypted, protocols under Linux in your EtherCAT slave? > > Would one really want to have a large number of such stations all > around a plant, each exchanging only a few at bits? What makes you think the multi-core EtherCAT slave is exchanging only a few bits. The ones with multi-core processors are typically I/O hubs that can handle many hundreds of bits. You asked what's the point of using a multi-core processor in an EtherCAT slave. I told you the reason why people design them that way: because they need the CPU power to handle other protocols simultaneously or do things like image processing. > Use some hierarchical system, but the expected advantage of EtherCAT > is lost. Generally, the multi-core EtherCAT slave _is_ part of a hierarchical system. For example the EtherCAT slave might be an IO-Link master with 8 attached IO-Link sensors, each of which can handle 32 bytes of input and 32 bytes of output. You seem to be arguing against using a multi-core processor in an EtherCAT slave does nothing other than handle a few bits of DIO. Nobody does that. Nobody is proposing that. >>> In addition, if there are dozens of series connected twisted pair >>> connectors, what is the electromechanical reliability of each >>> connection ? A single fault will prevent the Ethernet frame >>> circulating back to the master. >> >>If single point of failure is an issue, then you can connect the >>EtherCAT devices in a loop to get some redundancy. > > The EtherCAT has the same reliability issues as 10Base2 and 10Base5 > coaxial Ethernets with a large number of connections to a single > bus. You were worried the entire network was susceptible to single-point connector failure. With a ring, it's not, you'll need a two-point failure to loose comms.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2020-04-22 18:09 +0300 |
| Message-ID | <nhm0af5jqmbbrodmjuuga89r39mh0efr7i@4ax.com> |
| In reply to | #29589 |
On Wed, 22 Apr 2020 13:19:45 +0000 (UTC), Grant Edwards <invalid@invalid.invalid> wrote: >On 2020-04-22, upsidedown@downunder.com <upsidedown@downunder.com> wrote: >> >>>> What is the point of using multicore processors, if a single core >>>> can perform the basic EtherCAT node functionality. >>> >>>What if you also want to run a web server and some other heavy-duty, >>>encrypted, protocols under Linux in your EtherCAT slave? >> >> Would one really want to have a large number of such stations all >> around a plant, each exchanging only a few at bits? > >What makes you think the multi-core EtherCAT slave is exchanging only >a few bits. The ones with multi-core processors are typically I/O >hubs that can handle many hundreds of bits. You asked what's the >point of using a multi-core processor in an EtherCAT slave. I told >you the reason why people design them that way: because they need the >CPU power to handle other protocols simultaneously or do things like >image processing. My main point was that if you are going to transfer a significant number of bytes/node (say at least 10 bytes), why use EtherCAT in the first place ? You could then use any standard garden variety RS-422/485 or 10/100/1000BaseT hardware with some standard protocol, even Modbus RTU/UDP/TCP. If the node complexity justifies using xCore, then most likely is going to transfer a lot of data to the outside world. The EtherCAT+xCore combination doesn't make much sense, but EtherCAT alone or xCore alone can be quite competitive in their own niches. > >> Use some hierarchical system, but the expected advantage of EtherCAT >> is lost. > >Generally, the multi-core EtherCAT slave _is_ part of a hierarchical >system. For example the EtherCAT slave might be an IO-Link master >with 8 attached IO-Link sensors, each of which can handle 32 bytes of >input and 32 bytes of output. > >You seem to be arguing against using a multi-core processor in an >EtherCAT slave does nothing other than handle a few bits of DIO. > >Nobody does that. > >Nobody is proposing that. > >>>> In addition, if there are dozens of series connected twisted pair >>>> connectors, what is the electromechanical reliability of each >>>> connection ? A single fault will prevent the Ethernet frame >>>> circulating back to the master. >>> >>>If single point of failure is an issue, then you can connect the >>>EtherCAT devices in a loop to get some redundancy. >> >> The EtherCAT has the same reliability issues as 10Base2 and 10Base5 >> coaxial Ethernets with a large number of connections to a single >> bus. > >You were worried the entire network was susceptible to single-point >connector failure. With a ring, it's not, you'll need a two-point >failure to loose comms.
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web