loopt vast met arduino programmering

Ergens tussen een Arduinese delay(10000) en het zelf in assembly schrijven van een compleet OS zit een gepaste oplossing voor dit soort functies.
Een relevante factor daarbij is wat er in de vingers of voor in het hoofd zit, zodat het zo vlot en in perceptie zo eenvoudig mogelijk opgelost is. Hoewel er goede gewoontes zijn zal dat voor iedereen anders zijn.

Met deze voorbehouden; voor eenvoudige microcontroller projecten net wat voorbij het triviale neig ik tegenwoordig zelf naar:

• Een state machine als hoofdstructuur.
• Non-blocking code.
• Systeemtikken van 10 of 100 ms, niet in de laatste plaats omdat het dan eenvoudig is de load in de gaten te houden, wat goed is voor het begrip wat er gebeurd en/of nog bij kan.
• Interrupts enkel voor hardware gerelateerde zaken, zoals (rotary encoder-) pulsen tellen, stap pulsen zenden, samples nemen, displays multiplexen etc.
  Interrupts nooit voor drukknoppen, dan zou men in hardware moeten ontdenderen wat onelegant voelt.
  Ik lees de knop gewoon regelmatig, iedere tik, in. Mensen zijn toch niet zo snel

hallo,

zoals vele van jullie al zijde had ik een kleine letter k gebruikt inplaats van hoofdletter K.

de arduino hoeft geen temperatuur te regelen. er zat hier maar 4 schakelingen op. 1 voor waterklep, 1 voor pomp, 1 voor stroom van de tijdklok, 1 voor de zeep pomp. de rest word analoog geregeld en hoeft de arduino niks mee te doen. de arduino neemt alleen de taken over van de tijdklok die kapot is. dus in dit geval de 4 relais de verder gewoon het zelfde blijft.

ik heb de programma nu werkend en ziet er goed uit met de delay. alleen heb nu het probleem dit die constant herhaalt terwijl ik de knop meer 1 x ingedrukt hebt.

heb vermoeden dat de buttonstate nog steeds op high staat. hoe kan ik die in het einde van de programma veranderen naar low.

alvast bedankt

Achter de if van program lang zet je beide weer op low

Op 25 december 2022 19:44:06 schreef fcapri:
Achter de if van program lang zet je beide weer op low

currentButtonState_k = LOW;

currentButtonState_L = low;

op deze manier?

Druktoetsen detecteren doe je in een timerinterrupt, dan wordt er niets opgehouden, en ben je veel flexibeler...

"doe je"? Dat is 1 mogelijke manier, ja, maar niet de enige, en niet alleenzaligmakend.

.dubbel

[Bericht gewijzigd door fcapri op maandag 26 december 2022 16:56:10 (99%)]

Op 25 december 2022 20:04:39 schreef Jd6130r:
[...]

currentButtonState_k = LOW;

currentButtonState_L = low;

op deze manier?

zo krijg je weer een fout dat die eerste niet gedeclareerd is. hoofdletter K gebruiken.
maar idd, zo kan je het doen.

eigenlijk zou ik de loop helemaal anders maken en je programma in sub programma runnen. het enige verschil is die ene tijd 120000 vs 360000. geef die als variabele mee

void loop() {
  lastButtonState_K = currentButtonState_K ;     // save the last state
  currentButtonState_K = digitalRead(BUTTON_PIN_K); // read new state

  if(lastButtonState_K == HIGH && currentButtonState_K == LOW) {
      Serial.println("The button KORT is pressed");
      program(120000);
      currentButtonState_K = LOW;
      
  }
  if(lastButtonState_L == HIGH && currentButtonState_L == LOW) {
      Serial.println("The button LANG is pressed");
      program(360000);
      currentButtonState_L = LOW;
  }
}

void program(int programtijd) {
      digitalWrite(RELAY_PIN_4,HIGH);
      delay(500);
      digitalWrite(RELAY_PIN_4,LOW);
      digitalWrite(RELAY_PIN_2,HIGH);
      delay(programtijd);
      digitalWrite(RELAY_PIN_2,LOW);
      digitalWrite(RELAY_PIN_1,HIGH);
      delay(15000);
      digitalWrite(RELAY_PIN_1,LOW);
}

trouwens, werkt dat programma wel??? ik zie dat je nergens die BUTTON_PIN_L inleest in de loop, dus dat lang programma kan nooit draaien.

om uit de loop te geraken kan je ergens een variabele gebruiken.
bv in algedraaid = 0;

moment dat je 1 programma gestart hebt, zet je die op 1.
en in de loop maak je een grote if die enkel werkt als algedraaid op 0 staat.
heb je dus 1 vaat gedraaid, moet je resetten om nog eens te draaien.

daarna maak je een display met een menu, 4 drukknoppen (omhoog, omlaag, reset en start).
kan je in het display selectie maken:
eco program
normal program
lang program
eco is dan dat de watertemperatuur lager is dan beide.

kwa veiligheid zou je ook moeten ingrijpen als je computer vastloopt. dus een timer ernaast die de machine na pakweg 3uur spanningsloos zet als je arduino zijn programma niet heeft afgewerkt. je kan dan een foutcode genereren.
BV Error1: runtime to long
Error2: temperatuur not reached
....

en in no time heb je zelf een ingewikkelde vaatwas gebouwd met alle functies van een nieuwe .

tip, zorg dat je de usb connector toegankelijk hebt, zodat je 'firmware updates' kan uitvoeren van alle nieuwigheden die je bijmaakt.
want je zal updates maken.
het volgende dat je wil, is een countdown timer op je display dat de tijd weergeeft voordat het programma gedaan is. je zal enorm bijleren met dit projectje en met wat kleine euros kan je opties toevoegen tot een met (een display van 2€, en draaiknopje voor in je menu te scrollen, opties om zelf je temperatuur in te stellen (koud-40°-60°...), nog eens extra naspoelen voor glazen...)

"doe je"? Dat is 1 mogelijke manier, ja, maar niet de enige, en niet alleenzaligmakend.

Toch ga ik daarbij volkomen met Arco mee. Het maakt 'ondenderen' kinderlijk eenvoudig - en die interrupt loopt toch.

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 maandag 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 donderdag 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