Tool om programma ordelijk te houden en te beginnen

Lambiek

Special Member

Op 19 augustus 2019 11:57:15 schreef MGP:
We zouden samen eens een halfgeleidergids moeten maken :)

Wie weet. :)

Als je haar maar goed zit, GROETEN LAMBIEK.

Op 19 augustus 2019 08:51:48 schreef rew:

code:


#define SD_PARITY_ERROR         (eventflags_t)32    /**< @brief Parity.     */

Wat heb ik aan het commentaar dat dit constantes zijn? waar worden ze gebruikt? Wat heb ik aan de documentatie "Parity." bij de constante "SD_PARITY_ERROR". De code geeft in ieder geval aan dat het een ERROR betreft.

Dit is ook geen documentatie van de C-code, maar code voor de doxygen-compiler om een document te maken waarin staat dat SD_PARITY_ERROR de naam is van de constante die een parity error aangeeft.

Dat is voor mensen die programmeren op basis van de documentatie, en die niet in de header files kijken. Want die zijn onleesbaar :-)

Onderliggende probleem is natuurlijk dat Doxygen net zo dom is als de C compiler, en dus net zulke onleesbare input nodig heeft als de C-compiler. En totdat AI werkelijk van de grond komt zal dat probleem voor alle tools gelden die software begrijpelijker/toegankelijker/onderhoudbaarder moeten maken.

Op 20 augustus 2019 14:14:23 schreef blurp:
Dat is voor mensen die programmeren op basis van de documentatie, en die niet in de header files kijken. Want die zijn onleesbaar :-)

In welk universum voegt 'Parity' iets toe aan de documentatie van de constante met PARITY als deel?

"The following constants define the bit flags for various error conditions in the status register ISR of the uart peripheral"

/daar/ heb je wat aan.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

MGP, Lambiek.
Dacht dat ik 1 van de weinige was die eerst op papier wat nadenkt en schetst.
Vooral schema's dan.
Meteen vanuit een PC werken kost me ook moeite.
Zou dit een leeftijds dingetje zijn ?

Lambiek

Special Member

Op 21 augustus 2019 08:59:42 schreef HD13:
Dacht dat ik 1 van de weinige was die eerst op papier wat nadenkt en schetst.

Het is gewoon makkelijk en veel overzichtelijker. En je komt er ook snel achter of iets kan of niet.

Vooral schema's dan.

Schema's doe ik hele kleine stukjes van, dat is weer makkelijk bij het ontwerpen van een print.

Meteen vanuit een PC werken kost me ook moeite.

Het kost me niet echt moeite om het zonder te doen, meestal zit het al in mijn hoofd. Maar als je met meerdere dingen bezig bent is het gewoon makkelijk en hoef je er niet meer bij na te denken.

Zou dit een leeftijds dingetje zijn ?

Ik heb het altijd zo gedaan, ook toen ik jonger was. :)

En dat alles bij elkaar is weer makkelijk voor het schrijven van de software, je snuffelt de aantekeningen even door en het rolt er zo uit. :) Maar eigenlijk is software nooit af, er zijn altijd wel dingen die beter of korter kunnen.

Als je haar maar goed zit, GROETEN LAMBIEK.

Op 21 augustus 2019 08:59:42 schreef HD13:
MGP, Lambiek.
Dacht dat ik 1 van de weinige was die eerst op papier wat nadenkt en schetst.

Hobbymatig is dat meer dan voldoende, professioneel kan dat niet omdat er meestal meerdere personen belang bij hebben dat zoiets correct gedocumenteerd wordt.
Maar idd zoiets op PC verwerken vraagt veel tijd en als je nog een handleiding moet schrijven ben je wel een tijdje zoet.

LDmicro user.
Lambiek

Special Member

Op 21 augustus 2019 09:23:44 schreef MGP:
...., professioneel kan dat niet omdat er meestal meerdere personen belang bij hebben dat zoiets correct gedocumenteerd wordt.

Professioneel kan dat ook prima, dat helpt je weer om te doen wat je hieronder schrijft. :)

Maar idd zoiets op PC verwerken vraagt veel tijd en als je nog een handleiding moet schrijven ben je wel een tijdje zoet.

Als je haar maar goed zit, GROETEN LAMBIEK.

Op 21 augustus 2019 09:09:15 schreef Lambiek:
[...]
Schema's doe ik hele kleine stukjes van, dat is weer makkelijk bij het ontwerpen van een print.

Geinig dat veel technici bijna op dezelfde manier werken. In mijn rugzak die ik naar het werk neem zitten tal van papieren datasheets (fel ingekort met enkel dat wat ik op dat moment belangrijk vind) een notaboekje en vodjes papier, soms zelfs bierviltjes, met wat gekriebel op. Mijn overste krijgt dikwijls kippenvel als hij dat allemaal op mijn bureau ziet liggen :-p
Voor mij zijn het allemaal puzzelstukjes die samen ooit een geheel moeten vormen. En ieder puzzelstukjes probeer ik dan eerst uit of het net dat doet wat ik verwacht. Alles alle stukjes werken, dan pas maak ik er uiteindelijk een schema van, waarna ik dan kan beginnen met een PCB te tekenen.

Laatst ging ik raad vragen aan een collega op een andere dienst. Hij dook meteen in zijn archief, een lade vol met … papiertjes met gekriebel op. Maar hij had wel de oplossing waar ik naar zocht :-p

Depeet
Lambiek

Special Member

Op 21 augustus 2019 09:48:58 schreef depeet:
Voor mij zijn het allemaal puzzelstukjes die samen ooit een geheel moeten vormen. En ieder puzzelstukjes probeer ik dan eerst uit of het net dat doet wat ik verwacht. Alles alle stukjes werken, dan pas maak ik er uiteindelijk een schema van, waarna ik dan kan beginnen met een PCB te tekenen.

Precies. :)

Als je haar maar goed zit, GROETEN LAMBIEK.

Op 21 augustus 2019 05:20:26 schreef rew:
[...]In welk universum voegt 'Parity' iets toe aan de documentatie van de constante met PARITY als deel?

Er moet iets staan in de gegenereerde documentatie.

"The following constants define the bit flags for various error conditions in the status register ISR of the uart peripheral"
/daar/ heb je wat aan.

Nu verwacht je dat er nagedacht wordt. Da's een beginnersfout ;-)

Oef, je vraagt wel iets.

Ten eerste zou ik beginnen met kijken naar TDD(test driven development). Het idee is dat je een test schrijft om je code te testen. Dat kan zelfs gewoon lokaal op je PC. Door voor ieder scenario een test te beschrijven, beschrijf je als het ware meteen wat je code behoort te doen. Dat werkt beter dan documentatie, omdat het automatisch een foutmelding zal geven als je scenario's en je code niet overeen stemmen. Bij ons op de zaak is het credo zelfs "commentaar liegt altijd". Natuurlijk behoeft dat niet het geval te zijn, maar in de praktijk is het erg moeilijk om het allemaal in overeenstemming te houden. En één enkele afwijking trekt in feite al je commentaar in twijfel.

Ten tweede kan je de principes van clean coding aanhouden. Het idee is dat iedere module die je schrijft precies één verantwoordelijkheid heeft. Dat betekent ook dat je heel veel modules zult krijgen, maar dat is overzichtelijker dan een paar hele grote modules.

Bijvoorbeeld een klok. Je zult losse testen schrijven voor het voortschrijden van een seconde, voor de overgang van één minuut, één uur, en één dag. Je schrijft testen voor het instellen van de tijd, het instellen van een alarm, en het verwijderen van een alarm. Je schrijft dan ook een test voor het verwijderen van een alarm als het op snooze staat. Je tijd beheer is een aparte module van je alarm module. Je alarm module een andere dan je snooze module. Je visualisatie weer een andere, je interface naar de hardware of het OS voor het ophalen van de tijd weer een andere.

Meep! Meep!

Bij het overzichtelijk houden van code komt vaak een stukje code architechteur kijken. Echt tools zijn er zover ik weet niet...

Aantal tips zijn al gegeven zoals in lagen opbouwen, abstracties maken enz. Twee 'tools' die ik verder nog aan kan bevelen zijn UML voor het modeleren (uittekenen) van de software in een abstracte vorm. Youtube staat vol met informatie hierover.

Een tweede is het gebruik van code patterns. Zeker met embedded raad ik je aan om eens naar een finite state machine te kijken. Dit is een hele interessante architechtuur die super veel gebruikt wordt. Ik denk dat zo'n beetje al je witgoed apparaten draaien op een vorm van een FSM.