I've only been "on" this task since yesterday, and have had to deal with both the "newness" of this information, at least to me, and also the not-too-clear explanation of the problem from my colleague. That's why I asked the question here, since there are a few users who've already encountered this information, hence, have knowledge of (1) where it is documented, and (2) what its impact is.

What I have to do is to demodulate an encoded stream of data being sampled in the Mode 0 serial channel. Each bit is represented by what amounts to a two-bit symbol. Each bit is sampled four times. A table-lookup is one way in which a symbol, so encoded and oversampled, can be translated. The lookup table is a 256-entry table, hence, the content of A can ideally serve as an index. However, the decision as to the table is made on the basis of a flag which is residue from the result obtained from the previous byte. Additionally, there are occasional (very rare, relative to the bit rate) timing corrections that have to be made due to slight variations in the data rate due to difference between the crystals used in the MCU and the data source. There are also other variations in rate that require this timing adjustment.

All this has to be accomodated in the code. The key is predictability of the MCU's execution. The presence of a cache, pipeline, prefetch queue, or whatever, doesn't matter, so long as it's characterized correctly. Once that's done, it's entirely predictable, if not jitter-free.

Is this information in the datasheet or in the User Guide? Both? I spent some time searching in Acrobat Reader, just to get a "feel" for this feature (I didn't get one!), but haven't yet sat down and read the doc's yet. I'm still trying to assess whether this part can do the job "better" or more easily than the somewhat slower Maxim/Dallas part.

RE