3 ms·
> 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 yours
by kahlonel 6y ago
> 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.
- nsajko 6y agoActually, she/he moved the code for acknowledging radio packets into the ISR, relative to the the "by the book" solution of having minimal ISRs.
- kahlonel 6y agoWhy didn’t they move the command processing into the ISR too then?
- nsajko 6y agoI 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.
- kahlonel 6y ago> 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.
- nsajko 6y agoI 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.
- ivanbakel 6y agoThat'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.