loopt vast met arduino programmering

Je bent bij afhandeling in interrupt veel en veel flexibeler (ook voor onverwachte toekomstige uitbreidingen die er volgens Murphy zeker komen... )
Debounce is inderdaad simpel, en ook iets als een repeteer functie (zoals bij pc keyboard: toetsdruk wordt herhaald bij lang indrukken)

En de rest van je programma heeft er geen last van...

Het is zeker een goede manier, dat spreek ik niet tegen. Maar ik krijg de kriebels van het toontje - misschien niet zo bedoeld - van "wat ik vertel dat is de enige waarheid en al de rest doet er niet toe".

Welke manier voor iemand de beste is, dat maakt die zelf maar uit. Wij zijn hier om ideetjes aan te brengen, om informatie bij te brengen, om ervaringen te vergelijken. Niet om vanuit ivoren torens onze oekazes te verkondigen.

Had er nu gestaan "Druktoetsen detecteren doe je volgens mij het best in een timerinterrupt" dan stond ik luidkeels te applaudisseren !

[Bericht gewijzigd door Paulinha_B op 26 december 2022 14:27:18 (14%)

Kijk,

Daar wordt ik nou kregelig van, van dat semantiek geneuzel zonder praktische onderbouwing...

Wat ik zeg bedoel ik ook: afhandeling in een interrupt is de simpelste en meest efficiente manier om toetsen af te handelen.
Alleen als je een processor hebt die 99.99% van de tijd niets doet is wachten en/of delays gebruiken ook te doen, maar beter is het zeker niet...

Dan zullen we er maar niet verder op ingaan. "de simpelste en efficientste manier" is bovendien ook heel fraai en netjes gesteld - dank!

Welke manier voor iemand de beste is, dat maakt die zelf maar uit.

Dat is een discussie die ik in het verleden ook vaak met mijn zoon gevoerd heb. Waarom zou je tijd en moeite steken om de 1000 wegen naar Rome zelf te ontdekken. Dat geeft mislukkingen (sommigen zijn doodlopend) en frustratie omdat ze je niet brengen waar je wil. De dooddoener : " Je leert er van", nou je leert er van hoe het niet moet en dat is frustrerend. Liever luister ik dan naar "mensen" die er dagelijks mee bezig zijn, een ANWB, een TomTom en qua programmeren hier op het forum naar een Arco, EricP, Rew die er veel vaker mee bezig zijn en bij andere programmeurs een hoop frustratie kunnen voorkomen. Je "wat ik vertel is de waarheid" kan meer waar zijn dan je denkt. 20 jaar geleden ( hoor, Opa verteld) heb ik software van een niet echte beginner in de software wereld (IBM) een complete Unix machine onderuit zien halen omdat de programmeur dacht dat het een goed idee was "Delays" te maken door tellers te laten lopen en zo de machine "bezig te houden". Er zijn gewoon zaken als "Best practices" en die heten niet voor niets zo. En Timer interrupts en state machines zijn er daar een paar van

Mijn vader (niet bprosman ) noemde bij het kerstdiner nog een software kwaliteit, namelijk terugleesbaarheid.

Dat vind ik wel een goede, die ook wijst naar het inzetten van gebruikelijke structuren.

Als er een ongebruikelijke structuur gebruikt wordt, moet het nog steeds leesbare code zijn. Onderhoudbaarheid is een van de belangrijkste aspecten van software implementatie (en ook van HDL trouwens).

ja, het is verwonderlijk dat je uw eigen code 2maand later totaal niet meer begrijpt.
op de moment dat je er mee bezig bent, lijkt het super logisch, maar een paar weken/maanden/later niet meer.

ik probeer daarom het aantal regels ferm te reduceren. hierboven was dat 1 grote blok in die loop, daar heb je geen overzicht meer van dan.

ik werk dan liever heel compact, mijn loop zou hier niet meer zijn dan:

void loop{
lees_inputs();
*verwerk_inputs();*
run_program();
}

en dan een sub routine om de knop in te lezen
en een sub routine voor het eigenlijk programma.
zijn er bepaalde handelingen voor de data waar je wil mee werken, dan doe ik dat in verwerk inputs

en dan is zoiets heel makkelijk te volgen, en een stuk duidelijker dan 10 geneste if's

noemde bij het kerstdiner nog een software kwaliteit, namelijk terugleesbaarheid.

Ik ben het helemaal met de beste man eens. Deels is dat het gevolg van de 'rat race' om altijd snel te moeten zijn (deel markt, deels omdat de 'omgeving' snel verandert) deels is het botweg onkunde - en dat begint vaak al bij de opzet en vervolgens doorborduren op ellende.

Toch is er niks mis mee om zo nu en dan zelf eens de weg naar Rome te zoeken. Immers, als je nooit buiten de gebaande paden komt, dan kom je ook nooit verder dan 'het gemiddelde'. Toch is het daarbij belangrijk om het doel niet uit het oog te verliezen. Als 'iets nieuws proberen' het doel is: vooral proberen. Waarschijnlijk ga je op je m**l, maar je hebt een hoop geleerd en wellicht vind je een prima bruikbare weg.
Als de bestaande wegen het niet doen zoals voor jou noodzakelijk: vooral doen. Met de bestaande wegen kom je er blijkbaar niet.
Als je een stuk productie software uit de grond moet stampen waarbij 'de rest' al uitdaging genoeg biedt, dan pak je waar je dat kunt de gebaande weg.

zelf in assembly schrijven van een compleet OS

Timer interrupts zijn niet voorbehouden aan een OS. Daarnaast... assembly doe ik een hele enkele keer nog - en dan met een specifieke reden (doorgaans volkomen controle over de timing). Maar meestal is het gewoon C.

Onderhoudbaarheid is een van de belangrijkste aspecten van software implementatie

Doorgaans wel. Toch ontkom je niet altijd aan een stukje 'write-only' code. Doorgaans is dat performance en een enkele keer memory (8052, wat 'custom made' processortjes waar ik mee gewerkt heb) gerelateerd. De 'way to go' is doorgaans de 'interface' waterdicht documenteren en er voor zorgen dat dat stukje code gewoon werkt zonder rare bugs (ofwel: voorkom dat een ander er nog eens in moet duiken). Doorgaans is het compact en niet overdreven complex, beiden zijn dan goed te doen. (dat is een hoop 'doorgaans' Ja, er zijn altijd situaties te verzinnen waarin het nou net niet op gaat. Verzin wat moois!).

De spreuk die me altijd is bijgebleven: Als architecten zouden bouwen als programmeurs, dan zou een enkele specht hele steden kunnen verwoesten.
De oorzaak zit doorgaans in het alleen maar 'functioneel' denken en vergeten dat er ook wel eens exceptions optreden. Bij de meeste projecten lijkt het al uitdagend genoeg te zijn om het functioneel een soort van werkend te krijgen. 'Robuust' is meestal een brug te ver.
Het kan overigens wel. Ik heb (had, ik doe het niet veel meer) eigenlijk in vrijwel alles wat ik gemaakt heb met 24/7 te maken: stilstand kost geld. Fouten in 'output' trouwens ook. En je wordt ervoor gebeld - volgens Murphy is dat altijd 's nachts. Je leert het snel af

Toch is er niks mis mee om zo nu en dan zelf eens de weg naar Rome te zoeken. Immers, als je nooit buiten de gebaande paden komt, dan kom je ook nooit verder dan 'het gemiddelde'.

Maar als 10 anderen tegen je zeggen dat die weg doodlopend is moet je je afvragen of het nog zin heeft te kijken of ze gelijk hebben.

Heb de sketch gedownload en de twee k's in regel 35 veranderd in hoofdleter K.
Mij mij compileerd hij.
Ben verder niet zo goed in het programmeren daarom verder niet gekeken.
gr. Winand

Dat blijft een eeuwige discussie. Als die 10 met een sluitend verhaal komen, dan waarschijnlijk wel. Is het de kortste weg? Waarschijnlijk niet.

Het hangt er wederom vanaf... wat je doel is.

Ik denk dan altijd aan een stukje uit Genius: Einstein (ik weet niet de serie allemaal gezien hebben). Ergens heeft men verzonnen dat 'tijd' absoluut is. Met een heel verhaal er omheen - en dat leek redelijk te kloppen. Toch klopte dat volgens Einstein niet. Uiteindelijk kreeg hij gelijk - en kon dat nog aantonen ook (iets met een bliksem, een donder en een trein...).
Maar goed... Einstein had dan ook als doel 'onderzoeken'. En niet 'productie draaien'

Het punt is dit: als iedereen steeds opnieuw bij het begin blijft beginnen, dan komt je _met_z'n_allen_ geen steek verder. Dan blijf je steeds op het zelfde punt uit komen. Als je nou eens begint met aan te nemen wat anderen al tig jaar geleden hebben ervaren, en wat inmiddels algemeen is aangenomen, dan kun je _daar_bovenop_ iets extra toevoegen. En dan wordt je met z'n allen steeds beter. Dat deed Einstein ook, die heeft ook de basis vd Natuurkunde niet opnieuw bedacht. Die ging verder waar anderen gebleven waren.

hallo alle,

heb het programma werkend en ben daar tevreden over.

alleen het gekke is nu wanneer de boiler omschakelt naar de verwarming element of weer terug gaat naar de boiler. begint hij ineens uitzicht zelf een wasprogramma.

hier zit een kleine boiler op, en een verwarming element in een bak met water. ze gaan nooit te gelijk aan. wanneer hij schakelt tussen de boiler of verwarming element gaat de wasprogramma aan van de arduino

kan het zo zijn dat de 230v kabels en de 5v storing geeft of zo iets.

heb nu namelijk 230v in vaatwasser gepakt een omvormer van 12v tussen gezet en daar de arduino uno op aangesloten. de kabels van de drukknoppen arduino lopen wel langs de 230v kabels.

hoor graag of jullie misschien weten waardoor het komt en hoe het opgelost kan worden

alvast bedankt

[Bericht gewijzigd door Jd6130r op 29 december 2022 11:02:09 (100%)

Doe wat met debouncing. Dan ben je hier waarschijnlijk ook wel van af. Al is het een lapmiddel...

heb nu namelijk 230v in vaatwasser gepakt een omvormer van 12v tussen gezet

Dat moet kunnen. Echter 12V is wel wat veel voor de Vin van de arduino. IK zou zelf gewoon direct naar 5V gaan en dat op de arduino 5V aanbieden.

Om daar eventueel storing van DCDC converter te ondrukken kan je nog een 100nF en extra 1000uF eleco erbij plaatsen met elke een spanning van 16V of beter.

De meeste kans op storing van een arduino zijn de ingangen onderstaand schema helpt daar tegen