Arduino

[Peter Korsten]

Op een breadboard de schakeling bouwen en kijken wat het programma doet, naar mijns inziens leer je daar meer van dan allerlei diagrammen te maken.

En als je echt lang bezig bent met ontwikkelen van programmatuur, leer je dat het het beste is om eerst een diagram te maken.

Programmeren is helemaal niet gemakkelijk. Je moet namelijk heel abstract en strak denken, bijna als een computer. Na een dag werken moet je daar maar zin in hebben (en dat heb ik dus niet).

Je moet eigenlijk de volgende stappen ondernemen:

• Duidelijk weten wat je wil
• Duidelijk omschrijven wat je wil
• Het bovenstaande als een wiskundig model en/of algoritme opzetten
• Het geheel implementeren
• Het geheel testen
• Waar nodig, wijzigingen aanbrengen en opnieuw testen

Uiteraard ben ik niet op die manier begonnen: ik heb rondgekeken wat anderen deden , heel veel zelf uitgezocht en ben door schade en schande wijs geworden.

Overigens is een nadeel van het afkijken van wat anderen doen, dat anderen vaak fouten maken. Als je je daar niet van bewust bent, omdat je ze simpelweg niet als fouten herkent, loop je dus de kans om die fouten uitentreuren te herhalen. Het vergt heel veel oefening en ervaring om een fout in een stuk broncode te herkennen. En zelfs dan kijk je er vaak overheen.

Moraal van het verhaal: experimenteren mag en is leuk, maar onthoud dat programmeren geen kunst maar een ambacht is. Zonder plan timmer je geen stevige kast in elkaar en zonder plan zet je ook geen deugdelijk programma in elkaar. Leer van anderen, van de fouten van anderen en van de fouten die je zelf zult maken.

- Peter

[gvandersel]

Mag ik me bij het bovenstaande aansluiten.

Groet,

Gerard van der Sel.

PS: Een statemachine laat je dingen in een vaste volgorde herhalen. Doe dat NIET op een modelbaan. Er is naar mijn mening niets zo vervelend als een voorspelbare trein.

[tuurtje]

Peter

Leer van anderen, van de fouten van anderen en van de fouten die je zelf zult maken.

Ik ben het helemaal met je eens. Vallen en opstaan.
En ik weet zeker dat ik de komende tijd ga vallen, maar ik zie dat als een uitdaging.

Twee jaar geleden ben ik ook gevallen en mijn heup gebroken, zo'n uitdaging wens ik niemand toe

Ik ga jullie op de hoogte houden van mijn struikelingen.

Groetjes

Arthur 

[smits66]

Hoi,

Met de twee posts boven aan de pagina, ben ik niet geheel eens, als je professioneel aan het programmeren ben, zal dat misschien de juiste volgorde zijn, maar we hebben het over de Arduino die we programmeren op hobby niveau.
De programma's die we schrijven zijn nu niet de moeilijkste programma's om te programmeren, via een input een output sturen meer is het eigenlijk niet.

 

Programmeren is helemaal niet gemakkelijk. Je moet namelijk heel abstract en strak denken, bijna als een computer

  T'is hoe je het bekijkt,  daar kan ik niets mee, ik weet niet eens wat abstract denken is, ik programmeer met mijn boerenverstand en daar komen goed werkende programma's uit , ze zijn niet de meest compacte maar het werk wel en ze zijn overzichtelijk.

Voor het programmeren van een Arduino en Visual Basic heeft het geen zin om uren flowchats , statemachine ,en andere diagrammen te maken, ik vind dat zonde van mijn hobby tijd en heb daar geen zin in.

Het is wel verstandig om een schematische overzicht te maken wat je wil sturen, dat kost niet zo veel tijd.

Voor de duidelijkheid ik heb ondertussen een werkende, nog wel beperkte modelbaan sturing met een Arduino geprogrammeerd en een visual basic programma om met de Arduino te communiceren en het werk goed, ik ben daar nog geen maand mee bezig geweest.

Met het Visual Basic programma kun je de wissels omzetten, handmatig een blok bezet melding geven, noodstop geven zodat alle treinen meteen stil staan, baanspanning aanzetten baan verlichting in en uitschakelen in meerde groepen, tekst meldingen ontvangen van de Arduino en commando's aan de Arduino geven.

Er moet nog een snelheid regeling(pwm), automatische blok bezet melding, seinsturing (blok sein) en wat ik er later  nog bij wil hebben, ingebouwd worden.

Het is ingewikkelder om een elektronische wissel omzetter te ontwerpen, dan een routine om de schakeling aan te sturen.

Ik val niemand aan, maar zo zie ik het, iedereen moet het doen zoals hij het het beste vind, daar ga me niet aan snijden, dat wil ik ook niet.

Ik zou zeggen veel plezier met het programmeren van de Arduino en het verder ontdekken van de mogelijkheden van een Arduino.

Hoe ik de Arduino analoge modelbaaan sturing aan het ontwerpen bouwen programmeren ben kun je lezen in mijn Topic. http://forum.beneluxspoor.net/index.php?topic=57884.new;topicseen#new

Mvg Paul

[Tom Z.]

Vind dit echt een aardig draadje worden. Dank allemaal voor de bijdragen ! Tom Z.

[Peter Korsten]

Paul, laten we het eens hebben over het bouwen van een vitrine, in plaats van een programma. Wat jij nou zegt is dat je geen professioneel timmerman bent en je daarom al die professionele instrumenten als verstekzagen en waterpassen niet nodig hebt. Je gebruikt gewoon je boerenverstand en daar komt een vitrine uit die misschien niet helemaal recht hangt, maar het verder wel goed doet.

Als je op zo'n manier een vitrine bouwt, kun je er donder op zeggen dat je treintjes in een zielig hoopje op de grond belanden.

Hetzelfde geldt voor programmeren. Omdat je geen professional bent, wil dat nog niet zeggen dat je daarom maar wat aan moet gaan klooien. (En ik moet er helaas aan toevoegen dat veel "professionele" programmeurs zomaar wat aanklooien. Er voor betaald krijgen is geen garantie voor kwaliteit.)

Ik vraag ook niet om een business case, risico-analyse, stakeholder interviews, UML diagrammen en unit testen. Maar als je het stappenplan dat ik beschreven heb volgt, dan ontwijk je al een boel valkuilen.

Op mijn 12e ben ik begonnen met aanklooien. Nu ben ik 44 en ik heb een hekel aan documenten en diagrammen maken, maar die 32 jaar hebben we wel geleerd wat wel en niet werkt. En aanklooien werkt niet.

Iedereen weet wel ongeveer wat hij wil. Maar om dat duidelijk en ondubbelzinnig op te schrijven, dat valt vaak vies tegen. Maar dat is wel de essentiële stap tussen idee en programma.

- Peter

[smits66]

Hoi, peter

Dit kan een leuke discussie worden
Even over de vitrine , ik heb een vitrine gebouwd zonder tekening en allerlei elektrische apparatuur te gebruiken, alleen met een duimstok, blokhaak ,hand zaag, en mijn boerenverstand  het is niet het mooiste maar wel stevig en kan tegen een stootje en hangt waterpas en al vijf jaar zonder problemen.
 
Ik kom er vanavond op terug.

Met vriendelijke groet Paul Smits.





Verstuurd vanaf mijn SMP53-210 met Tapatalk

[Tom Z.]

Zeg ik net dat dit een aardig draadje is geworden, gaat het ineens over vitrines 

Met vriendelijke groet, Tom Z.

[gvandersel]

Paul,

Wat Peter denk ik probeert te zeggen is dat als je een iets moeilijkere problemen gaat oplossen het aanklooien niet de beste oplossing gaat brengen (Als er al een oplossing komt). Voor je dedicated treinbesturing zul je het door het op te delen in kleinere problemen (hoe stuur ik een wissel, hoe stuur ik een locomotief, etc) het aan de gang krijgen, daar twijfel ik geen moment aan. Maar jij bent inmiddels voor dat project ook aan het documenteren (zie je diagrammen in je eigen draadje).
Je hebt keuzes gemaakt en dus vooraf dingen uitgedacht en beslissingen genomen. Dit is toch echt "gestructureerder" als aanklooien.

Groet,

Gerard van der Sel.

PS. Alle werkmethodes zijn afgeleid van JBF (Jan Boeren Fluitjes). Ze zijn gebasseerd op "best practices"

PSS: Blokhaak is in mijn ogen proffessioneel gereedschap.

[Peter Korsten]

Zeg ik net dat dit een aardig draadje is geworden, gaat het ineens over vitrines 

Als metafoor voor een programma, maar het blijkt dat ik betere metaforen moet verzinnen.

- Peter

[smits66]

Hoi

@Gerard

Ik weet wat peter probeert te zeggen, waar het mij om gaat is dat ik absoluut niet aan het aanklooien ben, dat word wel gesuggereerd, (althans zo kwam het wel over) door Peter.

Door mijn werk, ik werk in de bouw als elektromonteur, kom ik vaak situaties tegen die ik per direct moet oplossen, geen tijd om tekeningen er bij te halen, zijn vaak niet eens goed, maar het moet wel opgelost worden, dus blijft alleen mijn ervaring en boerenverstand over om het probleem op te lossen.

Op die manier ben ik ook met mijn hobby, programmeren en ontwikkelen bezig, ik kom een probleem tegen en los het op zonder documentatie of allerlei  andere schema's.

IK vind het dus persoonlijk niet van belang om allerlei documentatie te maken.

De flowchart in mijn eigen draadje gebruik ik zelf niet, ik heb het er bijgezet voor de mensen die het draadje lezen ,om uit te leggen hoe ik het wil maken en hoe het moet gaan werken.

@Peter

Hoi Peter

Ik val jou niet aan op je ideeën , ik zie het alleen anders.

Mocht je het idee hebben dat ik jou aanval mijn excuses daar voor.
 
Nee ik klooi niet aan, mijn programma is gestructureerd geprogrammeerd zowel de Arduino als Visual basic.
De meeste informatie zet ik achter de statements, zodat ik kan zien wat die statement doet in de sub routine.

Daardoor is het programma wel groter en lijkt het lomper (geld ook voor de vitrine kast ) maar dat vind ik niet erg (Arduino Mega heeft 128 kb geheugen ik zit nu op max 10 kb)

Mocht je de broncode willen zien hoor ik het wel, geld trouwens voor iedereen.

@Tom Z

We zullen het niet meer hebben over vitrinekasten, maar verder gaan met de Arduinio

Mvg Paul Smits 

[tuurtje]

Ik heb vandaag mijn Uno ontvangen.

We gaan maar eens structureel stoeien 

Zonder gekheid, ik hoop nog van jullie ervaringen te mogen genieten.

Groetjes

Arthur

[smits66]

Hoi Arthur

Succes met je Arduino, mocht je nog vragen hebben horen we het wel.

Kijk ook eens op mijn eigen Arduino topic.
http://forum.beneluxspoor.net/index.php/topic,57884.new.html#new


mvg  paul 

[Timo]

Door mijn werk, ik werk in de bouw als elektromonteur, kom ik vaak situaties tegen die ik per direct moet oplossen, geen tijd om tekeningen er bij te halen, zijn vaak niet eens goed, maar het moet wel opgelost worden, dus blijft alleen mijn ervaring en boerenverstand over om het probleem op te lossen.

En door zoiets had ik laatst dus geen spanning in me kamer  Doordat het "even" zonder documentatie was gedaan in het verleden zijn twee elektromonteurs bij elkaar 8 uur bezig geweest om een losse draad te vinden. Uiteraard is dit ook niet gedocumenteerd dus ja... Maar ik snap dat het voor iemand met ervaring in veel gevallen prima kan werken. Maar daar zit de crux, ervaring, jij doet het al even. Begin je ergens mee kunnen aantekeningen erg handig zijn. Vraag een niet klusser maar eens een vitrine/vogelhuisje in elkaar te timmeren zonder tekening, kan je lachen... 

En idd, ik droeg niet aan om hele abstract ingewikkelde dingen te doen die uren kosten. Maar om eens duidelijk te stellen wat je wilt doen voor je er aan begint. Een state diagram is een mogelijkheid ervoor en kan naar mijn mening een handig houvast zijn als je met iets nieuws als programmeren begint. Ik zeg niet dat het de enige goede weg is, alles wat voor jou werkt is goed. Maar ik zou het mezelf niet moeilijker maken dan nodig is door niets vooraf op papier te zetten op een manier die je nu al kent/begrijpt.

PS: Een statemachine laat je dingen in een vaste volgorde herhalen. Doe dat NIET op een modelbaan. Er is naar mijn mening niets zo vervelend als een voorspelbare trein.

Daar ben ik het niet met je eens Gerard. Je weet alleen alle mogelijke toestanden van iets. (Station spoor bezet, trein rijdt naar station enz) En op een modelbaan is dat precies het geval! En hoe je tussen deze states wisselt maakt de boel leuk. Moet er gewacht worden? Moet er op een knop gedrukt worden? Moet er misschien af en toe iets anders gebeuren? Is de stand van de maan van belang? Hiermee breng je de variatie  En niets houdt je tegen om een random tijd te pakken (wacht ergens tussen de 10 en 60 seconden bij het station). Of om een random actie te kiezen (er is iedere keer 20% kans dat hij naar spoor B gaat ipv naar spoor A). Maar ook dit kan prima in een finite state machine!

En buiten dat, het ging hier om een pendelbaan. Dit is, hoe je het ook doet, iets erg statisch 


Timo

[gvandersel]

Timo,

Klopt, een statemachine is onvoorspebaar te maken door de overgangen tussen de verschillende toestanden aan onverwachte dingen te hangen. Dit maakt zo'n statemachine inderdaad leuker.
Het programmeert makkelijker een state machine. Ik persoonlijk zou een statemachine per blok gebruiken en daarna de coordinatie tussen de blokken op een andere manier regelen.

Groet,

Gerard van der Sel.