<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 28, 2017 at 10:31 AM, Denis Obrezkov <span dir="ltr"><<a href="mailto:denisobrezkov@gmail.com" target="_blank">denisobrezkov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div class="gmail-h5"><div class="gmail_quote">2017-07-28 17:05 GMT+02:00 Joel Sherrill <span dir="ltr"><<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-m_6997291409501819699gmail-">On Fri, Jul 28, 2017 at 9:23 AM, Denis Obrezkov <span dir="ltr"><<a href="mailto:denisobrezkov@gmail.com" target="_blank">denisobrezkov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>2017-07-28 15:19 GMT+02:00 Sebastian Huber <span dir="ltr"><<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brai<wbr>ns.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 28/07/17 15:15, Denis Obrezkov wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2017-07-28 14:56 GMT+02:00 Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a> <mailto:<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>>>:<span class="gmail-m_6997291409501819699gmail-m_-4346984994325008467m_2132216567767509145gmail-"><br>
<br>
There is a debug option near the bottom of confdefs.h which you<br>
can enable to generate a data structure filled in with various<br>
values computed by confdefs. You can look at that in gdb without<br>
loading it on the target.<br>
<br>
It is probably worth it to look at that now and see what you spot.<br>
<br>
Okay, I'll try.<br>
<br>
<br>
And a random thought.. what's the interrupt stack size and how is<br>
it allocated? What are the port specific related macros set to?<br>
<br>
I don't completely understand what is the interrupt stack. Because, when an interrupt occurs,<br>
I save all registers and move the stack pointer, handle interrupt,<br>
</span></blockquote>
<br>
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.<br></blockquote><div><br></div></span><div>Am I understand right that RTEMS has a wrapper for interrupt handlers that creates a dedicated 'interrupt handler' task?<br></div><div>I think it is not, since we call ISR directly from assembler code, thus should we save registers in a dedicated interrupt stack</div><div>by ourselves in the ISR?</div></div></div></div></blockquote><div><br></div></span><div>There can be interrupt server threads but that is a distinct topic.</div><div><br></div><div>Interrupts have to execute on a stack. As Gedare said, you are currently processing each</div><div>ISR on the stack of the thread that was interrupted. Most of the other ports have a dedicated</div><div>interrupt stack and switch to it.</div><div><br></div><div>There is a worst case stack usage for each thread and the interrupts. Without a dedicated </div><div>interrupt stack, each task must account for its worst usage and the worst case interrupt</div><div>when allocating its stack.</div><span class="gmail-m_6997291409501819699gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Also, I don't understand what do you mean by: " you only have to account for one interrupt frame per thread".</div></div><div>And what is an 'interrupt frame'? I have found something in a relatively old guide:</div><div><a href="https://docs.rtems.org/releases/rtemsdocs-4.9.6/share/rtems/html/porting/porting00033.html" target="_blank">https://docs.rtems.org/release<wbr>s/rtemsdocs-4.9.6/share/rtems/<wbr>html/porting/porting00033.html</a><br></div><div>but it doesn't make it clear.</div></div></div></blockquote><div><br></div></span><div>An interrupt frame is the set of data that must be saved for each interrupt occurrence. The</div><div>"only have to save one" is because you can switch to a dedicated stack where interrupts</div><div>are processed and possibly nested. Thus you have the usage for the processing and </div><div>possible nested interrupts.</div><div><br></div><div>But you need to figure out why the memory allocated changed. Optimization level should be</div><div>independent of that.</div><span class="gmail-m_6997291409501819699gmail-HOEnZb"><font color="#888888"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class="gmail-m_6997291409501819699gmail-m_-4346984994325008467HOEnZb"><font color="#888888">-- <br><div class="gmail-m_6997291409501819699gmail-m_-4346984994325008467m_2132216567767509145gmail_signature">Regards, Denis Obrezkov</div>
</font></span></div></div>
</blockquote></font></span></div><br></div></div>
</blockquote></div><br></div></div>I can see that during task initialization I have a call:</div><div class="gmail_extra"><span class="gmail-"><div class="gmail_extra"> _Thread_Initialize_<wbr>information (information=information@entry<wbr>=0x80000ad4 <_RTEMS_tasks_Information>, the_api=the_api@entry=OBJECTS_<wbr>CLASSIC_API, the_class=the_class@entry=1, maximum=124, </div><div class="gmail_extra"> is_string=is_string@entry=<wbr>false, maximum_name_length=maximum_<wbr>name_length@entry=4)</div><div><br></div></span><div>And maximum is 124, but I have a configuration parameter:</div><div><div>#define CONFIGURE_MAXIMUM_TASKS 4</div></div></div></div></blockquote><div><br></div><div>I can't imagine any standard RTEMS test configuring that many tasks. </div><div>Is there a data corruption issue?</div><div><br></div><div>124 = 0x7c which doesn't ring any bells for me on odd memory issues.</div><div><br></div><div>What is the contents of "Configuration_RTEMS_API"?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><br></div><div>It seems that other tasks are LIBBLOCK tasks.</div><div><br></div><div>Also, this is my Configuration during run:</div><div><div>(gdb) p Configuration.stack_space_<wbr>size </div><div>$1 = 2648</div><div>(gdb) p Configuration.work_space_size </div><div>$2 = 4216</div><div>(gdb) p Configuration.interrupt_stack_<wbr>size </div><div>$3 = 512</div><div>(gdb) p Configuration.idle_task_stack_<wbr>size </div><div>$4 = 512</div></div></div></div></blockquote><div><br></div><div>That looks reasonable. Add CONFIGURE_MAXIMUM_PRIORITY and set it to 4. That should</div><div>reduce the workspace.</div><div><br></div><div> long term, we might want to consider lowering it permanently like one of the Coldfires </div><div>had to. Or change the default scheduler to the Simple one to save memory.</div><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class="gmail-HOEnZb"><font color="#888888"><div><br></div>-- <br><div class="gmail-m_6997291409501819699gmail_signature">Regards, Denis Obrezkov</div>
</font></span></div></div>
</blockquote></div><br></div></div>