3 ms·
> I disagree. If you have interrupt priorities then you can treat your interrupt service routines as the highest priority tasks. ... I think "Keep ISRs small"
by nsajko 6y ago
> I disagree. If you have interrupt priorities then you can treat your interrupt service routines as the highest priority tasks. ...
I think "Keep ISRs small" is still a good guideline for most cases. Big interrupt handlers require more system-wide knowledge to verify (e.g., stack space, maximal latency, priority problems, ...). They introduce more coupling into the system, in other words.
Of course, this should not be some hard rule, rather just a rule of thumb. I wouldn't like it if some policy like this prevented you from choosing the optimal solution in a case like you suggested.
- barbegal 6y ago> Big interrupt handlers require more system-wide knowledge to verify I think the point I'm trying to make is that sometimes following the rule of "make your ISR small" actually makes this worse because your bigger high priority task can be interrupted or you turn interrupts off or mask interrupts and you end up with even more complexity.
- aidenn0 6y agoSometimes following rules-of-thumb blindly will make things worse. This is one reason why we call them "rules of thumb" rather than e.g. "laws." Another example: if you are shipping over a million units, then adding hardware to simplify software starts to look like a bad trade-off since BOM starts to dominate NRE.
- Gibbon1 6y agoFat ISR's are often really hard to debug. And the more complex state an ISR has the harder it is to communicate with it. That's because with an ISR you are in a state of sin because you always end up with duplicated state.