USB and PCI (was Re: DP8473A (was IBM Displaywriter

On Mon, Dec 31, 2012 at 05:49:35PM +0100, GerardCJAT wrote: Good question. XMOS has been claiming it's real since last spring, and the last date I got for public release was Jan 2013. As of a couple of weeks ago, Future has stock, but they're being douchey about it (screening buyers). Still, I'm hoping that means Digikey will have it for sale to anybody within a month or two, so I'm just putting the finishing touches on a prototype PCB layout. That part's definitely true. These days you finally have lots of choices with USB. I already have working USB code in a PIC18 design, but it's just not quite fast or flexible enough for bit-banging the interfaces I care about. Yes yes yes! It's *wonderful*. Not that I've done much other multi-core stuff (just x86, unless emulation counts) but they've done multi-core really really cleanly (and then written a multi-threaded mutated C compiler that erases most of the benefits, but if you program it in assembly you get them all, plus it's easier to control the lengths of your code paths when it matters). The pro-UNIX bias of the designers is obvious (for better or for worse), so there's a "get resource" instruction that acts like a UNIX "open()" call (which gives you a handle which you can use in I/O instructions to talk to timers, channels, locks, or other threads), and then the event-wait mechanism works a lot like select() (except with a vector for each handle), so activity on any handle will wake you out of a "wait" instruction. So each hyperthread's main loop isn't even a loop -- you just handle an event, re-arm it, and do another "wait" instruction. It wouldn't always be, but because it's done so cleanly in the XMOS chips it helps much more than it hurts. So in my ISA FDC, there's one hyperthread which does nothing but handle accesses from the ISA bus, another which does nothing but read/write the FDD bitstream, and another which acts as a FIFO between the two. That's much easier to get working than having a tangled mass of interrupts and worrying about whether each event will be handled fast enough even if something else interrupts at just the wrong time. The instruction set is horrible (except for a few very useful things like the CRC, bit-reverse, and byte-reverse instructions), but not bad enough to get in the way of getting work done. And having instructions execute every 10 ns, almost no matter what (until you have >4 hyperthreads and then it derates to 20 ns if you use all 8 slots), is great for bit-banging. John Wilson D Bit