BeneluxSpoor.net forum
Vraag en antwoord => Digitaal => Topic gestart door: bask185 op 27 februari 2020, 15:42:17
-
Mede hobbyist.
Loop je wel eens tegen de lamp wanneer je je Arduino programmeert? Groeit je .ino uit tot een gigantische draak? Heb je wel eens moeite met het voor elkaar krijgen van sommige taken? En lukt je niet om een programma te bouwen zonder zoveel bugs? Dan heb ik misschien iets wat je zou kunnen helpen. (y)
Bugs komen in allerlei vormen, je vergeet iets te tikken, een waarde past niet in een variabele, je maakt denkfouten of je doet iets fout zonder dat je weet waarom het fout is ???
Ik heb voor zowel beginnende als gevorderde programmeurs een korte driedelige cursus geschreven in Nederlands (In Jip en Janneke taal) over het programmeren van een Arduino. De hoofddoelen van deze cursus zijn om jou te helpen in het voorkomen van fouten, je te helpen met het opzetten met ingewikkelde processen en om je te helpen om je code zowel netjes, simpel als leesbaar te houden.
In dit eerste deel, leg ik slechts de meeste relevante elementen van de programmeertaal uit. Ik geloof namelijk dat je als nieuweling al veel fouten kan verkomen als je simpelweg weet wat je aan het doen bent. Dit deel bevat tevens hier en daar ook handige truuks waar je wat kan hebben.
In deel twee laat ik je zien hoe je een simpele state diagram kan maken en hoe je dat heel duidelijk en simpel kan omzetten in uiterst simpele code met een zeer geordende structuur. Als voorbeelden laat ik zien hoe we vanuit scratch een AHOB met servo motors programmeren. En in stapjes werken we onze weg naar de top :D
Deel 3 is misschien voor de meer gevorderde programmeur. Daarin leg ik uit hoe je je computer voor je code kan laten maken. Met een python script kunnen we dan een grafische state diagram omzetten in een code structuur wat slechts een beetje invulling vereist. Een nieuwe projectfolder wordt vervolgens voor je aangemaakt en je kan dan multitasken tot dat je een ons weegt.
We gaan dan van:
(https://raw.githubusercontent.com/bask185/State-Machine-Scripts/master/images/demo.png)
Naar:
(https://raw.githubusercontent.com/bask185/State-Machine-Scripts/master/images/demoStateMachine.png)
in slechts een paar seconde en een druk op een knop.
KLIK OP MIJ (https://github.com/bask185/State-Machine-Scripts/blob/master/images/Goed%20programmeren%20in%20C%20deel%201.pdf) voor de link naar een de online cursus (je hoeft niks te downloaden).
Aan degene die geinteresseerd zijn, veel lees plezier ;)
Bas
P.S.
Mocht iemand het niet eens zijn over hoe ik sommige dingen uitleg, schrijf dan je eigen tekst ;D. Ik ben wel geinteresseerd in dingen die echt fout zijn (hoewel ik die volgens mij niet gemaakt heb) en tik fouten.
-
Ziet eruit als best een lap werk. Heeeeeel snel doorgebladerd.
Ik zal 'em gaan lezen. Ik *ben* eruit gekomen toen ik twee jaar geleden aan het arduino-en ging, maar ik heb een python achtergrond en mis dus bakken met vingervlugheid qua types declareren enzo :) Er staat vast spul in je document dat ik niet weet.
Reinout
-
Top Bas ik ga je topic volgen en de cursus door nemen (y)
-
Interessant Bas, ik ga het eens doorlezen en op me in laten werken ...
Ik ben wel geinteresseerd in dingen die echt fout zijn (hoewel ik die volgens mij niet gemaakt heb) en tik fouten.
De eerste: §2.4 eindigt abrupt, zonder het bereik van een long long te vermelden.
-
.....en tik fouten.
“Tikfouten”... is één woord... ;)
Gr, Bert
-
Interessant (y) zou misschien zelfs iets kunnen zijn voor mensen met een blinde vlek voor software zoals ik...
De interesse was alweer weg na bladzijde 6. Dit is echt niets voor mij. Ik krijg er de kriebels van.
-
Hoi Bas,
mooi initiatief!
Ben benieuwd naar deel 2 en 3!!
Theo
-
Bas,
(y) (y)
Mvg Ronald Hofmeester.
-
“Tikfouten”... is één woord...
Programmeertaal, codestructuur, driedelige en projectfolder ook...
Engelse ziekte heet dat.
-
(y) leuk initiatief, kom ik er misschien ook nog eens achter hoe het zelf te programmeren is.
ps:
.....misschien zo zelfs wel te begrijpen door de vele houtnerf fotografen en Neerlandicus op dit voor speelgoedtreinjes met al zijn facetten bedoelde forum ;D (y).
-
Engelse ziekte heet dat.
Daardoor haak ik vaak na drie zinnen af. Ik moet veel te veel nadenken wat er eigenlijk bedoeld wordt. En dan ben ik de draad van het verhaal kwijt.
-
.....misschien zo zelfs wel te begrijpen door de vele houtnerf fotografen en Neerlandicus op dit voor speelgoedtreinjes met al zijn facetten bedoelde forum
Bask185 vraagt er zelf om.
Op github zie ik op mijn telefoon alleen maar een grijze vlek op de plaats van de .pdf. Als ik het bestand download, zie ik de tekst wel.
Behalve tikfouten zie ik ook nog een paar d/t fouten. Als de vorm niet goed is, komt de inhoud ook niet over.
Ik geloof er niet in dat je programmeren van een Arduino met C++ in jip-en-janneketaal kan uitleggen. Ik begrijp je tekst, maar ik heb in een grijs verleden (1984) wel computerkunde gestudeerd.
-
Hoi Bas!
Mooi compact document! Tenminste, compact voor wat je allemaal vertelt. Maar ik denk dat de snelheid daardoor voor een nieuweling misschien wel wat hoog ligt. Maar zeker wel een nuttig verhaal (y)
Nu heb ik de tekst niet geheel gelezen (eigenlijk vooral het begin waar de nieuwelingen instromen). Een paar zaken waar misschien iets meer aandacht aan gegeven mag worden die jij "vanzelf" goed doet maar ik vaak mis zie gaan bij beginnelingen. Ik zou het dus verder naar voren halen voor de slechte gewoontes af te leren voor ze erin slijten ;D Ik schrijf het hier maar op als "eigen tekst" als aanvulling voor anderen ;)
Naamgeving
De compiler kan naamgeving en variabelen geen sikkepit schelen. Het is een hulpmiddel voor ons mensen. Het heeft daarom weinig zin om voor korte namen te gaan omdat het zo lekker kort is. Gebruik liever een langere naam die exact aangeeft wat het is en waardoor de code direct duidelijk is. Vaak kan dit ervoor zorgen dat je code al duidelijk is zonder dat je commentaar toe hoeft te voegen. Scheelt het je dus toch typen ;D
Dus 'errorLedPin' in plaats van 'led2' of 'l2' bijvoorbeeld. Of 'buttonUpPin' in plaats van 'up'.
Syntax
Hoe geef je de code weer? Ook hier geld, de compiler is niet zo kieskeurig. Die heeft eigenlijk maar twee eisen: elke statement eindigt met een ; en elk openend haakje ( { [ heeft een sluitend haakje. De rest is weer is het vooral gereedschap voor de mens om het leesbaar te houden, grijp dat gereedschap met beide handen aan!
Ik denk dat () en [] vrij snel duidelijk zijn waarvoor ze dienen. Als je nieuw begint is {} misschien iets onduidelijker. Het groepeert een blok code zodat je het bijvoorbeeld als één blok wel of niet kan doen.
Consistent
Zag dat je dit later wel aanhaalt maar vind het oooo zo belangrijk. C/C++ geeft je veel vrijheid in hoe je de code neerzet. Maar gebruik dit als voordeel. Spring bijvoorbeeld consistent in (of juist niet). Gebruik dezelfde schijfwijze, taal en notatie voor variabelen. Dus niet 'aantalTreinen' en 'Number_of_Wissels' want dan blijf je opzoeken hoe je het ook al weer moest schrijven.
Wel kan het zijn dat als je heel erg je eigen stijl maakt dat als je een vraag erover op een forum stelt dat mensen je vraag links laten liggen omdat ze het te complex leesbaar vinden. De als "standaard" geaccepteerde regels bij Arduino zijn
- Niets volgt na een ; (uitzondering in een for())
- Na een { spring je in, na een } spring je terug
- Variabelen schrijfJeCamelCase en UpperCamelCaseVoorClasses (en MisschienVoorConstanten)
- Niets volgt na een { of } (uitzondering voor het sluiten van een definitie) (sorry Bas ;))
Zeg dus niet dat iedereen zich er aan moet houden, maar alleen dat je wel in de minderheid bent en mensen het dus als "onleesbare code" kunnen ervaren als je van veel punten afwijkt. Maar belangrijkste voor jezelf is om consistent te zijn in hoe je het doet. Dan vallen jou fouten sneller op.
Compiler heeft gelijk!
Veel beginners komen er al vaak mee dat de compiler iets fout doet of dat ze niet snappen waarom de compiler het niet met ze eens is. Maar echt waar, de compiler doet het goed en vertelt je zelfs in de foutmelding waar je een fout hebt gemaakt. Erg handig om te gebruiken dus :angel: En je kan nog meer hulp krijgen als je in de Arduino IDE bij instellingen "compiler warnings" op "All" zet.
Okay, heel af en toe maakt de compiler (of de Arduino IDE laag) een foutje. Maar echt, die kans is heeel klein, ga daar in ieder geval maar net vanuit. :police:
Arduino is C++11
Vergeleken met gewoon C kent C++ een aantal handige stukken gereedschap. Zo kan je 'const' gebruiken als veilig alternatief (het is echt een variabele en dus reageert zo, ook in de errors/warning) van een macro (#define) voor dingen die tijdens het draaien van het programma (runtime) niet wijzigen.
Timo
PS [Plaag modus aan ;)] Ja ik vind dat zo'n hele trap aan accolades zeker wat toevoegt daar je in één oogopslag kunt zien of je (sluitende) haakjes mis. De discussie of haakjes of instappen beter is is een andere. Maar aangezien ze in C/C++ nodig zijn geef ik ze liever overzichtelijk weer. Het echte probleem is natuurlijk de hoeveelheid geneste blokken code.
-
De eerste: §2.4 eindigt abrupt, zonder het bereik van een long long te vermelden.
noted! (y)
aangepast en een verkeerd getal geupload (moest er nog 1 van aftrekken) er kloppen nog meer dingen niet. Dus deze komt nog.
Ja ik vind dat zo'n hele trap aan accolades zeker wat toevoegt daar je in één oogopslag kunt zien of je (sluitende) haakjes mis
Dat is enigszins waar, maar elke editor heeft tegenwoordig standaard bracket highlighting, zelfs die IDE van arduino heeft het. De editor Kate deed zelfs hele blokken highlighten. Dat is echt de fijnste tool die ik ooit gebruikt heb. Ik heb in Vs code nog niet gevonden hoe dit moet met die ellendige Json files. Ben jij misschien zo'n diehard die in VIM programmeert?
Het tikt soms ook enigszins wat vervelender, want ik vergeet er ook wel eens eentje, maar ik vind het zo fijn lezen. Het lijkt zo net op Python :P. Ik heb overigens in meeste code voorbeelden er geen gebruik van gemaakt.
Maar ik denk dat de snelheid daardoor voor een nieuweling misschien wel wat hoog ligt.
Mowa, je moet zo denken. Je hoeft niet alles in een keer te onthouden. Dat is onmenselijk. Ik heb mijn C++ boek ook niet in een dag gelezen.
Niets volgt na een { of } (uitzondering voor het sluiten van een definitie) (sorry Bas ;))
Ik heb ook wel eens gehoord dat het ook geaccepteerd wordt als er er een else achter een } wordt gezet... :'(
Ik heb overigens in paragraaf §6.5.2 camelCase en underscores een klein woordje gedaan over naampjes. Misschien dat ik de paragraaf beter kan hernoemen naar 'naamgeving'. Dat vind ik wel een goede.
Programmeertaal, codestructuur, driedelige en projectfolder ook...
Engelse ziekte heet dat.
Tik fouten is legit een woordgrapje van me geweest. Dit komt van iemand die wel eens in zijn code zet:
bool PIGS_CAN_FLY = true;
while(PIGS_CAN_FLY == true) {
projectfolder twijfelde ik aan omdat folder mij een Engels wordt lijkt. En ik vind onze taal verre van perfect. Er zitten overbodige elementen in, er ontbreken elementen en er zit onlogica in. Ik vind het zelf stom dat we zo veel aan elkaar schrijven. Ik heb het in ieder geval aangepast. En bedankt voor het aanwijzen.
Slim dat ik ben ??? had ik natuurlijk niet eerst een spelling check gedaan. Ik heb er zelf ook een paar uitgepikt. Er staat ook ergens 'unsiged', 'intellingen'. Ik had hem ook uitgezet vanwege de rode kringels onder alle Engelse woorden.
Behalve tikfouten zie ik ook nog een paar d/t fouten. Als de vorm niet goed is, komt de inhoud ook niet over.
Wees dan tenminste zo vriendelijk om de paragraaf nummers te vermelden. Ik kan hier niet zo veel mee. :-\
Normaliter maak ik geen dergelijke fouten... wanneer ik schrijf. Mijn basisschoollerares heeft me goed opgevoed en ik ben bekend met alle regels. Wanneer ik tik echter merk ik dat mijn taal gevoel het toch laat afweten daarom ontglippen me toch nog een paar d/t. + ik heb nooit geen tik cursus gevolgd niet. Dat zal ongetwijfeld ook geen positieve bijdrage leveren. Programmaren kan ik, maar tikken..... :'(
Ik ben nu bezig met een meer uitgebreidere 'scan' van m'n docu op foutjes. Is best veel werk. ::) En ik wil §6.5.2 updaten met wat van Timo's advies.
Ik zal deel 2 beter controleren, mijn excuses.
Bas
EDIT:
Ik heb denk ik de meeste fouten er uit gevist. Het waren er verdomd veel :-(
-
... Wees dan tenminste zo vriendelijk om de paragraafnummers te vermelden. Ik kan hier niet zo veel mee.
Als je me een e-mailadres pb't, stuur ik je een geredigeerde .pdf
-
Dag Bas
Een puik stuk werk, mijn complimenten (y). Ik zie dat Timo al gereageerd heeft, dus daar ga ik verder niks aan toevoegen ;).
Een paar punten, over de spellingfouten, die maak je, zeker als je een groot stuk schrijft. Als anderen zich daar aan storen, jammer dan. Die kun je altijd nog later corrigeren zolang ze maar door gegeven worden.
Over de kritiek op de z.g. "Engelse ziekte", dat vind ik zelf een moeilijk punt. In zekere zin ben ik het er wel mee eens dat je moet proberen om dat te vermijden, zeker als het stuk bestemd is voor niet IT mensen. Aan de andere kant het is niet altijd mogelijk om een Engels begrip in een enkel Nederlands woord te vangen, probeer maar eens de begrippen "input" en "output" in een enkel Nederlands woord te vangen. Verder de doelgroep voor dit werk zijn toch mensen die met programmeren willen beginnen en als je alles in het Nederlands zou willen vertalen, dan ontstaat er later een probleem, omdat alle andere informatie op het Internet toch weer in het Engels is. en men dan niet weet waar ze op moet zoeken. Ik word er nog wel eens bijgehaald als iemand in de omgeving een probleem met zijn PC heeft, die natuurlijk in het Nederlands ingesteld staat, en dan heb ik altijd moeite om een link te leggen tussen de informatie op het internet en de instellingen op die PC.
Het enige waar ik zelf wat moeite mee heb is je uitleg van de "class" (niet classe, dat zou klasse moeten zijn) als een uitbreiding van de struct. Dat vindt ik zelf wel erg kort door de bocht, omdat juist door het gebruik van "class" en de daarvan afgeleide objecten, de taal C++ fundamenteel onderscheiden is van C. Maar ik besef te goed, dat dat binnen het kader van dit stuk bijna niet te uit te leggen is. Daar voor zou je een apart verhaal moeten hebben over Object georienteerde programmering, dat is n.l. een echte "Paradigma shift" in het het programmeren en ontwerpen.
Groet Meino
-
Meino, de Engelse ziekte is niet het onnodig (!) gebruik van de Engelse taal, maar het gebruik van teveel spaties. Ofwel het los schrijven van woorden die aan elkaar horen. Twee zelfstandige naamwoorden, waarvan het eerste iets zegt over het tweede (boekenkast en niet boeken kast). In het Engels worden dit soort woorden niet aaneen geschreven. Vandaar de naam Engelse ziekte als dit in het Nederlands wordt overgenomen.
MvrGr,
Paul
-
Paul
dat wist ik niet. Als iemand die zelf ruim 35 jaar veel in het Engels geschreven heeft, weet ik dat ik me zelf daar ook vaak aan bezondig (woorden los knippen) en dat ik soms moeite moet doen om dat te onderdrukken. Ik zelf denk, dat we dat in het Nederlands langzaamvan het Engels aan het overnemen zijn.
Groet Meino
-
... Engelse ziekte is niet het onnodig (!) gebruik van de Engelse taal, maar het gebruik van teveel spaties.
... zolang ze maar door gegeven worden.
...de begrippen "input" en "output"
Invoer en uitvoer.
Je kunt niet voor beginnende én gevorderde programmeurs in het Nederlands en in een jip-en-janneketaal schrijven.
Kies één doelgroep en pas daar je stijl en inhoud op aan. Je begint nu al vrij snel over structs en pointers, de beginner haakt dan al af en pas tegen het eind begin je over basisdingen als if then else en do while, dat zou andersom moeten zijn. In deel 2 kun je dan voor een doelgroep schrijven met een hoger beginniveau.
Schrijf objectief en laat ook je tekst proeflezen door iemand uit je doelgroep vóórdat je de tekst publiceert.
-
[off topic] Een 3e vorm van Engelse ziekte is de zinsdeelvolgorde. Vertaling door een Nederlander van zijn Engelse zinnen levert bijvoorbeeld dit op: "Dit systeem wordt gebruikt bij vrijwel alle objecten. Meer logisch lijkt mij: "Dit systeem wordt bij vrijwel alle objecten gebruikt." -> (ont-)koppeling van hulpwerkwoord en voltooid deelwoord [/on topic]
-
Het enige waar ik zelf wat moeite mee heb is je uitleg van de "class" (niet classe, dat zou klasse moeten zijn) als een uitbreiding van de struct. Dat vindt ik zelf wel erg kort door de bocht...
Dat mag misschien zo zijn, maar geloof mij.. op private variabele en een beetje syntax verschillen na, zijn ze onderhuids nauwelijks verschillend.
Je begint nu al vrij snel over structs en pointers, de beginner haakt dan al af en pas tegen het eind begin je over basisdingen als if then else en do while, dat zou andersom moeten zijn.
!!!
P.S.
Mocht iemand het niet eens zijn over hoe ik sommige dingen uitleg, schrijf dan je eigen tekst ;D.
Maar for real. Structs en arrays hebben wel een eigen hoofdstuk genaamd 'geavanceerde datatypes'. En voor de eerste pointer uitleg staat specifiek deze zin: "Pointers zijn voor beginnelingen erg moeilijk te behappen dus als je dit nog niet snap, kan je het negeren.".
Ik kom ook met het meest praktische voorbeeld mogelijk. Ik snapte jaren lang ook niets van pointers. Ik snap ze pas sinds een jaar of twee. Bij alle uitleg wat ik had, snapte ik nooit het 'voordeel'. Het standaard voorbeeld is het klassieke swap voorbeeld, waarbij je in een functie de waardes van 2 variabelen moet uitwisselen. Dat kan je ook doen met een 'normale' lokale variabele, dus ja waarom moeilijk doen met een pointer?
Bij het passing by reference stukje, leg ik specifiek de noodzaak uit. Ik leg uit dat een functie op de standaard manier slechts een waarde kan retourneren. En dat je dat alleen kan oplossen door pointers. Dit was ook het voorbeeld waardoor ik het ging snappen. Ik heb ook getracht om het zo duidelijk en simpel als mogelijk te houden. Pointers zijn nu eenmaal een payne op sommige momenten.
Je kunt niet voor beginnende én gevorderde programmeurs in het Nederlands en in een jip-en-janneketaal schrijven.
Hoezo niet? Deel 1 is trouwens ook voornamelijk voor beginnenden. Als gevorderde zou ik slechts even kijken of er iets in staat wat ik nog niet wist. Bitfields ken ik ook pas sinds een maand of zes. Ik heb ook uitgelegd:
"In dit eerste deel, leg ik slechts de meeste relevante elementen van de programmeertaal uit. Ik geloof namelijk dat je als nieuweling al veel fouten kan verkomen als je simpelweg weet wat je aan het doen bent."
Deel 2 gaat voornamelijk over state machines, daarbij begin ik simpel met zo'n switch-case en ik breid het steeds verder en verder uit zodat het telkens overzichtelijker en makkelijker wordt. Uiteindelijk werk ik m'n weg naar een structuur waar ik een zevental macro's in heb verwerkt. Op dat moment is het voor sommige gevorderden ook wel interessant om even een kiekje te nemen.
Bas
-
Pointers gebruik je om een geschakelde lijst van records ('structs') te maken, of een stapel, of een wachtrij, of een boom, of andere structuren waarbij je van te voren niet weet hoeveel elementen er zijn (hoeveel ruimte je nodig hebt).
-
Dag Bas
Toch even een kleine reactie. Daar zal ik het bij laten, omdat dit eigenlijk niet thuis hoort op dit forum.
Dat mag misschien zo zijn, maar geloof mij.. op private variabele en een beetje syntax verschillen na, zijn ze onderhuids nauwelijks verschillend.
Ik had het over te kort door de bocht. Je hebt gelijk als je het puur fysiek bekijkt, je kunt een "class" als een "struct" met functies zien. Maar! op het moment dat je werkelijk begrijpt wat je met Klassen en hun objecten kunt doen, dan ga je fundamenteel anders ontwerpen en programmeren. Dat bedoelde ik met "Paradigme shift".
Ik weet niet of je ooit van de "Gang Of Four" gehoord hebt, maar hun boek over "Design Patterns" bevat nuttige informatie.
Groet Meino
-
Hallo Bas,
Als eerste wil ik je zeggen dat ik het een heel loffelijk streven vind om mensen voor wat programmeerwerk enthousiast te maken. Met wat basiskennis kun je zo al snel leuke dingen doen met bijvoorbeeld een Arduino. Rudy Boer doet wat dat betreft heel leuk werk, ook op dit forum.
Ik heb je document - waar je volgens mij heel veel werk in hebt gestoken - snel doorgelezen.Ik ben het wel met eerdere reacties eens dat je je doelgroep goed in het oog moet houden. Je schiet al snel je doel voorbij door teveel en te ingewikkeld te willen uitleggen. Ik ben bang dat een hoop "beginners" snel afhaken.
Dan nog even dit, omdat er in dit draadje regelmatig op wordt teruggekomen, niet omdat je hiermee "beginners" zou moeten plagen.
Mag ik je erop wijzen dat in C++ het "passing by reference" mechanisme iets anders is dan het mechanisme dat jij beschrijft. Dat kan worden gezien als "passing by pointer". Wat je nl. in dit laatste geval doet is een pointer als functie argument gebruiken. Deze pointer zelf wordt gewoon "by value" doorgegeven. Je kunt in de functie dan ook de pointer zelf niet veranderen. Wat wel kan is de inhoud van de locatie waar de pointer naar verwijst veranderen. En dat was altijd de gebruikte methode. Passing by reference is iets anders in C++. Zie de m.i. goede uitleg die je hier vindt.
https://www.geeksforgeeks.org/passing-by-pointer-vs-passing-by-reference-in-c/
Succes met je werk, maar houd het vooral eenvoudig als je voor beginners schrijft.
Paul
-
Paul,
Bedankt voor je input. Ik moet zeggen.... weer wat nieuws geleerd (y). Ik denk dat de simpelste oplossing is om het woord 'reference' door 'pointer' te vervangen. Dat volstaat voor deze context.
Vind je trouwens echt dat ik ingewikkeld uitleg? Ik probeer het simpel te vertellen, alleen sommige dingen zijn nu eenmaal iets minder simpel dan andere dingen. Ik heb het stukje 'structs' nog eens doorgelezen, maar de uitleg lijkt mij enigszins duidelijk voor beginners. De uitleg is in ieder geval compleet. Ik kan natuurlijk niet voor een beginner spreken. Maar tot en met de functies moet het toch duidelijk zijn ???
Deel 2 zal in ieder geval simpeler (en korter zijn) en daarin komen ook heel weinig nieuwe dingen naar voren.
mvg,
Bas
-
Bas en overige heren,
Met plezier lees ik dit en had het handboekje dan ook al uitgeprint om eerst maar eens snel door te bladeren. Op basis van de inspanningen van Bas om het zo zorgvuldig mogelijk te doen, zal ik de komende week versie 2 dan maar uitprinten en 1 krijgt een tweede leven.
Qua mijntrein-projecten past het prima. HDL krijg ik langzaam onder de knie, Arcomora begin ik te snappen en met Arduino maak ik ook al vorderingen.
Dit helpt me verder op weg. Dank voor de input en wat mij betreft volgt er nog meer.
Groeten Ad
-
Hallo Bas,
Als ik wat meer tijd heb zal ik je document wat nauwkeuriger doorlezen, en proberen wat meer gedetailleerde feedback te geven.
Mijn eerste indruk was dat je op een aantal plaatsen al kennis veronderstelt die een beginner nog niet heeft. Maar dat is een bekende valkuil als je zelf die kennis al wel hebt.
Mijn opmerking over "pass by reference" was vooral bedoeld om mensen niet op het verkeerde spoor te zetten. Als je nl. als beginner wat meer informatie gaat zoeken raak je helemaal in de knoop als je denkt dat het zgn. "pass by pointer" hetzelfde is. En de materie met pointers is in het begin toch wat weerbarstig.
Overigens is "pass by reference" in C++ wel de aanbevolen methode om functieargumenten te wijzigen. En als je ze niet wilt kunnen wijzigen "pass by constant reference ". En conceptueel simpeler dan het hele pointer verhaal.
Groet,
Paul
-
Bas,
Hierin moet ik Paul gelijk geven:
Mijn eerste indruk was dat je op een aantal plaatsen al kennis veronderstelt die een beginner nog niet heeft.
Echte beginners ben je vrees ik na een paar alinea's al helemaal kwijt.
Als je echt iets voor een volledige beginner gaat maken, begin dan eerst eens met het uitleggen en verklaren van alle Engelstalige termen, functies en begrippen, voor je er, logischerwijze, kwistig mee rond ga strooien.
Zelf heb ik in een ver verleden aan een groep die totaal geen basiskennis had de mappenstructuur van een harde schijf met 3 partities als volgt uitgelegd:
De schijf is een kast, een kast met 3 deuren (de partities), op deze deuren staan letters (C:, D: en E:), achter elke deur zit een aantal laden voor hangmappen (de hoofdmappen) met een eigen naam, de hangmappen kunnen per lade in groepen verdeeld zijn (de submappen) ook weer met namen; en in elke hangmap kunnen tabbladen geplaatst zijn (de sub sub mappen en verder).
Als je de echte beginner wilt bereiken zal je m.i. daarmee moeten gaan beginnen.
-
Hoi Bas,
Vind je trouwens echt dat ik ingewikkeld uitleg? Ik probeer het simpel te vertellen, alleen sommige dingen zijn nu eenmaal iets minder simpel dan andere dingen. Ik heb het stukje 'structs' nog eens doorgelezen, maar de uitleg lijkt mij enigszins duidelijk voor beginners. De uitleg is in ieder geval compleet. Ik kan natuurlijk niet voor een beginner spreken. Maar tot en met de functies moet het toch duidelijk zijn ???
Als eerste waardeer ik het heel erg dat je de tijd en de moeite neemt tot het opzetten van het document (y) (y).
Verder is het heel lastig van wie is nu een beginner en wie is een gevorderde programmeur.
Het gaat er om dat je binnen onze hobby een Adruino kan toepassen voor de meest uiteenlopende toepassingen.
Als beginner zal je je moeten verdiepen in de materie, en als gevorderde zal meer moeten focussen op hobby gerelateerde toepassing in plaats van het schrijven van het ultieme perfecte code.
Voor wat betreft het document, maak het zoals jij het wil maken.
Het is makkelijker als je het hele document klaar hebt (deel 1 t/m deel ...) om alles nog eens rustig door te lezen.
Dan zin en spelling aan te passen of verbeteren, onderwerpen/hoofdstukken verplaatsen zodat het beter aansluit in het document.
Het zal altijd lastig blijven om iets te schrijven wat bij iedereen aansluit.
Ik denk dat het met de inspanning die je in het document steekt een mooi document krijg wat je als referentie bij het schrijven van je code voor je project kan gebruiken.
Ben benieuwd naar deel 2 en de rest wat nog gaat volgen.
Mvg Ronald Hofmeester.
-
Bas,
Mooi stukje werk. Ik ben zelf ook al weer behoorlijke tijd bezig met Arduino. Is leuk om mee te werken en niet echt ingewikkeld. Echter weet iedereen die zelf code krast dat er zo nu en dan wel eens fouten in de listing voor kunnen komen en dan is het nalopen ervan best lastig. Zeker als het programma (sketch) enige omvang heeft. Er is wat mij betreft geen eenduidige manier om fouten op te sporen en te verbeteren.
En waarom ben ik van mening dat jou bijdrage zinvol is? Omdat iedereen er wel wat van kan leren. Ik werk ook vaak met XOD (xod.io) en het leuke daaraan is dat je in schema vorm je programma kunt opbouwen. Aan het eind van het werk komt er dan een sketch tevoorschijn waar je "u" tegen zegt. Dat klinkt leuk, maar omdat ik die sketch niet zelf heb geschreven is het lastig om te begrijpen waarom voor bepaalde oplossingen is gekozen. En in het zeldzame geval dat er toch een fout in zit, is die zo goed als niet terug te vinden.
Gezien de opmerkingen op Beneluxspoor zijn er mensen die enige tekortkomingen hebben geconstateerd en daar over berichten. Draagt alleen maar bij aan de kwaliteit van het product en zullen we allemaal ons voordeel ermee kunnen doen. Dus ga lekker door en in blijde verwachting van de andere delen wens ik je succes en wijsheid.
Richard
-
Beste hobbyisten,
Het heeft even laten wachten maar deel 2 van de cursus (https://github.com/bask185/State-Machine-Scripts/blob/master/images/Goed%20programmeren%20in%20C%20deel%202.pdf) is er! (y)
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. ;D
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.
-
Hoi Bas,
Ik heb weet niet alles gelezen maar je stuk over macro's trok even de aandacht :angel: Dit omdat ik duidelijk van het andere team ben. Team "macro's de wereld uit!" ;) Maar gelukkig heb je het een cursus C genoemd ;D Maar goed, dat is je eigen invulling, daar ga ik je hier niet verder mee lastig vallen. Mee eens ben ik het zeker niet ;D, maar het is jouw artikel (y)
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! :angel:
- 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 8)
- 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:
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? :angel:
Bovenstaande moet je wel luchtig lezen! Ik ben niet boos of zou nooit meer een kroket (en biertje? :angel:) 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 (y) 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
-
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.
-
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
-
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:
(https://i.imgur.com/UUb7uqM.png)
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 ;D
elektronica architectuur:
(https://images.beneluxspoor.net/bnls/naamloos5_1.png)
(https://images.beneluxspoor.net/bnls/naamloos3_1.jpg)
Programma kan ook op een raspberry pi draaien (y)
-
(y) (y) (y)
-
@Timo, it has been done!
-
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 (y) 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 :angel:
@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 ;D
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 ;D Dat maakt elke stap een stuk relaxter dan 80% debuggen en je eindigt met leesbaardere / betere code ook nog ;D
Timo
PS Wat heb je tegen arme millis() :o :P
-
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
-
@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
-
@Meino: Edsger Dijkstra
-
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. :-X Is niet voor niets dat jij die verstopt met macro's ;D
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 :angel:) in je programma en je bent er langer mee bezig ;D 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 ;D Okay, je kunt er vanaf door gewoon een != te doen :angel: 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 :angel: 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 ;D
@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 8)
Goed, nu neemt iedereen even een slok van zijn (/haar) koffie/biertje! ;D
Timo
-
@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! ;D
Doen we. Misschien niet zo'n gek idee om als de crisis weer over is, elkaar eens ergens te ontmoeten.
Groet Meino
-
Meino,
Zoek je alsjeblieft de Duff's device eens op. Ga je geweldig vinden. Jij ook Timo ;D
@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:
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.
-
Wat!! Je zou millis kunnen casten of AND'en dan red je het wel met 2 bytes
-
Leuk die Duff's device ;D
millis() komt inderdaad nog met wat overhead om het atomic te houden. En inderdaad, je kunt gewoon een cast doen als je af kunt met minder bytes ;D Al met al vind ik de kleine performanceoverhead het meer dan waard om gebruikersgemak (= code schrijven performance ;D) er voor terug te krijgen.
En let erop, de 8-bit Arduino's hebben geen DIV of MUL instructie. Vandaar dat ze normaal kostbaar zijn als het geen macht van 2 is. Vandaar mijn opmerking over de if(!(_1ms % 10). Maar goed, die kun je vervangen door if(_1ms == 10).
Timo
-
Duff's device, daar had ik inderdaad nog nooit van gehoord. Uit 1983, toen zat ik nog diep in mainframes (BAL,Cobol etc). Maar het is ook interessant wat er over de performance gezegd wordt. Destijds, in 1983, was de C compiler nog vrij simpel, alleen de K&R variant, later met GNU C en uitgekookte optimalisatie, werd dat anders. Bijvoorbeeld het gebruik van register voor variabelen. Uit de tijd dat ik met GNU C en performance bezig was, bleek uit de testen dat het gebruik van register niet nodig was en meestal contraproductief werkte, omdat je daarmee de mogelijkheden van de optimalisator beperkte.
Groet Meino
-
Nu we toch bezig zijn, hebben jullie dit wel eens gelezen: http://yosefk.com/c++fqa/defective.html
Groet Meino
-
(https://i.redd.it/h3ziqig1uakz.jpg)
;D
-
Mede hobbyist,
...
Ik heb voor zowel beginnende als gevorderde programmeurs een korte driedelige cursus geschreven in Nederlands (In Jip en Janneke taal) over het programmeren van een Arduino. De hoofddoelen van deze cursus zijn om jou te helpen in het voorkomen van fouten, je te helpen met het opzetten met ingewikkelde processen en om je te helpen om je code zowel netjes, simpel als leesbaar te houden.
...
Hallo heren,
Was dit draadje niet ooit begonnen voor de beginnende en de gevorderde programmeur ? Ik denk dat de beginnende inmiddels wel is afgehaakt ! ;D
Jammer voor Bas die zich zoveel moeite heeft getroost. (Al ben ik het met zijn zienswijze lang niet altijd eens).
Groet,
Paul
-
Deel 3 komt nog, dat is pas de bom (y)
-
Ik ben bijna klaar met deel 3 maar aanvullend op deel 2 heb ik een functionerende AHOB geprogrammeerd voor gebruik met (nu nog) 2 sporen. Het werkt natuurlijk ook met 1 spoor en je kan er ook zelf een AKI van maken, dat zou niet moeilijk moeten zijn.
https://github.com/bask185/ahob
Ik heb hem alleen getest met de seriele monitor en led pin 13 en met een draadje heb ik inputs getriggerd. Alles lijkt goed gaan, er is geen onvoorspelbaar gedrag.
Het programma reageerde in grote lijnen precies zoals verwacht. Er zat geen fout in de flow van de drie state-machines.
Ik had natuurlijk een paar kleine foutjes. De servo's stuurde ik verkeerd om aan (1 en 2 omgewisseld), ze bleven atlijd open. Ik was ergens een digitalRead vergeten dus ik tikte if(input == false) ipv if(digitalRead(input) == false; Ik kon met de teksten op de seriele montitor echter in no-time deze bugs opsporen. Maar er waren verder geen grote dealbreakers.
Het coderen heeft me denk ik net een uur gekost.
Treinen kunnen beide kanten op beide sporen rijden. Volgorde doet er niet toe. Het gaat ook goed als de bomen al openen en er komt een nieuwe trein binnen, dan gaan de bomen weer dicht vanaf het punt waar ze gebleven waren.
Ik zou zeggen: test het uit, bekijk de source code en met name de state machines (railCrossing.cpp, readTrack1.cpp en readTrack2.cpp) (en bouw een werkende AHOB in je modelbaan :P).
Overzicht van de IO:
2 detector1 INPUT_PULLUP
3 detector2 INPUT_PULLUP
4 detector3 INPUT_PULLUP
5 detector4 INPUT_PULLUP
6 servoPin1 OUTPUT
7 servoPin2 OUTPUT
10 led1 OUTPUT
12 blinkLed1 OUTPUT
13 blinkLed2 OUTPUT
Als iemand vragen heeft, hoor ik het graag.
Mvg,
Bas
-
Is er een filmpje van?
a) Bij gewoon dubbelspoor kun je met 4 detectors volstaan.
b) Maar bij dubbel enkelspoor heb je minimaal 6 detectors nodig.
Heb jij het systeem voor a) gemaakt?
-
Mijn implementatie: Elk spoor heeft 2 detectors. Een trein kan van beide kanten aankomen. Het maakt niet uit welke van de detector als eerst wordt getriggerd. De andere detector wordt dan gebruikt om te te bepalen of de trein er voorbij is. De trein moet eerst naar deze detector toe rijden, vanaf dat punt moet de detector minimaal 10 seconde vrij zijn geweest om het blok weer vrij te geven. Deze tijd kan je natuurlijk aanpassen.
Dit heeft misschien het nadelige effect dat de bomen relatief laat open gaan. Die 10 seconde zit er meer tussen voor als de detector kleiner is dan de grootste as-afstanden. De tijd kan ook makkelijk naar 0 toe.
Wat je zou ook kunnen doen, en ik denk dat jij dit ook bedoelt, je kan op de overgang zelf een detector maken. Dan kan je de buitenste 2 detectors parallel aansluiten op 1 van de 2 arduino ingangen en dan doe je de middelste aansluiten op de andere ingang. Dat zou ook moeten werken en het maakt niet hoe je ze op de ingangen aansluit. Maar bijwerking: als de middelste sensor dus 10 seconde verbroken is, en de trein is nog net aan in contact met een van de buitenste sensors dan zouden de bomen weer dicht gaan. Je kan die 10 seconde ophogen tot max 255 om er zeker van te zijn dat je trein er voorbij is
De 2 sporen hebben geen afhankelijkheden van elkaar. Zolang 1 van de sporen zegt, 'ik ben nu bezet' dan sluit de overgang. Als beide sporen zeggen: 'ik ben niet meer bezet' dan gaan de bomen weer open. De overgang zelf en de bezetmeldingen zijn 3 parallele processen.
Als je (of iemand anders) nog een verzoeknummer heb, kunnen we altijd wat regelen. Ik kan de software sws ook geschikt maken voor een AKI.
Overigens de sluit/open tijd van de bomen instelbaar in config.h. De open en sluit posities van de servo's zijn ook daar instelbaar. De servo's delen alleen nog wel dezelfde posities op het moment. Als servo 1 van 10 naar 100 graden draait dan doet servo 2 dat ook.
Mvg,
Bas
PS.
Ik zelf nog geen overgang gebouwd. De software stuurt serieel feedback over alles wat het doet. Zo kon ik bevestigen dat het goed werkt desondanks ik nog geen servo daadwerkelijk heb aangestuurd. Ik kan eventueel een filmpje maken van de seriele monitor, maar je kan ook zelf het programma in een arduino stoppen en de detectors nabootsen met een draadje.
-
Een overwegschakeling voor dubbel enkelspoor behoort er uit te zien zoals in de bijlage staat. De uitgangen 300 en 302 stellen de overweg in werking. De geheugenschakelingen 301 en 303 "onthouden" dat de trein op de overweg (contacten 01 en 04) is geweest. Uitgang 10 is het overwegsignaal dat de lampen, bellen en slagbomen aanstuurt.
(https://images.beneluxspoor.net/bnls/Overweg-JLD.png) (https://images.beneluxspoor.net/bnls/Overweg-JLD.png)
-
Wow krijg ik me daar even een flashback naar de TI PM550 met program terminal ... Bedankt Martin ;D
-
Dit is zo verwarrend ??? Van alle talen in de wereld (NL, Chinees, C, assembly, arabisch) krijg ik net de enige taal voor me die ik niet kan behappen, Logic Ladder Diagram. Chinees kan ik tenminste nog in Google translate gooien ;D
Ik heb misschien elektrotechniek gestudeerd maar van logic ladder diagrammen snap ik echt niks. Ik vind het echt heel knap dat mensen er ook maar iets mee kunnen maken.
Ik kan opmaken dat je 6 detectors heb 00 t/m 05 en dat 01 en 04 de middelste zijn? Maar hoe het nu precies werkt, is me echt een mysterie? Betekent |/| hier 'niet'
Ik kan ook niet helemaal opmaken of je nu wel of niet hebt begrepen wat ik bedoelde ??? Ik dacht dat ik het vrij duidelijk uitlegde ???
Mvg,
Bas
EDIT:
(https://i.imgur.com/Elmgf9U.jpg)
Ik heb de state-diagrams toegevoegd waarmee ik de code grotendeels gegenereerd heb. Werkt zoals in de beschrijving van mn vorige post. als in wacht positie eerst sw1 gemaakt is, dan wordt sw2 in de gaten gehouden. Als sw2 gemaakt is, wordt er gewacht totdat deze niet meer gemaakt is. De trein is er dan voorbij. Sw3 en Sw4 werken hetzelfde. Beide blokken vertellen de overweg met 2 globale variabelen of er een trein is of niet.
-
Betekent |/| hier 'niet'
Ja: een verbreekcontact.
Komt een waarheidstabel je bekend voor?
Nu ik er even over nadenk, besef ik dat dit schema voor volledige detectie geldt -> zoals het Märklin-systeem.
-
Op zich zijn ladder diagrammen niet zo lastig. Je moet het vooral vergelijken met een schema met echte schakelaars en gloeilampen/relais (tri-state/float/zweven bestaat niet, ofwel iets niet aansturen betekend uit). Echt 1 op 1 de relais techniek die het verving. Links heb je de voedingsrail en rechts GND (of andere voedingsrail). Vervolgens ga je er van boven naar beneden per circuitje doorheen.
-| |- is een NO knop (of relais) contact
-|/|- is een NC knop (of relais) contact
-( )- is de lamp/relais
In de basis dus erg simpel. Alleen als het complex wordt dan wordt het snel minder overzichtelijk.
@Martin Hornis Het lijkt me alleen een beetje complex voor wat het doet... Waarom niet direct 300 en 302 als geheugen gebruiken? Maar komt misschien vooral dat ik even mis wat de andere 2 ingangen (per helft) doen.
Timo
-
Ja die ken ik van digitale techniek. OR en AND poorten, pulsentellers, flip-flops dat vond ik wel leuk om te doen. Ik heb ooit een digitale wekker er mee ontworpen, kreeg er een 9.6 voor met natuurkunde (y)
Ik snap het hele punt niet meer van die LLD behalve om mij te laten zien hoe volgens jou de ahob zou moeten werken. Het voelt voor mij ook een beetje als mosterd na de maaltijd. Ik ben er al klaar mee, ik heb in details uitgelegd hoe mijn implementatie werkt omdat je het schijnbaar niet helemaal snapt, dat kan, niks mis mee. En vervolgens krijg ik een LLD voor m'n neus van een of ander programma dat waarschijnlijk hetzelfde doet als de mijne??? Je geeft ook niet echt concreet antwoord op de vraag of je m'n implementatie nu wel of niet snapt? Ik vermoed van wel, maar we lopen hier dus helemaal langs elkaar heen.
Ik heb slechts een Arduino programma gepost die een ahob met servomotors en met ledjes kan aansturen en ik heb uitgelegd hoe die werkt. Mijn voornaamste reden is om mijn programmastructuur en werkwijze te demonstreren. De 2e reden is om andere mensen simpelweg een werkend ahob programma kado te geven. Dat zijn mijn bedoelingen.
Mvg,
Bas
-
Bas, geen kritiek maar gewoon een vraag.
Waarom ben je uitgegaan van maar 2 detectors per spoor in plaats van 3, zoals in het grootbedrijf?
Aan beide zijden een aanrijdsectie/detector (AD1 en AD2) en een middensectie/detector (MD).
En die dan als volgt afhandelen.
- Alles laag en actief: ruststand
- AD1 hoog: overweg gaat sluiten en AD2 wordt inactief gemaakt, maar nog wel ingelezen.
- MD hoog: onthouden maar geen verdere actie
- AD1 en MD beiden laag: overweg mag weer open
- MD en AD2 beiden laag: AD2 weer activeren
- Alles laag en actief: ruststand weer bereikt
En dat natuurlijk ook met AD1 en AD2 qua volgorde omgekeerd voor een trein in de andere richting.
-
Zie mijn aanvulling: Nu ik er even over nadenk, besef ik dat dit schema voor volledige detectie geldt -> zoals het Märklin-systeem.
-
- AD1 hoog: overweg gaat sluiten en AD2 wordt inactief gemaakt, maar nog wel ingelezen.
Gevaarlijk -> als er van de andere kant ook een trein komt?... De klap op de overweg is groot. ;D
-
@Eric B
Nou Eric, heel simpel.
A, ik had niet echt een idee hoe het groot bedrijf functioneert.
B. Deze constructie leek mij te volstaan
C. 4 contacten is minder dremel en soldeer werk dan 6
En zoals ik al zei, het is mogelijk om de buitenste detectors parallel aan te sluiten op 1 input en de middelste detector kan op de andere input. Dus ik was mezelf een stapje voor hehe ;D
Maar deze state-machines zijn uitermate flexibel, ik wil best een nieuwe state-diagram maken en het net zo doen als het grootbedrijf. Kleine moeite immers ;)
Mvg,
Bas
-
Gevaarlijk -> als er van de andere kant ook een trein komt?... De klap op de overweg is groot. ;D
Dan is er is structureel mis met je beveiliging/blokstelsel, dat los je niet op met de aansturing van je overweg ;D
Bas, bij enkelspoor heb je aan beide zijden van de overweg aanrijdsecties.
Bij dubbel enkelspoor dus 2 x het zelfde naast elkaar.
In het verleden waren er ook dubbelsporige trajecten die alleen ingericht waren voor Verkeerd Spoor rijden, de overwegen werden bij VS rijden niet automatisch gesloten, omdat de aanrijdsectie in die richting niet aanwezig was.
De machinist reed dus op zicht en moest met de 1e as van de trein de middensectie berijden om de overweg alsnog te sluiten.
-
Ik zelf nog geen overgang gebouwd. De software stuurt serieel feedback over alles wat het doet. Zo kon ik bevestigen dat het goed werkt desondanks ik nog geen servo daadwerkelijk heb aangestuurd. Ik kan eventueel een filmpje maken van de seriele monitor, maar je kan ook zelf het programma in een arduino stoppen en de detectors nabootsen met een draadje.
[/quote]
Hoi Bas ik heb het een en ander geprobeerd maar ik krijg de servo's niet aan het werken , terwijl de serieel monitor wel alles aangeeft evenals de leds en sensors
doen serieel hun werk het knippert en stopt knipperen op het juiste moment , alleen de servo's reageren niet , getest met een servo tester werken ze wel ;-)
Evenzo heb ik de grnd vd servo's nagekeken de is ook aangesloten op de grnd vd arduino.
Hoop dat je voor mij een oplossing hebt (y)
-
Ik zal vanavond ff kijken met een oscilloscoop of de Servo signalen goed zijn.
In het aller ergste geval is er een conflict tussen de hardware timers. Dit is in ieder geval oplosbaar. Dit heb je wel eens met Arduino libraries.
EDIT:
ben op werk, en heb het al gevonden. Ik ben de servo attachments vergeten. Echte rookie mistake hier ;D. De wijziging staat al op internet, maar je kan ook de regels zelf toevoegen. In railCrossing.cpp staat op regel 39 deze functie:
// FUNCTIONS
extern void railCrossingInit(void) {
state = beginState;
arm1.attach(servoPin1); // <--deze toevoegen
arm2.attach(servoPin2); // <-- deze toevoegen
arm1.write(openPos);
arm2.write(openPos);
}
-
Als je de .attach() en .write() even omdraait scheelt dat een power spike ;)
Ennuh, arrays ;D
Timo
-
Hoi Timo,
Probeer als iemand die alleen maar poke en peek geleerd heeft dit te begrijpen
Wat bedoel je met een power spike?
Groetjes
Arthur
-
Hij bedoelt een piekje in de servo motor aansturing.
wat gebeurt er nu?
Op het moment dat ik de servo attach aan een pin, ga ik direct servo signalen op die pin zetten. Ik heb op dat punt nog geen waarde (hoek) opgegeven met servo.write()
Als de servo dan fysiek op 90 graden staat. En ik attach hem zonder hem eerst naar 90 graden te sturen met servo.write. Dan probeert de arduino de servo waarschijnlijk naar 0 graden toe te sturen. Als ik dan met servo.write() een waarde opgeef van 90 dan draait hij weer terug naar 90. Hierbij worden grote stromen gebruikte voor de aanloopstromen van de motoren. Echter omdat de instructies direct onder elkaar staan, duurt het sturen naar positie 0 slechts enkele microsecondes. En daarom spreekt Timo van een Power Spike. Een kortbondig momentje waarop de servo's heel veel stroom trekken.
Als ik nu de write boven de attachment zet, dan stuur ik de servo eerst naar 90 graden voordat ik de signalen op de pin zet.
@Timo ik vind een array voor 2 servo's een beetje overkill. Er door heen loop'en kost meer performance en je bespaart er ook niet significant veel geheugen mee. Of zou je iets anders in een array willen stoppen?
-
De kans dat het inderdaad een spike geeft is wel klein, toegegeven. Maar attach() zonder signal uit bestaat niet, ook niet zonder .write(). Er zal dan de default van 90 gebruikt worden. Dient dus meer als "best practice" voor als je er in de toekomst wel wat tussen zet. Bijvoorbeeld omdat je een vertraging tussen de .attach()'s gaat zetten om de power spike (vermogenspiek) van meerdere servo's koppelen te drukken.
Ik vind het geen overkill ;D Jij probeert steeds de compiler te slim af te zijn en kleine zaken te optimaliseren voor runtime. Ik zou zeggen, laat dat aan de compiler over. 8) Vertrouw je die niet hebben we nog assembler ;D De compiler kan best nog wel eens zien dat je simpelweg over twee items loopt en dat al optimaliseren als losse calls. En met array's is dan loopen over de array wel een logische stap, verplicht is het natuurlijk niet. Maar ben wel van mening dat als je dan toch dingen nummert, je dit beter kunt doen op een manier doet dat de compiler er ook van op de hoogte is :) Bijkomend voordeel is weer consistentie, immers doe je het dan altijd hetzelfde. Of je dan gaat loopen of ze gewoon individueel aanroept. Maar met arrays en loopen is het wel opeens kinderspel om de overweg uit te breiden met extra slagbomen :angel:
Timo
-
Je kan ook 4 motors op een IO pin aansluiten, dan heb je ook 4 bomen (y)
Je kan sws nog meer werk verrichten aan verbeteringen voor dit programma... als je dat wilt. Als ik dat stuk van Eric B lees, kan je bijvoorbeeld die state-machines voor de bezetmelding de deur uit trappen en vervangen door een paar simpele if-statements. Je kan ook denken aan idd 4 servo IO met elk hun unieke open en sluit posities. Je kan nu net zo makkelijk een servo signaal vertakken naar 4 servo motors. Je kan het geheel misschien via de terminal configureerbaar maken, on the fly een servo positie of een tijd aanpassen en dat in de EEPROM stoppen. Ik heb nu een simpele config.h toegevoegd, maar bij elke wijziging die je maakt, moet je opnieuw programma compileren en uploaden.
Voor de huidige toepassing volstaat het programma. En mensen kunnen waarschijnlijk zelf meer servo's toevoegen als ze dat willen. Er gaan er 4 op een timer dacht ik. Bovendien is het leuk voor mensen om zelf te knutselen aan een programma, het leren moet ergens beginnen. :police:
En ik ben niet echt bezig met compiler optimalisatie. Ik had simpelweg niet bedacht dat er misschien meer bomen bij zouden komen ;D. Daarom vond ik een array van 2 items niet echt interessant om te doen. Bijna net zo veel tik werk.
Bas
-
ben op werk, en heb het al gevonden. Ik ben de servo attachments vergeten. Echte rookie mistake hier ;D. De wijziging staat al op internet, maar je kan ook de regels zelf toevoegen. In railCrossing.cpp staat op regel 39 deze functie:
// FUNCTIONS
extern void railCrossingInit(void) {
state = beginState;
arm1.write(openPos);
arm2.write(openPos);
arm1.attach(servoPin1); // <--deze toevoegen
arm2.attach(servoPin2); // <-- deze toevoegen
}
Top Bas dank je (y)
-
A, ik had niet echt een idee hoe het groot bedrijf functioneert.
Even terugkomend op de "Engelse ziekte". Die laat zich door het Coronavirus niet verdringen. Hier een prachtig voorbeeld hoe het in het Nederlands echt wel uitmaakt om het aan elkaar te schrijven, omdat het een andere betekenis krijgt. ;D ;)
-
Ik ben afgelopen weken kapot aan het gaan op kooihoorts. De medicatie helpt niet echt goed met mijn ogen. Ik heb er thuis al helemaal veel last van. Als ik mn filmpje af heb, kan ik het laatste deel releasen.
In ieder geval wilde ik wat zinnigs mededelen. Ik had namelijk een productieve pauze deze week. En ik heb een Weistra module (https://github.com/bask185/State-Machine-Scripts/tree/master/modules) gemaakt. Dus voor de analoog rijdende mensen die hun baan willen automatiseren:
Syntax is eenvoudig gehouden conform de Arduino Library Guidelines.
#include "weistra.h"
#define potPin A0
Weistra regelaar(13); // maak het object en gebruik pin 13
void setup()
{
regelaar.begin(); // initialiseert de regelaar
}
void loop() {
regelaar.update(); // moet elke cyclus worden aangeroepen omdat we gebruik maken van SW timing.
byte currentTime = millis() & 0xff;
static byte previousTime = 0;
if(currentTime - previousTime >= 200) { // 5 updates per seconde
previousTime = currentTime;
byte throttle = map( analogRead(potPin), 0, 1023, 0, 100); // neem ADC sample en schaal om naar 0-100
regelaar.setSpeed( throttle ); // zet de snelheid
}
}
Het mooie is dat je hiermee elke pin kan gebruiken en je kan meerdere regelaars door elkaar heen gebruiken. Het zou ook op alle Arduino boards moeten werken.
Ik heb de SW alleen getest met de onboard led en de seriele monitor, maar de resultaten vallen binnen de verwachtingen (deze keer :P )
Ik wil in de toekomst nog een soort veiligheids/overloop feature toevoegen dat je de regelaars met elkaar kan synchroniseren. Dan kan je een trein van het ene blok naar het andere blok laten rijden zonder dat je een (te lange) kortsluiting maakt. En als er wensen zijn voor de Permaloog regeling van meneer Zondervan, let me know.
Veel rijplezier!
Bas
-
Hallo Bas,
Ik heb je "Weistruino" regelaar uitgeprobeerd en hij doet het fantastisch... Een analoge lok die normaal slecht op gang komt, veel last van kleef, rijdt met deze regelaar mooi langzaam weg (y)
In jouw sketch moest ik alleen deze aanpassing doen, anders komt ie bij mij maar één keer bij de setSpeed in de if. Ik heb een Uno gebruikt.
//byte currentTime = millis() & 0xff;
//static byte previousTime = 0;
unsigned int currentTime = millis() & 0xff;
static unsigned int previousTime = 0;
Ik heb geen H-brug gebruikt, maar een enkele Mosfet achter een optocoupler.
Met een H-brug van Alie had ik al eens eerder gemerkt dat er sluiting ontstaat als er vanaf een permanent gevoede sectie naar de H-brug-sectie wordt overgestoken, waarbij opgemerkt dat de voeding van de H-brug dezelfde was als die van de permanent gevoede sectie.
-
Blij dat die het doet. Ik heb even gekeken waarom het niet goed werkte.
if(currentTime - previousTime >= 200) { // 5 updates per seconde
previousTime = currentTime;
Na de eerste maal in if-statement krijgt previousTime de waarde 200. Vanaf dat punt moet currentTime gelijk of hoger dan 400 kunnen worden. En zijnde het een byte, kon dit niet.
Het is in dit geval alleen nodig om een currentTime te veranderen in een unsigned int. De previous mag wel een byte zijn.
Bas
-
Neem nou meteen een unsigned long, anders loop je later weer stuk...
-
Ik moet na wat verder testen wel iets terugkomen op de regeleigenschappen.
Bij een belabberde loc ging het redelijk, maar een normaal goedlopende loc schokt enorm in het lagere regelbereik (tot ca 30/100) Maar wellicht ligt dat aan mijn simpele Mosfet schakelingetje...
In ieder geval leuk om verder mee te knutselen.
-
Neem nou meteen een unsigned long, anders loop je later weer stuk...
Ik gebruik voor mezelf al geen millis meer. Ik gebruik 8 bit counters die in een ISR naar 0 tellen. In mijn code zie je vaak:
if( !someTimer ) {
someTimer = 5; // afhankelijk van de gekozen tijdbasis kan dit 5ms, 5cs, 5ds of 5s zijn
Minder tikwerk en minder geheugen gebruik. Het is ook erg dynamisch en werkt goed mijn state-machine structuur. Het werkt alleen absoluut niet goed als je het in een class wilt bouwen.
@Hennik
Ik heb deze Weistra regelaar 1x gebruikt thuis, had idd goede rij-eigenschappen, maar de knipperende lichtjes op 20Hz... ik had geen zin om de loc aan te passen dus ik ging op 31kHz rijden, belabberd gedrag op de hoge snelheden, maar het ding rijdt.
Het kan misschien liggen aan eventuele onstoringscondensators of smoorspoelen. Ik heb het niet veel ervaring met dit soort problemen. Maar je kan je locs openschroeven om te kijken naar de verschillen.
Bas
-
Ik ben nog weer aan het stoeien geweest met de "Weistruino" regelaar.
Inmiddels ontdekt dat het schokkende gedrag veroorzaakt werd door een belabberde voeding. Ik had de gelijkspanningsuitgang van een simpele modelspoortrafo gebruikt, en die is alles behalve vlak, schoot me te binnen. Een elco loste dat direct op.
Nu probeer ik meerdere regelaars te definiëren in dezelfde sketch. Ik denk dan aan een array.
Weistra regelaar(13); // maak het object en gebruik pin 13
Weistra is het type object en regelaar is de naam. Kan deze als array gedefinieerd worden (zoals de servo library) t.b.v. laten we zeggen 3 regelaars?
Wat ik geprobeerd heb is:
const byte regelaarPin[3] = {2,3,4};
Weistra regelaar[0](regelaarPin[0]);
Dat accepteert de compiler nog... maar zo gauw ik Weistra regelaar[1](regelaarPin[1]); toevoeg, dan volgt de foutmelding "conflicting declaration 'Weistra regelaar [1]'"
Of moet hiervoor iets in de Weistra library aangepast worden?
-
Je werkt met een array, die moet je anders initialiseren
const byte regelaarPin[3] = {2,3,4};
Weistra regelaar[3] = {Weistra(regelaarPin[0]), Weistra(regelaarPin[1]), Weistra(regelaarPin[2])};
Groet Meino
-
Bedankt Meino, dat had ik echt nooit zelf kunnen verzinnen.
Weer een stapje verder dus, maar nog niet helemaal.
Geen compilatiefouten meer, maar nog wel een probleem om void setup()
{
regelaar.begin(); // initialiseert de regelaar
}
om te bouwen naar een array.
Wat werkt is:const byte regelaarPin[3] = {2,3,4};
Weistra regelaar[3] = {Weistra(regelaarPin[0]), Weistra(regelaarPin[1]), Weistra(regelaarPin[2])};
void setup()
{
regelaar[0].begin(); // initialiseert de 1e regelaar
}
Maar als ik doe:
void setup()
{
regelaar[0].begin(); // initialiseert de 1e regelaar
regelaar[1].begin(); // initialiseert de 2e regelaar
}ofvoid setup()
{
for(byte i=0; i<numRegelaars; i++)
{
regelaar[i].begin(); // initialiseert alle regelaars
}
}
Dan zie ik in de serialmonitor de waarde van throttle nog netjes variëren met de stand van de potmeter, maar de outputpinnen blijven laag.
Hoe de Weistra begin() method te gebruiken?
-
Ik zit op werk en kan niet bijzonder veel doen. Ik heb natuurlijk wel permanent een arduino aan mijn PC hangen. In de pauze zal ik ook proberen om met een array 3 objecten te maken. Ik heb echter alleen led pin 13 als visuele hulpmiddel om te zien of 1 van de regelaren het daadwerkelijk doet of niet.
Ik heb overigens een vermoeden van iets wat ik fout gedaan zou kunnen hebben. Ik had vorige maand namelijk iets nieuws geleerd wat ik nog niet eerder wist, dus ik zal de code ook even nalopen.
Mvg,
Bas
-
Ja ik zie het al, ik heb een fout gemaakt in de update functie:
void Weistra::update() {
static byte counter = 0;
static uint32_t prevTime = 0;
if( portx_p != 0 ) {
uint32_t currentTime = micros()/* & 0x0000FFFF*/; // we only use the last 2 bytes of micros()
if( currentTime - prevTime >= intervalTime ) { // interval
prevTime = currentTime;
if( counter == 0 && dutyCycle > 0) { // if counter reaches 100, reset it to 0 and enable the track power pin
*portx_p |= trackPin;
}
if( counter == dutyCycle && dutyCycle < 100) {
*portx_p &= ~trackPin;
}
counter++;
if(counter > 100) counter = 0;
}
}
}
Omdat deze functie een deel is van een class (ofwel we noemen het nu een 'method') mag ik geen static variabele gebruiken. Deze static variabele zijn lokale variabele, static zorgt er voor dat deze variabele hun waarde blijven behouden buiten de functie om. Normaal is dat rete handig om te gebruiken, maar niet je als je met met classes en meer dan 1 object ga werken.
Doordat we 3 objecten hebben gemaakt met dezelfde class, delen deze 3 objecten exact dezelfde variabele (prevTime en counter). Dit zou misschien ooit handig kunnen zijn als je wilt dat verschillende objecten met elkaar kunnen communiceren maar nu is het resultaat catastrofaal.
De fix
In weistra.cpp zet deze lijnen in commentaar of verwijder ze helemaal.
// static byte counter = 0;
// static uint32_t prevTime = 0;
In weista.h moet je achter het 'private' labeltje het volgende toevoegen:
private:
unsigned int intervalTime;
unsigned char dutyCycle;
unsigned char trackPin;
uint32_t prevTime; // <-- voeg toe (uint32_t is het zelfde als unsigned long)
uint8_t counter; // <-- voeg toe (uint8_t is hetzelfde als byte)
Feitelijk geef je elke object nu hun eigen variabelen die nodig zijn voor de werking.
Ik kwam hier vorige maand achter toen ik er achter kwam dat mijn debounceClass niet goed werkte als ik 2 of meer inputs wilde 'deboucen'. Ik merkte dat er een soort overspraak was tussen de verschillende inputs die niet mogelijk zou moeten zijn.
Mijn excuses voor het ongemak en veel treinplezier verder.
Mvg,
Bas
-
Omdat deze functie een deel is van een class (ofwel we noemen het nu een 'method') mag ik geen static variabele gebruiken. Deze static variabele zijn lokale variabele, static zorgt er voor dat deze variabele hun waarde blijven behouden buiten de functie om. Normaal is dat rete handig om te gebruiken, maar niet je als je met met classes en meer dan 1 object ga werken.
En dus in strijd met alle regels betreffende goed programmeren. Dat was iets dat ik bij een code review er uit liet halen, bedenk maar wat anders.
Groet Meino
-
En dus in strijd met alle regels betreffende goed programmeren in C++ ..
..bedenk maar wat anders.
Je hebt wel het gedeelte achter "De fix" gelezen?? Ik heb er alweer private variabele van gemaakt en gepusht op git
-
Dag Bas
De rest had ik zeker wel gelezen. Maar het ging mij meer over je opmerking "dat is rete handig...." omdat dat suggereert dat je dit soort constructies vaak gebruikt. Ik heb in mijn werkzame leven te veel door de bagger van anderen moeten spitten om zaken aan de praat te krijgen. Dus er zijn programmeer constructies die ik simpelweg fout vind en door hoort het gebruik van static variabelen zeker bij. Dat is misschien ook een reden dat ik een sterke affiniteit met "Object Oriented..." heb.
Groet Meino
-
Het werkt nu, ook met meerdere regelaars op één arduino. Bedankt Bas!
-
@hennik
(y)
@Meino,
Dat hangt af van de toepassing of static handig is of niet, soms moet je wel. Class -> nee. ISR -> ja
Als ik bijvoorbeeld in de void loop 10 functies heb lopen die allemaal getimed worden met millis() worden dan vind ik het zelf logischer om elke functie een static 'prevTime' te geven. Aangezien elke 'prevTime' alleen in 1 functie wordt gebruikt, vind ik het zelf beter om de scoop dan te beperken tot die functie. Alle 10 de functies kunnen dan allemaal dezelfde naam 'prevTime' blijven gebruiken zonder conflicten. En bedenk, het alternatief zou 10 verschillend genaamde globale variabelen zijn? Je kan misschien iets leuks met namespace of structs doen of een andere C++ feature met ingewikkelde syntax gebruiken die ik nog niet ken?
void foobar() {
static uint32_t prevTime = 0 ;
uint32_t currentTime = millis() ;
if( currentTime > ( prevTime + interval ) ) {
prevTime = currentTime ;
// code 2 run
}
}
muv de interval constante, kan je de code zo kopieren voor andere functies. En ik ben van mening dat meeste beginnelingen snappen wat hier gebeurt, zelfs als ze static niet kennen, komt de context wel over. Ik denk dat ik hier trouwens ook nog een schitterend setje macro's voor zou kunnen maken ::) Maar nu wil ik je niet boos maken natuurlijk :P
Er is trouwens een leuke library genaamd 'fireTimer' die denk ik meer jouw voorkeur heeft, daar die OOP is. Ik hem nog niet zelf gebruikt, maar de syntax bevalt mij wel.
En je hoeft helemaal weinig te tikken:
FireTimer msTimer;
void setup()
{
msTimer.begin(1000); // every 100ms
}
void loop() {
if( msTimer.fire() ) {
// code 2 run
}
}
Doet onderhuids precies hetzelfde :police:
Mvg,
Bas
-
Bas
ik heb geen problemen met macro's, dat is iemand anders op het forum.
Groet Meino
-
Ik dacht alle C++'ers last hadden van die 'bug' ;D
-
En toen bleef het stil ???
-
I'm sorry, je hebt gelijk :-[.
Heb je wel eens dat je teveel projecten op je hals heb gehaald? :(
Ik ben ondertussen 2 treinbanen voor mezelf aan het bouwen, ik bouw een treinbaan voor een gehandicapte meneer elke andere zondag, ik ga er nog een bouwen voor een terminaal iemand voor stichting droomdag, ik ben een modulair sein/blok module aan het ontwikkelen en daarvoor moet ik nog het e.e.a. leren voor een programma, mijn DCC centrale is nog niet af (wel bijna!) ik werk 40u, ik fiets bijna elke dag 25km van en naar werk en dan heb je thuis nog het huishouden, date-avond met je vrouw, de 'verplichte' familie bezoekjes, treinclubavond elke donderdag... En buiten dat allemaal om heb ik ook niet altijd even veel energie over om iets ingewikkelds aan te pakken (ik heb 's middags vaan tegenwind). Ik besteed de helft van mijn te korte pauzes aan hobby gerelateerde zaken
Nogmaals mijn excuses, ik ben het niet vergeten en het komt wel, ik weet alleen niet wanneer. Ik heb nu wel geluk bij een ongeluk, door corona gaan de clubavonden niet meer door, de 2 eerder genoemde treinbanen zijn tijdelijk 'opgeschort' dus ik heb weer een paar uurtjes tijd over.
Bas
-
Oke Bas,geen probleem , hoewel de discussies boven mijn pet gaan gebruik ik dit item voor eventueel probleemoplosser in toekomstige arduino avonturen.
Was al bang dat het doodgebloed was. ;)
-
Even terugkomend op de Arduino Weistra regelaar.
Ik ervaarde dat de loc soms wel eens een korte boost kreeg als de regelaarknop in de lage bereiken rustig verder teruggedraaid werd.
Na wat experimenteren lijkt dat met onderstaande wijziging opgelost (maar vraag me niet waarom)
in bestand Weistra.ccp regel 30, verander
if( counter == dutyCycle && dutyCycle < 100) {in
if( counter >= dutyCycle && dutyCycle < 100) {
-
Ik ben blij dat je hem opgelost had. Ik had deze regelaar ook sinds vorige maand in gebruik genomen op Rosedale Abbey en daar ervaarde ik hetzelfde. Dat zijn altijd de lastige bugs, die af en toe en willekeurig de kop op steken.
Ik zal jouw wijziging doorvoeren. Ik had zelf ook een kleine aanpassing. Ik ervaarde het probleem dat mijn 2-assige peckett slipte op een helling op lage snelheden. Je zag hem echt continu kleine sprongetjes maken. Om dat op te lossen heb ik de onder frequentie verhoogt naar 50Hz.
Ik heb deze regel aangepast
else { frequency = map(dutyCycle, 10, 100, Fmin, Fmax); }
Die Fmin en Fmax zijn nu constantes die bovenin het bestand staan.
#define Fmax 100
#define Fmin 50
Dat lost ook het zichtbare ledflicker probleem op (y)
Mvg,
Bas
-
Bedankt Bas (y)
-
Deel 3 komt nog, dat is pas de bom (y)
Ha Bas,
Waar vind ik deel 3 ? Misschien heb ik iets gemist.
Groet,
Paul