Why not put task context in interrupt

4
votes

Here is the story.

Its a safety critical project and needs to run a time critical functional routine in 20KHz. Now the design is to put functional routine in a 20KHz FIQ interrupt, meanwhile safety interrupt also in FIQ. Thats the only two FIQ in system. (Surely there are couples of IRQ enabled in the MCU)

I know that its not good to put task context in interrupt ISR, the proper way of doing this to set mark and run in OS task. But seems current design harm nobody.

The routine takes about 10us (main clock 300MHz), so basically it will not blocks IRQ/FIQ for unacceptable time. It even save time for extra context switch compare with using OS task to run the functional routine. To me, currently it feels like the design is against every principle written on text book in university but can not find a reason to say no to it.

How could I convince myself to move functional routine from ISR to OS? Should I?

3
coperating-systemembeddedinterruptsafety-critical
If the FIQ/s is/are short enough to not impact the required functionality of the rest of the app, and do not use code/functions that are illegal/unwise in FIQ context, then fine. Sure, you have to be careful what you do/call, but if it is safe and works, great:) - Martin James
Example - I came unstuck when I pushed a buffer struct pointer onto a circular queue that, while safe when pushed from IRQ and pulled from thread, was not safe when it was also pushed from an FIQ as the queue indices could get mixed up when the FIQ interrupted an IRQ:( I got round that by explicitly setting a software interrupt so its hanlder ran either after the FIQ returned or after any other IRQ that had been interrupted had returned. - Martin James
I have to ask, however, what it is that you are doing that takes 10us? - Martin James
@MartinJames Good point. Interrupt preemptive truly cause problem while critical resource not well protected. The 10 us is just some math work. Sensors getting data back and MCU needs do some calculation and response real fast. The math works is the functional routine mentioned above. I figure there are no critical resource in this case. If I move to OS, I get extra bloat. What's the benefit I may gain from those bloat? - Tian
You've labelled this safety-critical. If your application is safety-critical, then you must ensure that the interrupt is 100% cyclic and that your program is 100% deterministic. It might even be better to get rid of the interrupt, have the main program do all its work, then busy-wait for the interrupt source - this assuming that the program does nothing but to process all the things needed between the 20kHz cycles. It is kind of hard to say how you should design the system without knowing the spec. - Lundin

3 Answers

3
votes

Let's recollect your situation:

  1. you are coding a safety critical system
  2. the software architecture isn't specified otherwise you wouldn't ask the question at hand
  3. the system requirements weren't processed correctly otherwise 2) wouldn't be in question
  4. someone told you to "use minimum interrupt if possible in safety critical system"
  5. you want to use the highest priority & non-interruptible code for "just some math work"

Sorry for being a bit harsh but I wouldn't want to use/be in your safety critical system.

For your actual problem: you have to make sure two things

  • the code in the FIQ must be deterministic and WCET tested
  • the registers of the timer must be protected and supervised. Why? An unwanted/erroneous manipulation of the timers registers by a lower safety level code can congest the CPU so much that effectively nothing else but the interrupt is processed.

All this under the assumption that your safe state depends entirely on an external hardware watchdog.

PS: Which are the hazards for users of your system? Annoyance? Injury? Lethal? Are you in a SIL or ASIL context?

1
votes

The reason to move complex code away from ISR is precisely to avoid lengthy processing in the ISR and thus timing jitter and delayed interrupt servicing resulting from it.

You are stating the your processing is not lengthy so do it in the ISR! Otherwise you are just adding bloat.

1
votes

20Khz = 50us between interrupts, with 10us of processing time it gives you roughly 20% of CPU time just for this "task", and a jitter of 10us in any other routine that runs in your CPU, it will also sum 10us of processing time for each 40us that any other task will consum, if it is ok for your project, and you keep your total CPU processing time below 70% (which is the common maximum acceptable for critical systems), IMHO it should work without any issue.