I don't know how your debugger works, but in my environment, I can tell what's going on and when. You're right, in that if you use a 16-cycle stretch, then your interrupt response time could be increased to as long as 23 cycles if it's normally 7 cycles, since the interrupt won't be processed until the completion of the current instruction. However, since you're transmitting a constant stream at 10 Mbits per second, when do you have time to respond to an interrupt of any sort?

Do you interrupt your bit-banged serial transmission in order to process interrupts? You can do that, since you have control of both clock and data, but the rate's going to drop if you take time to do other things.

Could you resolve that question about whether it's 8 Mbits per second or 10 Mbits per second?

There are too many "loose ends" now. On one hand you've said you have occasional interrupts. on the other, you say you always and constantly transmit 5000 bits each half-millisecond. In another post, you say you transfer 500 bytes per half-millisecond.

Actually, you needn't bother, since NOBODY CARES about what you do or why you do it. The core of this argument, as you've presented it, is that because there exists in the infinite universe, at least one application in which it might be impractical to use the 82C55, nobody should ever use it anywhere. They should "stamp their feet and refuse" or some such, as you've stated a time or two, if directed by their employer or professor, to do so. That's just plain wrong, not just from a technical standpoint, but from a philosophical one as well.

It's wrong just as it would be wrong to say it's wrong to ride a bicycle because there are cars or motorcycles. It's wrong just as it would be wrong to say it's wrong to use a 5-volt supply because there are 3-volt parts available.

A fellow with an MCU in 40-pin DIP packaging can't use your SMT part in his application. If his board has two 8255's on it and he asks how to drive his LCD with them, it doesn't help if you tell him to buy a different board. It may just be his hobby project. He wants to use THAT board. It's just like when he wants to ride his bicycle. He has a car, but he wants to ride his bicycle. It does what he wants.

RE

p.s.

BTW, there's no reason that interrupt latency should be an issue for you at all. You can interrupt that bit-banging process in which you control both clock and data anywhere you want without consequence. Your interrupt from the 460 kbps UART requires a service response of something over 21 microseconds. Since you control both ends of the synchronous-mode comm link it shouldn't matter a bit whether you take a microsecond or so off the bit-banging task in order to service the interrupt. Since you seem to feel that 5000 is a pretty good approximation (remember "roughly") of 4000, in your application, it shouldn't matter at all.