2017-07-28 17:05 GMT+02:00 Joel Sherrill <j...@rtems.org>: > > > On Fri, Jul 28, 2017 at 9:23 AM, Denis Obrezkov <denisobrez...@gmail.com> > wrote: > >> 2017-07-28 15:19 GMT+02:00 Sebastian Huber <sebastian.huber@embedded-brai >> ns.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? >> > > There can be interrupt server threads but that is a distinct topic. > > Interrupts have to execute on a stack. As Gedare said, you are currently > processing each > ISR on the stack of the thread that was interrupted. Most of the other > ports have a dedicated > interrupt stack and switch to it. > > There is a worst case stack usage for each thread and the interrupts. > Without a dedicated > interrupt stack, each task must account for its worst usage and the worst > case interrupt > when allocating its stack. > > >> >> 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. >> > > An interrupt frame is the set of data that must be saved for each > interrupt occurrence. The > "only have to save one" is because you can switch to a dedicated stack > where interrupts > are processed and possibly nested. Thus you have the usage for the > processing and > possible nested interrupts. > > But you need to figure out why the memory allocated changed. Optimization > level should be > independent of that. > > >> -- >> Regards, Denis Obrezkov >> > > I can see that during task initialization I have a call: _Thread_Initialize_information (information=information@entry=0x80000ad4 <_RTEMS_tasks_Information>, the_api=the_api@entry=OBJECTS_CLASSIC_API, the_class=the_class@entry=1, maximum=124, is_string=is_string@entry=false, maximum_name_length=maximum_name_length@entry=4)
And maximum is 124, but I have a configuration parameter: #define CONFIGURE_MAXIMUM_TASKS 4 It seems that other tasks are LIBBLOCK tasks. Also, this is my Configuration during run: (gdb) p Configuration.stack_space_size $1 = 2648 (gdb) p Configuration.work_space_size $2 = 4216 (gdb) p Configuration.interrupt_stack_size $3 = 512 (gdb) p Configuration.idle_task_stack_size $4 = 512 -- Regards, Denis Obrezkov
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
