CODEWITHSUNDEEP
coperating-systemembeddedinterruptsafety-critical
Tian
Tian

Reputation: 61

Why not put task context in interrupt

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?

Upvotes: 4

Views: 443

Answers (3)

Vroomfondel
Vroomfondel

Reputation: 2898

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?

Upvotes: 3

Gustavo Laureano
Gustavo Laureano

Reputation: 566

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.

Upvotes: 1

teroi
teroi

Reputation: 1087

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.

Upvotes: 1

Related Questions