<div dir="ltr">Got it, Thank you.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 10, 2020 at 8:07 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">On Fri, Jul 10, 2020 at 4:58 AM Richi Dubey <<a href="mailto:richidubey@gmail.com" target="_blank">richidubey@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> Thanks for the suggestions, they're all very valid and helpful.<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>
><br>
> 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?<br>
><br>
<br>
For TDD you need to have a real test.<br>
<br>
> On Thu, Jul 9, 2020 at 8:27 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
>><br>
>> 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>