2017-07-28 15:19 GMT+02:00 Sebastian Huber < sebastian.hu...@embedded-brains.de>:
> On 28/07/17 15:15, Denis Obrezkov wrote: > > 2017-07-28 14:56 GMT+02:00 Joel Sherrill <j...@rtems.org <mailto: >> j...@rtems.org>>: >> >> There is a debug option near the bottom of confdefs.h which you >> can enable to generate a data structure filled in with various >> values computed by confdefs. You can look at that in gdb without >> loading it on the target. >> >> It is probably worth it to look at that now and see what you spot. >> >> Okay, I'll try. >> >> >> And a random thought.. what's the interrupt stack size and how is >> it allocated? What are the port specific related macros set to? >> >> I don't completely understand what is the interrupt stack. Because, when >> an interrupt occurs, >> I save all registers and move the stack pointer, handle interrupt, >> > > Now you handle the interrupt on the stack of the interrupted context > (usually a thread). So, you must take this overhead into account for every > thread. If you switch to an interrupt stack, then you only have to account > for one interrupt frame per thread. If you support nested interrupts, you > need even more space per thread without an interrupt stack. > Am I understand right that RTEMS has a wrapper for interrupt handlers that creates a dedicated 'interrupt handler' task? I think it is not, since we call ISR directly from assembler code, thus should we save registers in a dedicated interrupt stack by ourselves in the ISR? Also, I don't understand what do you mean by: " you only have to account for one interrupt frame per thread". And what is an 'interrupt frame'? I have found something in a relatively old guide: https://docs.rtems.org/releases/rtemsdocs-4.9.6/share/rtems/html/porting/porting00033.html but it doesn't make it clear. -- Regards, Denis Obrezkov
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
