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