Hacker News Reader

> You split the radio task into two tasks: a low priority task for processing commands and the ISR task which does the acknowledgements.

You contradicted yourself here. You moved the code out of radio ISR to application code, thus keeping the radio ISR small.

View on HN

Actually, she/he moved the code for acknowledging radio packets into the ISR, relative to the the "by the book" solution of having minimal ISRs.

Why didn’t they move the command processing into the ISR too then?

I assume the command processing was simply not a predictably small enough of a workload to fit into the time budget for an ISR. Besides, that is irrelevant for his point, he already gave an example of a "big" ISR, it doesn't have to be even bigger.

> not a predictably small enough workload

Which means ISRs can grow too big. And that’s the reason keeping ISRs as small as possible should be your goal.

That's not a good argument. That an extreme is bad doesn't make the opposite extreme good. I could easily have a house that is too large, but I wouldn't want to live in a box.

I mean, I (and most people on this thread...) agree with you, I believe it is almost always "nicer" to be consistent and have minimal ISRs. But her/his point (as I interpret it, at least) was that in some situations a somewhat larger ISR may make sense.

Reply on news.ycombinator.com