I've pointed out that using a relatively "slow" device does not make the system slow.
That's right just ignore the examples I gave (see below)

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.
this is just hilarious talking about conserving power AND using a 8255

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.
clarify for 'interrupt latency' the time from the external event till the ISR is entered.


If it's 5000 bits per half-millisecond, what do you do in the other half-millisecond?)
do it again


That 480kbps that you mentioned must be the bit-banged rate, as I know of no UART that supports so high a rate
Occasional upload via UART of "the next bunch of bits to be bit-banged out repeatedly" The SIlabs f12x, f13x UART support "so high a rate" easily.



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 bang 5000 bits per halfmillisecond and occasionally recieve an update at 480kbaud

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.
the only timing is 'within', the bits must be transferred before a timer tick strobes.

facts:
1) (with or without a speed switch)(synchronous) The snail is unusable for fast I/O.

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.
terminology speed switch - cycle stretcher

2) (with a speed switch)(asynchronous) when an interrupt is coinciding with whatever the snail is doing the latency is horrendously increased
(without a speed switch)(asynchronous) when an interrupt is coinciding with an external memory access the latency is horrendously increased.
The 8255 doesn't "do" anything. and the you say that it does 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.
Ok, since you can not understand it, let me bend it in neon: If an interrupt happens at a 'normal' movx, the interrupy latency will be (if I recall correctly) 7 cycles. however if it happens at the beginning of a 16 cycle stretch it will be 22 ( 7 +15) cycles. If you had some (slightly) time critical interrupts that would give you a nice intermittent failure do you understand it now?

3) (with a speed switch)(general) if any ISR is using XDATA (or, even worse, accessing the snail) the 'housekeeping' becomes a real burden.
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.
If you just tried to absorb instead of flying to the defense of the snail you would understand. Housekeeping means that if you do not know the speed - ok cycle stretch mode - of the data bus when an interrupt happens (and you cant when you keep changing it) you will need to save (change) and restore the cycle length status adding 'housekeeping overhead"

4) (with or without a speed switch) if you can live with the timing of the snail, you can, most likely, live with the timing of IIC or SPI and save a whole lot of port pins (which you then can use for fast I/O) note: any decent modern derivative has HW SPI and/or IIC. Stupidly bit banging either would invalidate this point, but then the use of the snail would not be a problem since your uCs technology would be equally old.


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.
bit banging hangs the cpu till done, anyhow I thought we were discussing the snail, not bit banged IIC/SPI which is why I only referred to current technology when i mentioned IIC/SPI, sorry i forgot your penchant for yesterdays stuff.

5) using a modern derivative with sufficient internal ROM and RAM you would lose as many pins as you 'gained' using the snail.
It would be really interesting to see an example demonstrating that from you, involving, say, 96 port bits.
you keep stating that my examples are 'unique' yours are even more so