<div dir="ltr">Hi,<div><br></div><div>Thanks for the suggestions, they're all very valid and helpful.</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">We advocate a test-driven development (TDD) approach in RTEMS. Write<br>the test that should pass once your implementation is correct. Making<br>it multi-layered from simpler to more complex functionality allows you<br>to keep track of your progress and make sure you don't break something<br>(regression) that was working earlier.</blockquote><div><br></div><div>Should it be a complete test suite like the ones in the folder smptests or should it just be an idea in the Doxygen comment?   </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 9, 2020 at 8:27 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</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">Richi,<br>
<br>
Some good advice from others. I'll just add a few more notes.<br>
<br>
On Thu, Jul 9, 2020 at 2:23 AM Richi Dubey <<a href="mailto:richidubey@gmail.com" target="_blank">richidubey@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> I understand. I'll learn how to use Doxygen and put it in my codes. Thank you.<br>
><br>
Not just that, he also suggests you can start with a doxygen<br>
description before you really start coding. This is useful to help<br>
think through the interfaces and structures of your functions before<br>
you start to implement them.<br>
<br>
If you need help to run doxygen locally, ask.<br>
<br>
> On Thu, Jul 9, 2020 at 12:43 PM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
>><br>
>> Hello Richi,<br>
>><br>
>> we use Doxygen to document the software design. Maybe you can write your<br>
>> high-level description with it. This way it is integrated already<br>
>> integrated in the sources. You can use @dot for graphs and @msc for<br>
>> message sequences.<br>
>><br>
<br>
Personally, I like to start with pen and paper drafts in a notebook. I<br>
keep my notebook handy to keep track of revisions and ideas. I'll move<br>
to either text- or graphic-based design if I need to share it with<br>
others. Text-based is easier to integrate in documentation, while<br>
graphic-based can make for some really nice explanations in blogs and<br>
other reports. Doing text-based in doxygen is a good way to save time<br>
on internal doco later.<br>
<br>
>> I would document the data structures and the invariants of the data<br>
>> structures. I would also try to write code which checks that the<br>
>> invariants are satisfied. This can be used in _Assert() and RTEMS_DEBUG<br>
>> blocks.<br>
>><br>
>> I would also write test cases. You can already run the test cases with:<br>
>><br>
>> <a href="https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#arbitrary-processor-affinity-priority-smp-scheduler" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#arbitrary-processor-affinity-priority-smp-scheduler</a><br>
>><br>
<br>
We advocate a test-driven development (TDD) approach in RTEMS. Write<br>
the test that should pass once your implementation is correct. Making<br>
it multi-layered from simpler to more complex functionality allows you<br>
to keep track of your progress and make sure you don't break something<br>
(regression) that was working earlier.<br>
<br>
>> There should be test cases which would fail with the Linux push and pull<br>
>> scheduler.<br>
>><br>
>> You should identify the key scheduler operations (e.g. block and<br>
>> unblock) and write a high level description of the algorithms used for<br>
>> these operations in some sort of pseudo code.<br>
>><br>
>> --<br>
>> Sebastian Huber, embedded brains GmbH<br>
>><br>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
>> Phone   : +49 89 189 47 41-16<br>
>> Fax     : +49 89 189 47 41-09<br>
>> E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
>> PGP     : Public key available on request.<br>
>><br>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
><br>
> _______________________________________________<br>
> users mailing list<br>
> <a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br>
</blockquote></div>