Hello, I'm working on a porting and my embrional work seems ok: several tasks are scheduled and I'm able also re-schedule (through TaskYIELD). At moment I don't use queues or ISRs.

In the current implementation I have only one Irq (the Tick ones) so that the context is saved into Task stacks.

Is it acceptable to use for all the other ISRs (CAN, SPI,...) the same handling?

I have a schema like this: irq source --> ISR handler (for all irqs) --> call to specific handler

The ISR handler entry point is unique for the system: when a irq exception is arised the main handler is called. After the context store into the stack, the irq handler (the one relative to the exception) is called.

Is it important/mandatory differentiate the handling for common irqs and tasks?

Please help me.

Regards, Pippo

You don't give the processor type in your question, which is very important in discussing how to write an ISR, as that is VERY processor specific.

In some ports of FreeRTOS, ISRs use the task stack, this is simple, but requires you to have extra space in every tasks stack for the most stack space that ISRs might use.

In other ports, some common code is invoked on entry to an ISR, and it can switch over to have the ISRs use their own stack. (Some processors even do this automatically). This method (if not directly supported by the hardware) is somewhat more complicated, but saves space.

It is important to write your ISR in accordance to the documentation for the port you are using, which will be different than how you write normal task code (which for the most part will be port independent).

Just to add to Richard Damon's answer - generally newer ports have separate interrupt stacks because they are on more powerful devices and support interrupt nesting. Interrupt nesting requiring more stack, which you don't want to have to allocate to each task, unless RAM consumption is not an issue.

Regards.

I got!!

I will come back soon...