Erm, I'm not sure I explained what I had in mind well then.
We copy a whole port's worth of data into memory at a time, using the interrupt.
In the slices in between those interrupts, we have to work out what that data is doing.
The way of doing so that I envisaged would be to work on the bits representing the first channel, then set the corresponding controls. Then work on the bits representing the second...
If we could get through processing all the channels between each timer interrupt, we would never introduce an excessive delay. But, obviously, we can't. If it takes too long to get through channels 1...n, a change commanded to channel n+1 just after it has been checked might take a while to be processed. This would be a problem for a super-fast, twitchy model but probably not for a gently cruising blimp.
If my logic is incorrect here, please help me understand how.
Of course, a better plan than mine for working on the stored data might be able to circumvent this issue. However, if we are storing samples of the pulses and then measuring them, even a perfect way of processing the data is going to have to allow time for measurement somewhere. The question is only "is it acceptable for this purpose", surely?