<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 11, 2021 at 3:04 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/02/2021 21:36, Gedare Bloom wrote:<br>
<br>
><br>
><br>
> On Wed, Feb 10, 2021 at 10:57 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a> <br>
> <mailto:<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>>> wrote:<br>
><br>
>     Hi<br>
><br>
>     The minimum sample is intended to show how to construct the<br>
>     minimum footprint RTEMS application. I suspect that with<br>
>     Sebastian's recent work on static allocation and reducing<br>
>     footprint, the minimum sample may be able to benefit from tweaking.<br>
><br>
>     I just checked rtl22xx_t and it is < 16K code and 272 bytes of<br>
>     data. :)<br>
><br>
>     Hello tends to be in the 64K range. Perhaps a static allocation<br>
>     hello variant.<br>
><br>
>     Just wanting users to have good examples. A discussion at the<br>
>     Flight Software Workshop mentioned RTEMS was big but it doesn't<br>
>     seem to be if you look at executables which reflect those minimum<br>
>     feature sets.<br>
><br>
>     Hoping Sebastian has magic settings to apply so these numbers are<br>
>     as good as possible.<br>
><br>
> This is a good idea. A "useful" minimum configuration with static <br>
> objects, or maybe even a couple of them, could be helpful to identify <br>
> reasonable bottom ends of the spectrum we can conceivably support.<br>
<br>
For the pre-qualification project we have to deliver some resource usage <br>
information. We would like to provide some benchmark programs and some <br>
rules to estimate the resource usage based on configuration options. <br>
Example benchmark programs:<br>
<br>
1. one one task with an infinite loop, no clock driver<br>
<br>
2. one one task with an infinite loop, with clock driver<br>
<br>
3. 2. +  create a second task<br>
<br>
4. 3. + send/receive events<br>
<br>
5. 3. + sem obtain/release<br>
<br>
6. 3. + msg send/receive<br>
<br>
7. 3. + barrier wait/release<br></blockquote><div><br></div><div>This is a good list but size measurement is always a pain. Architecture is </div><div>fixed for you but  ARM vs Thumb or SPARC vs their REX makes a big deal</div><div>and probably 2x since I think the erc32 minimum exe is ~28-32k where</div><div>rtl22xx_t is half that.</div><div><br></div><div>Using -Os can shrink things 10-12% based on history.<br><br>RTEMS options matter. Will the threads be statically constructed?</div><div>Will the init thread also be the idle thread?</div><div>SMP or uniprocessor?</div><div>Will you use the simple scheduler? </div><div>Or the default uniprocessor one?  Lower the maximum priorities?</div><div>Include a filesystem or not?</div><div><br></div><div>I recall one closed source RTEMS used to publish the size info that</div><div>didn't include the BSP. We could do this by "ld -r" against librtemscpu.a</div><div>and the application. At least reporting this size vs linked exe highlights </div><div>how some BSPs are just larger due to hardware complexity.</div><div><br></div><div>There is nothing wrong with what you listed. It is perfectly appropriate</div><div>for a qualification effort where many of the things I listed above are</div><div>held constant. </div><div><br></div><div>But I started this thread because I heard someone say RTEMS minimum</div><div>executable size was on the order of 100K where Zephyr was 10K. That is</div><div>likely comparing apples to oranges But I'd like to have some well </div><div>characterized cases that show we really do get down to that range. Yes</div><div>it would require cherry picking some of the parameters</div><div><br></div><div>+ Architecture: Thumb<br></div><div>+ GCC flags: -Os (maybe more)<br></div><div>+ RTEMS configuration: signals off? uniprocessor<br></div><div>+ What application?<br></div><div>    - static init? Init as idle?</div><div>    - Scheduler choice? Simple should be smaller.</div><div><br></div><div>When someone asks size of hello world (not on your list), the other</div><div>RTOS likely has console only output (printk) and not a robust POSIX</div><div>stack with stdio, termios, etc. Andt hen there is the choice of printf,</div><div>iprintf, or printk. </div><div><br></div><div>I think your list is great but I think we also need a true minimum </div><div>application that sets the bottom limit.  </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
...<br>
<br>
Print sizeof(obj) for various objects.<br></blockquote><div><br></div><div>This is spsize. Hopefully it can be updated/moved to meet their purposes. </div><div><br></div><div>Having a single directory of all these characterization tests is great. And </div><div>eventually having a larger set and corresponding documentation to explain</div><div>the delta between each one is important.</div><div><br></div><div>--joel</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">
<br>
>     --joel<br>
>     _______________________________________________<br>
>     devel mailing list<br>
>     <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>><br>
>     <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>     <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a>><br>
><br>
-- <br>
embedded brains GmbH<br>
Herr Sebastian HUBER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 16<br>
fax:   +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
<br>
</blockquote></div></div>