Zonder fouten een Arduino programmeren

[bask185]

Beste hobbyisten,

Het heeft even laten wachten maar deel 2 van de cursus  is er! 

Dit deel gaat specifiek over het coderen van processen in de vorm van een zgn 'state-machine'. We gaan hierbij ook gestructureerd te werk. Er wordt ook uitgelegd hoe je je code kan opsplitsen in meerdere bestanden om zo meer overzicht te maken voor jezelf.

Ik leer je ook een paar leuke truukjes die je kan doen met macro's. Je kan namelijk veel meer doen met een #define dan je tot nu toe gedaan heb. Ze kunnen voorkomen dat we iets vergeten en, ze kunnen code leesbaarder maken en ze kunnen ons werk besparen.

Een goede werkwijze, goede codestructuur, overzichtelijkheid en een paar handige macro's dragen ook veel bij in het voorkomen van bugs. Ik geef je een duidelijk stappen plan en tips over hoe je een nieuw project op kan zetten.

Voor de geinteresseerde, ik wens jullie weer veel leesplezier. 

P.S.
Ik heb deze keer een grammar check gedaan in MS word. Als je een stijl of taalfout aantreft, ben ik tevreden met de paragraaf nummer.

[Timo]

Hoi Bas,

Ik heb weet niet alles gelezen maar je stuk over macro's trok even de aandacht Dit omdat ik duidelijk van het andere team ben. Team "macro's de wereld uit!" Maar gelukkig heb je het een cursus C genoemd Maar goed, dat is je eigen invulling, daar ga ik je hier niet verder mee lastig vallen. Mee eens ben ik het zeker niet , maar het is jouw artikel

Waar ik wel over val is dat jij mij stiekem zwart maakt in je stuk. (Ja, ik voel me persoonlijk aangevallen.) Dit vind ik op zijn zachts niet zo netjes. Zou je dit willen aanpassen in de tekst?

Paar (niet macro) opmerkingen:
- Bladzijdenummers!
- Ik kan er volledig inkomen dat je heel snel naar Engelse woorden grijpt als je iets over programmeren uitlegt. Maar daar je er bewust voor gekozen hebt om te schrijven in het Nederlands zou ik proberen dat dan ook echt te doen. Bijvoorbeeld pitfall is gewoon een valkuil
- Is er een reden voor waarom je soms dingen opeens met hoofdletter schrijft? Dingen als "de Functies" etc.
- Volgens mij moet je de definitie van weerleggen nog even opzoeken in de van Dale Die lijk je steevast te verwisselen met de definitie van uitleggen of uiteenzetten.


Okay, ik had gezegd over je macro keuze niet te vallen maar je "broodje aap" paragraaf is natuurlijk zelf een broodje aap, sorry Type safe heeft NIETS maar dan ook niets met een standaard error van doen. Dat jij macros anno 2020 nog wilt gebruiken, prima. Maar zoek wel even op wat type safe is wil je  Overigens heb je geluk dat je de nieuwe compiler gebruikt om je punt te maken, de oudere compiler gaf echt niet aan dat de fout in de macro zat En ik moet je in dat opzicht gelijk geven, uit die tijd komt mijn uitspraak over slechte compiker errors met macos. Maar zeg nu zelf, die van de const is toch nog veel duidelijker 

Dan waarom zou je ooit willen tikken:

Code: [Selecteer]

ledPin = 4;//?

Los van hoe je dit oplost , maar ik kan zo twee gevallen bedenken die beide gewoon terug gaan naar simpelweg een menselijke fout.

1) Je bedoelde 'ledState' en je schreef gewoon naar de verkeerde variabele.
2) Dit stond in een if() en je bedoelde gewoon == (En nee, zelf vind ik Yoda notation ook niet mooi, maar nuttig is het wel.)

Een constante doelbewust willen wijzigen zal dan ook nooit voorkomen (bij iemand met enige kennis). Maar per ongeluk, dat is een ander verhaal. Het is dus zelfbescherming. Je kan zeggen, dan moet je beter opletten. Maar dat is toch gewoon voor 99% van de compiler errors?


Bovenstaande moet je wel luchtig lezen! Ik ben niet boos of zou nooit meer een kroket (en biertje? ) willen doen in Houten ofzo. Sterker nog, dat is denk ik eerder de plek waar we het over de zin en onzin van macro's kunnen hebben Maar het stukje in je artikel vind ik niet netjes. Graag de persoonsverwijzing eruit halen. Het is en blijft je eigen visie op de zeken. Verschil daarin is prima, messteek onderwater wat minder.


Timo

[bask185]

Time, Mijn excuses. Het was echt niet mijn bedoeling om je te beledigen. . Ik zal het zo spoedig mogelijk wijzigen. Weet dat ik je kritiek enigszins waardeer. Natuurlijk ben ik het er niet altijd mee eens (Go macro's, Go!). Ik vind het zelf namelijk wel leuk om een beetje te sparren met een ander. Het houd je scherp en je leert er soms iets bij.

Ik moet sws werk doen, want idd pagina nummers vergeten en:
"Type safety means that the compiler can check whether you're using the right types"
I screwed up. Geef ik toe.

Maar ff for real. Ik weet dat je als C++'er een soort van 'opgevoed' wordt om macro's te haten. Maar als je een beetje luchtig naar kijk, vind je niet dat de state functies nu een mooie duidelijke syntax hebben? Duidelijke blokjes voor de sub-states.

[MOVisser]

Jongens, jongens.....
Hoe we het huidige virus aanpakken daar zijn de meningen ook al over verdeeld.
Er zijn vele wegen, die naar Rome leiden is een gezegde. Zo ook hier.

Ik heb een Arduino en heb er al wel wat mee geëxperimenteerd. Downloaden van standaard door derden gemaakte prog's .
Achtergrond info en het hoe en waarom van het programmeren voor de Arduino is dan meer dan welkom. Ik heb vroeger Basic's gedaan. Ja, Ja.

Als ik de Arduino zou willen inzetten in dit geval, dan is dat voor de spoorbaan (gaat dit forum over). Ik zie dan graag standaard programma's te gebruiken voor de spoorbaan (overweg, knipper led's, of verwijzingen naar reeds bestaande programma's  etc..), met aanwijzingen waar en wat aan te passen om tot een bepaald doel te kunnen komen.

Zo zou er bv een 20 a 30 tal standaard prog's ter beschikking kunnen staan aan ons (als leken).
- knipper licht, verkeerslichten;
- aansturen servo's : wissels, deuren, draaiplateau's;
- aansturen magneten FC systeem;
- wisselende binnenhuis kamer verlichting;
- dag en nacht ritme,
........

Ronald Visser
 

[bask185]

Ik zal in de loop der tijd iig deze dingen opleveren:
- ahob + aki
- dag nacht regeling voor licht
- ben nu bezig met Selectrix
- knipperlichtjes voor politie auto's en dat soort werk.

Wat betreft Servo, wissels en draaidingen. Daar heeft Rudy Boer uitgebreide filmpjes over gemaakt. Alleen hij gebruikt dan een library (servo.h, stepper.h etc) en doet de rest in zijn .ino bestand. Dat werkt, maar het is niet geoptimaliseerd.

Wat ik natuurlijk wel kan maken, is een library, of module zoals ik het noem, te maken waarmee je gemakkelijker je draaischrijf kan bedienen. Alleen dan moeten we misschien eerst bespreken hoe we dat ding willen aansturen. Dat kan met 2 knopjes, voor naar links en naar rechts draaien. Met een druk op de knop, kan hij dan naar de volgende positie draaien. En dan kunnen we hem 1 malig deze vaste posities inleren. En als we de knopjes tegelijk in drukken, kunnen we schijf laten homen indien dat mogelijk is. Je ziet: ideeen spoelen binnen terwijl ik dit tik.

Je hebt verder ook het mardec programma. Als ik het me goed herinner luister dat programma de DCC bus af en kan daarmee servo's aansturen voor wissels. Het zal vast nog wel meer kunnen. En je hoeft geen woord te programmeren. Je kan via de terminal de arduino in kwestie programmeren.

Ik ben zelf ook druk bezig met mijn eigen elektronica en communicatie bus te bouwen. Als dat af is, kan ik kijken of het ook handig is voor anderen.
Programma ziet er zo uit:

Wat kan het straks?

simpele pendeldiensten maken, wisselstraten aan drukknopjes van je schakelpaneel linken, je kan zelf wissels direct aansturen en de bezetmelders worden doorgegeven. De pendeldienst, ben ik nog mee bezig en ik moet nog seinen toevoegen en dat wat me nog te binnenschiet: lichtcircuits schakelen. En ik hoorde net ergens het woord 'draaiplateau' vallen dus dat ook 
elektronica architectuur:



Programma kan ook op een raspberry pi draaien

[MOVisser]

 

[bask185]

@Timo, it has been done!

[Timo]

Hoi Bas,

Zoals ik je ook al persoonlijk heb gezegd, is al goed Jij pakt het ook sportief op Als alles weer een beetje normaal is in de wereld nodig ik je uit voor een biertje

Maar ff for real. Ik weet dat je als C++'er een soort van 'opgevoed' wordt om macro's te haten. Maar als je een beetje luchtig naar kijk, vind je niet dat de state functies nu een mooie duidelijke syntax hebben? Duidelijke blokjes voor de sub-states.

Daar moet ik je gelijk in geven Maar je voegt daarmee wel extra (programma specifieke) syntax toe. En dat kan je zien als onleesbaar maken, je maakt er als het ware een uitbreiding op de taal mee die je eerst moet leren. Hoeft dus ook niet slecht te zijn, maar alleen C/C++ kennen is niet meer genoeg. Of dat het waard is is aan de gebruiker.

Maar het maakt het wel duidelijk hier ja. Dat komt ook wel omdat de switch() een beetje een ondergeschoven kindje van C++ (maar eigenlijk ook al van C) lijkt. Onderhuids eigenlijk niets meer dan een stel goto's met weinig hulp en rommelige syntax. Ik mis alleen even een gewoon compleet programma ermee om er meer nuttigs over te kunnen zeggen

@MOVisser, tuurlijk leiden er meerdere wegen naar Rome, dat is de discussie ook niet. Het is alleen de vraag of je zelf gaat rijden of dat je de (Tesla) autopilot aan zet. En nee, dat hoeft zeker niet als je liever zelf rijdt. Maar dan kan het zijn dat je vol de file in rijdt of dat je halverwege liever een andere chauffeur wilt

En voor je problemen, zoals Bas eigenlijk ook al aan geeft zijn je beschrijvingen te vaag. Alles om een servo aan te sturen zit al standaard in de IDE in de vorm van de Servo() library. En een wissel of FC magneer sturen is gewoon met digitalWrite() (en de benodigde hardware) te doen. Ik denk ook dat de condities waaronder je iets wilt doen voor de uitdagingen zorgen.

Een Arduino/microcontroller/PC doet niets vanzelf en doet niets wat hem niet verteld is. En jij bent pas in staat hem dat te vertellen (te programmeren dus) als jij exact kunt omschrijven wat er wanneer en onder welke conditie gedaan moet worden Vandaar dat je project plannen zo belangrijk is. Dus niet 20% code schrijven, 80% debuggen maar 20% project definiëren, 20% code schrijven, 40% debuggen en 20% documentatie (/ commentaar) schrijven Dat maakt elke stap een stuk relaxter dan 80% debuggen en je eindigt met leesbaardere / betere code ook nog


Timo

PS Wat heb je tegen arme millis()

[bask185]

De switch-case is een van de meest handige en efficientste constructies die er is. Als het goed is, is dat 'stelletje goto's slechts 1 goto of een long jump in assembly.

Als je oplopende cases heb dan heb je een grote kans dat een switch-cade zich transleert naar een jump-table. De datapointer van je programma wordt dan afhankelijk van de switch variabele opgehoogd en dan vindt de long jump plaats. Een switch-case is dan ook altijd sneller dan een if-else keten. Het springen naar case 40 neemt net zo veel instructies in beslag als het springen naar case 0.

 Je moet bedenken dat bij elke if conditie zo'n 'goto' in je programma er bij komt in de assembly.

Over millis. De rede staat in de bijlage. Je moet eerst 4 bytes ophalen en dan 1 voor 1 aftrekken van 4 andere bytes voordat je dat resultaat met nog meer bytes vergelijkt. + Je hebt 4 bytes aan geheugen nodig per getimede actie.

Ik kijk slechts of 1 enkele byte al 0 is of niet. Het is simpelweg vele malen sneller dan millis().


En over dat biertje... Een corona lekker met limoentje

[meino]

@bas en @timo

Als oude man amuseer ik me best met jullie discussies. Gelukkig kan ik me zelf prima redden.
Je commentaar over het gebruik van het switch statement onderschrijf ik, echter niet uit performance oogpunt, maar gewoon omdat de code helderder wordt.
Overigens in sommige kringen wordt er op het gebruik van het switch statement ook zeer afwijzend gereageerd. Niet alleen het switch statement zelf, maar vooral het gebruik van de break of continue statements die je eigenlijk altijd nodig hebt. Dit naar aanleiding van een artikel uit 1968 van Edgar Dijkstra met de titel "Goto statement considered harmful". Een artikel dat niet alleen gaat over de goto, maar ook over andere statements die de programma flow opeens verplaatst, zoals de longjump, maar ook de break en continue (die weliswaar toen nog niet bestonden, C moest nog ontstaan, maar die ook aan de definities van dit artikel voldoen).

Even iets over de performance, eind jaren 90, begin 2000 ben ik erg bezig geweest met Gnu C compilers i.v.m. performance issues. Uit alle testen die we toen gedaan hebben bleek dat je het erg bont moest maken met je code om veel invloed op de performance te hebben, meestal wist de optimalisator van de compiler de snelste code te genereren. Aangezien onder de motorkap van de Arduino IDE ook Gnu zit, ga ik er van uit dat ook hier geoptimaliseerd wordt. Verder geloof ik niet dat voor onze hobbytoepassingen we de grenzen van de performance opzoeken. Dus ik zelf maak me daar niet druk over en vind ik de helderheid van de code belangrijker.

Groet Meino

[PaulRoman]

@Meino: Edsger Dijkstra

[Timo]

De switch-case is een van de meest handige

Handig, ja. Efficiënt voor code, nee. Zo moet een case bijvoorbeeld statisch zijn. Ook vind ik de syntax een gedrocht. Is niet voor niets dat jij die verstopt met macro's

Je moet bedenken dat bij elke if conditie zo'n 'goto' in je programma er bij komt in de assembly.

Bij if'jes wel, maar dat is (meestal) geen echte vervanging van een switch(), dan ga je naar else-if'jes. En dan heb je geen goto per state meer, toch?

Over millis. De rede staat in de bijlage. Je moet eerst 4 bytes ophalen en dan 1 voor 1 aftrekken van 4 andere bytes voordat je dat resultaat met nog meer bytes vergelijkt. + Je hebt 4 bytes aan geheugen nodig per getimede actie.

Dat je altijd 4 bytes nodig hebt is niet waar Als je minder dan 256ms wilt bijhouden heb je genoeg aan 1 byte. 2 bytes voor <1024 etc. Geen enkel probleem!

Maar ik vind die overhead voor een centrale timing echt wel minimaal. Doe ergens een deling (door een niet macht van 2 ) in je programma en je bent er langer mee bezig En laat je dat nu juist aan de lopende band doen in je ISR , die duurt nu veeeele malen langer dan die van millis() + tig keer millis checken Dus misschien wil je dat dus nog eens herzien  Okay, je kunt er vanaf door gewoon een != te doen Maar met de hoeveelheid taken die ik normaal in programma's gebruik + de overhead in code + dat je nu alleen makkelijk 1, 10, en 100ms kunt timen vind ik het niet waard Nogmaals, het staat je vrij!

Ik kijk slechts of 1 enkele byte al 0 is of niet. Het is simpelweg vele malen sneller dan millis().

Dat is vals spelen, je hebt nu ook extra overhead in je ISR Dus je winst is wel minimaal.

En over dat biertje... Een corona lekker met limoentje

Dat werkt wel virus dodend

@Meino, harmful is misschien wel een erg krachtig woord maar vind wel dat goto's in een hogere taal geen plaats meer hebben. Maar vind break en continue dan nog wel kunnen. Daar bepaald de taal/syntax namelijk zelf waar de jump heen gaat dus volgt het de normale code-flow.

En ben het eens met de performance. Je moet heel goed zijn in assembler wil je beter code voor een complex project kunnen maken. En ook een C-guru zijn als je slimmer wilt zijn dan de optimalisator. En zelfs dan nog blijft het een afweging tussen hele efficiënte code en heel efficiënt code kunnen schrijven

Goed, nu neemt iedereen even een slok van zijn (/haar) koffie/biertje!



Timo

[meino]

@PaulRoman
Dat dacht ik ook, maar niet zeker van de titel van dat stuk, even op Internet gecheckt, en de eerste hit was de site van CWI, daar werd hij Edgar genoemd, dus dat maar gebruikt.

@Meino, harmful is misschien wel een erg krachtig woord maar vind wel dat goto's in een hogere taal geen plaats meer hebben. Maar vind break en continue dan nog wel kunnen. Daar bepaald de taal/syntax namelijk zelf waar de jump heen gaat dus volgt het de normale code-flow.

Daar ben ik het helemaal mee eens. Mijn opmerking kwam voort uit een er/aanvaring die ik ooit eens heb gehad met een programmeur, vers van de universiteit, die de meest ingewikkelde if-then-else constructies gebruikte (en je wilt niet weten hoe zijn for loops er uitzagen) om het gebruik van break en continue te voorkomen. Dat had hij destijds namelijk geleerd, want die mochten niet gebruikt worden.

Goed, nu neemt iedereen even een slok van zijn (/haar) koffie/biertje!

Doen we. Misschien niet zo'n gek idee om als de crisis weer over is, elkaar eens ergens te ontmoeten.

Groet Meino

[bask185]

Meino,

Zoek je alsjeblieft de Duff's device eens op. Ga je geweldig vinden. Jij ook Timo   

@timo

Die ISR overhead valt reuze mee. uControllers kunnen razendsnel getallen delen met een enkele instructie. Voor m'n 8051 heb ik de DIV instructie waarbij de gedeelde waarde in m'n A wordt gestopt en het restant in B. Ik moet alleen eerst a en b laden. Ik denk dat een if(!(_1ms % 10) 5 regels assembly worden.

Het uitlezen van een timer in het programma zijn slechts 2 regels assembly code en een derde om een nieuw getal in de timer te laden.

Als je millis aanroept worden er al 4 registers gevuld (millis zelf heeft ook nog overhead dingen onderhuids) dan moet je de prev millis er van aftrekken als we met een seconde werken zijn dat al 2 substractions. Die 2 bytes die je daaraan overhoudt moet je nog met 2 andere vergelijken. En dan moet je millis opnieuw aanroepen en de 4 registers in de previous kopiëren. Als je voor de prev millis een 16 bitter pakt dan heb je buggy gedrag na 66 seconde.  Je moet hiervoor echt een unsigned long gebruiken. Ik heb het net getest. + Dat ISR doet ook nog die micros timer afhandelen.

Ja en wat ik echt naar vind, is het tikwerk wat bij millis komt kijken. Er is om dit probleem op te lossen een leuke library genaamd FireTimer. Doe zou ik nog als alternatief kunnen overwegen.

Dan mag je tikken:

Code: [Selecteer]

if(someTimer.fire()) {
  // actie
}
SomeTimer is hier een object die je kan instellen met een interval naar keuze. Die werkt dus met millis en micro's.

Dat beetje overhead wat ik misschien in m'n ISR heb, is niks vergeleken met de millis methode.

Ik moet maar eens proberen om assembly code te maken met arduino. Ben nu wel benieuwd naar hoeveel instructies precies we gebruiken.

About switch-case. Hij is zo efficiënt doordat de labels static zijn. Ik denk als je variabele case labels ga introduceren dat mensen gek worden omdat je de simpele logica verpest.

Nu ben ik ook wel eens een break vergeten en dat is natuurlijk vervelend. Maar we mogen toch blij zijn dat we ze hebben. Ook een fallthrough switch case kan erg handig zijn. Die wil ik nog wel eens gebruiken. Ik zelf zet de case labels wel eens op dezelfde tab als de switch omdat het.... labels zijn.. assembly restanten.

Ik heb overigens nog nooit een continu, of een do-while gebruikt. Ik gebruik eigenlijk geen while. De kans dat ik een 'goto' tik is nog groter dan dat.

[bask185]

Wat!! Je zou millis kunnen casten of AND'en dan red je het wel met 2 bytes