IIRC, the PIC's don't manage data tables particularly well, and you KNOW how I feel about ATMEL parts (AVR included).

The deal is that, as I said before, I have to demodulate a stream of encoded data. I intend to do that by table lookup, first by doing a "barrel shift" such that a transition is aligned at the center of the nybble and then proceeding to translate the eight bits in a 4x oversampled byte into two bits and splicing them into an output byte under construction. That requires a pretty long loop, since each bit pair requires a different version of the basic loop, and a timing adjustment (the barrlel-shift) is possible in each of several versions at each step of the way. I'll be receiving bits at a 1/5 microsecond rate. I'll have quite a large (at least viewed from a PIC) table and several of them, in which to do the lookup, and it all has to be in exactly a fifth of a microsecond. What's more, no matter which path I follow through the loop, it always has to be of exactly the same duration.

The principal problem, in the case of the Maxim/Dallas part, is that the code has to live in the internal XRAM, because that's the only place where I can safely run it at the required rate, and that very fact has yet to be proven. They specify their part to operate at 33 MHz tops, though their original tests and advertising said they'd run at 50 MHz. It turned out their FLASH was too slow, so they modified the specification. Now that they've discontinued their DS89C420, which was the one originally touted at running 50 MIPS, it may actually not be possible to run the thing at 40, MHz. At that rate in the Maxim MCU, I have two instruction cycles per bit. As most of the instructions are two-cycles, that's one instruction. If one of them is a DPTR load, I'm in trouble.

OTOH, if the SiLabs parts can be made to work, then just maybe I can build the loop and setup the various features such that I can operate at twice that rate. Unfortunately, I can't use the internal shift register in the SiLabs part, since it only operates at 1/12 the system clock, so I have to bit-bang, with the process interleaved with the other instructions I have to perform. That will undoubtedly force a bit of jitter into the sampling process, but will probably stay within reasonable limits of accuracy, particularly if I can get the thing to run at precisely 100 MHz, which will give me 5 instructions per bit. I'm going to have to spend some time away from the phone and other disturbances in order to skull this out.

If I have to use external hardware just to assemble and disassemble the bytes, I can probably do a lot of it in hardware, thereby allowing the use of a much slower MCU and less stringent code requirements. Who knows? I may be able to do without the MCU altogether.

RE