Are there any available guidelines for the amount of code to have in a critical section of interrupt driven processing?
My personal rule of thumb is that the critical portion, (i.e. that between disable interrupts and enable interrupts), of any interrupt driven processing should be no more than about a dozen lines of code, (including those in any function/library/macro called), and that the processing should be as linear as possible.
I would expect something along the lines of:
disable_interrupts if error_condition: set_error_flag else: small_data_transfer set_ready_flag enable_interrupts
However I have been asked to look into an existing project where some of the interrupts have handlers where the call charts will not fit on a sheet of A1 (all in the critical section).
To clarify this is a "bare metal" project with no OS/Scheduler implemented - and all of the interrupt handlers start by disabling all interrupts - i.e. the original authors regarded every operation in every ISR as critical, (even the housekeeping is all inside of a disable/enable section). There are a multitude of interrupts and hardware dependencies but as far as I can see some of the ISRs will be executing thousands of lines within the "critical" section.
I know that this is a problem and really needs to be completely rewritten but I can not find any standards, including MISRA, that I can point to rather than just saying "in my experience" - to convince the project management I need to point to some accepted standards.
So hence my question - Can anybody point me towards any standards or guidelines that I can use to back up my experience? (Or of course am I totally wrong).