2017-07-28 17:31 GMT+02:00 Denis Obrezkov <denisobrez...@gmail.com>: > 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.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? >>> >> >> 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 >
I've just found out that without optimization Configuration_RTEMS_API.maximum_tasks = 5, and with -Os, Configuration_RTEMS_API.maximum_tasks=124. -- Regards, Denis Obrezkov
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
