First of all, I've always (note the usage?) said that there are applications in which the 8255 will work. There are, obviously, also applications in which it won't. Naturally, there are applications in which the SiLabs parts won't work either, e.g. where they have to fit a DIP-40 socket.

While you're happy to shill for Keil and for SiLabs, I'm not one to proselytize for the 8255. I've never attempted to promote the thing at all, and, in fact, I don't particularly like 'em for reasons I've repeatedly stated. You, on the other hand, continue to insist that using one in a design in which it fits will make the system "slow." You use terms such as "snail," which brings to mind such rates as "furlongs per fortnight." I've pointed out that using a relatively "slow" device does not make the system slow. It simply makes the cycles in which the relatively slow device is accessed take longer than some other cycles. I've given you more than one example of applications where a device such as the 8255 might fully satisfy the requirements of the end-user.

You're welcome to provide detailed examples, not just hand-waves, showing how much, in numbers, it slows down a system that has other things to do. I freely admit there are places where a cycle-stretch requirement is inappropriate, but I also know that there are places where a 2.5 MHz MCU is adequate. Since a slower clock means less power, I imagine that's worthy of consideration.

Now, just to make sure that we're both speaking the same language, we should define some terms. I don't think it's necessary to do that with frequency. Latency is the duration of a transaction, i.e. from when the first bit is sent to when the last bit arrives or, in cases where that's needed, when the final transition of the transaction occurs. Propagation delay is the interval from the arrival of valid signal at a device input to the appearance of the corresponding valid signal at its output, namely the stimulus-response interval.


Nobody's trying to denegrate your example. I misread your data rate, that's all. However, it wasn't very well described, with bit-banged serial I/O at 5000 bits per half-millisecond, (clearly, that's not synchronous nor is it isochronous) or whatever, and an external UART, the role of which was not defined. )Surely you're not using async protocol for that 10 Mbit link, as that would waste several bits per byte. If it's 5000 bits per half-millisecond, what do you do in the other half-millisecond?) That 480kbps that you mentioned must be the bit-banged rate, as I know of no UART that supports so high a rate, and, further, it would be utterly stupid to use async format where you have blocks of 5000 bits unless you absolutely had to do so. What would interest me more than anything else, though, would be to know how you fit 5000 bits at 480kbps into half a millisecond. I just visited my calculator and find that the most you can fit in a half-millisecond is 2400 bits at that rate. Obviously some clarifications is needed if one is to understand your "example."

I'd be very interested in seeing code that can, at 100 MHz, in one of your SiLabs MCU's bit-bang a serial link at that rate, i.e. 5000 bits per half-millisecond. I'd guess it's not as precisely timed as you suggest.

Only a few of my applications, like yours, are truly time-critical to the extent that I haven't any way to reallocate timing. I don't believe you're alone in that respect, either.


What's a speed switch (synchronous)? The SiLabs parts, like the Maxim/Dallas parts, don't switch speeds. They simply add cycles, effectively stretching the external memory bus cycles. It's just an internal wait-state generator.


The 8255 doesn't "do" anything. It gates the data at its bus input to its port output or from its input port to its data bus, which is not synchronized with any clock. The only delay involved is the internal propagation delay. I admit 16 clock-ticks as opposed to one is quite an extension of the cycle. However, it's just that one cycle. The rest are "normal" cycles.


In what sense is "housekeeping" a problem? Do you mean cycle counting? You still have to do it. It's just the value that you add to the elapsed time. Surely the arithmetic isn't the problem.


Again, I'd like you to provide a detailed example of this. Bit-banging is a burden, but so long as it doesn't have to be high-rate synchronous communication, i.e. going on all the time in sync with an internally or externally generated clock with idle-characters, and other synchronous protocol features, It's not so bad. There is a top-end on IIC, and SPI, isn't there? You don't have to put in idle characters either, do you, so it's really just clocked isochronous communication. I've never bit-banged either of these, so I don't know much about 'em. I'd be very interested in seeing how much a 16-cycle (or less) wait-state impacts system operation. After all, when you're doing serial comm's, you're often just waiting for it to end anyway.


It would be really interesting to see an example demonstrating that from you, involving, say, 96 port bits.


Yes, but your favorites and mine both do.



If you need a reference to a datasheet, in case you need the best bus timing spec's, here are several. I've only found Toshiba, Oki, and Intersil to be shipping these, BTW, but there may be others. Intersil has is the slowest "fastest" part, but then, it's Rad-Hard and may also be a bit stingier with power than others.

http://www.datasheetcatalog.com/datasheet...2C55.shtml

RE