[Discussie] Arduino-topic

[Septillion]

@Atmoz Als eerste, je vult hem uit een String, niet een string

En weer zit je met wat mogelijk is tijdens runtime. Je hebt nu een compiler time initializatie staan van je array maar 'dataad' is nog niets. Je zal de array moeten vullen tijdens runtime door over alle times te lopen en een copy te doen. En 'TwinkleTwinkle4' zal groot genoeg moeten zijn om dat te kunnen hebben.

Daarnaast, wat staat er in je String? Echt losse 1-char grote noten of echt de tekst "NOTE_A5"? Beetje een XY problem

Ik kan denk ik alleen maar aanraden hier om die String te laten vallen. Ik denk echt dat je het daarmee veel lastiger maakt dan je zou moeten willen.

PS Wat een variable namen.....

[Atmoz]

Septillion schreef op maandag 21 juni 2021 @ 17:18:
@Atmoz Als eerste, je vult hem uit een String, niet een string

Thanks! Ik ga straks even uitzoeken wat de verschillen zijn

En weer zit je met wat mogelijk is tijdens runtime. Je hebt nu een compiler time initializatie staan van je array maar 'dataad' is nog niets. Je zal de array moeten vullen tijdens runtime door over alle times te lopen en een copy te doen. En 'TwinkleTwinkle4' zal groot genoeg moeten zijn om dat te kunnen hebben.

Ah wow! Ok, ik dacht al... dit kán toch gewoon niet wat hier (weer) aan de hand is

Ik snap denk ik redelijk goed aan de hand is hier, maar ik zou niet weten hoe ik dit moet oplossen...

Daarnaast, wat staat er in je String? Echt losse 1-char grote noten of echt de tekst "NOTE_A5"? Beetje een XY problem

Ik stuur vanuit de PC een String met daarin 50
Dus op de PC doe ik: SendUDP("50")

Ik kan denk ik alleen maar aanraden hier om die String te laten vallen. Ik denk echt dat je het daarmee veel lastiger maakt dan je zou moeten willen.

Ik lees sowieso dat werken met Strings absoluut niet het beste/fijnste is... Maarja, hoe dan?

PS Wat een variable namen.....

Haha klopt, dat krijg je vanzelf na vele uren achter elkaar dingen proberen/prutsen/testen...
Dan gaat het al snel van redelijke nette en logische benamingen naar "test123", testSjrot, etc...
En als het écht lukt soms zelfs scheldwoorden, maar dat is dan toch met de gedachte om het de volgende compile er weer uit te halen omdat het puur om te testen is die keer

Anyway: ik ben érg benieuwd hoe ik mijn probleem hierboven kan oplossen...

[Septillion]

Atmoz schreef op maandag 21 juni 2021 @ 18:22:
Thanks! Ik ga straks even uitzoeken wat de verschillen zijn

Een string is gewoon een array van char afgesloten met een null-char.
Een String is een object met dynamisch geheugen.

Ik stuur vanuit de PC een String met daarin 50
Dus op de PC doe ik: SendUDP("50")

Dat is dus een string met "50".

Ik lees sowieso dat werken met Strings absoluut niet het beste/fijnste is... Maarja, hoe dan?

Gewoon naar een char array lezen. En dan eigenlijk daarna direct al omzetten naar een nummer en daarmee eigenlijk een char/byte. Je zou ook al direct de byte waarde kunnen sturen misschien.

Met welke functie luister je naar UDP? Zelf nooit direct met UDP gewerkt.

En wil je ook meer dan één waarde kunnen sturen? Al bedacht hoe je "protool" er dan uit gaat zien?

Haha klopt, dat krijg je vanzelf na vele uren achter elkaar dingen proberen/prutsen/testen...
Dan gaat het al snel van redelijke nette en logische benamingen naar "test123", testSjrot, etc...
En als het écht lukt soms zelfs scheldwoorden, maar dat is dan toch met de gedachte om het de volgende compile er weer uit te halen omdat het puur om te testen is die keer

Toch probeer ik dan vaak logische namen te houden omdat ik het anders zelf 5 minuten later al niet meer snap

[Atmoz]

Septillion schreef op maandag 21 juni 2021 @ 20:10:
[...]

Een string is gewoon een array van char afgesloten met een null-char.
Een String is een object met dynamisch geheugen.


[...]

Dat is dus een string met "50".


[...]

Dankjewel!

Gewoon naar een char array lezen. En dan eigenlijk daarna direct al omzetten naar een nummer en daarmee eigenlijk een char/byte. Je zou ook al direct de byte waarde kunnen sturen misschien.

Hmzz, klinkt als je het zo zegt makkelijker gezegd dan gedaan

Met welke functie luister je naar UDP? Zelf nooit direct met UDP gewerkt.

Dat doe ik zo:

code:

   if(udp.listen(1234)) {
        udp.onPacket([](AsyncUDPPacket packet) {
            String test = (const char*)packet.data();        
            TestSjrot(test);
            //reply to the client
            //packet.printf("Got %u bytes of data", packet.length());
        });
    }

En wil je ook meer dan één waarde kunnen sturen? Al bedacht hoe je "protocol" er dan uit gaat zien?

Daar heb ik inderdaad wel al stiekem over nagedacht, maar voor nu hoeft dat niet. Ik ben al lang blij als 1 toon werkt.
Zojuist heb ik int8_t dataad = -50; globaal (boven setup()) gedeclareerd, en dan tijdens runtime vul ik hem weer, maar zelfs dán werkt het niet. Ik dacht dat ik hiermee dat probleem van het aanmaken tijdens compile time had omzeilt?!

Toch probeer ik dan vaak logische namen te houden omdat ik het anders zelf 5 minuten later al niet meer snap

Je hebt helemaal gelijk, ik moet daar ook wat serieuzer mee om gaan.

[Septillion]

@Atmoz Even recap wat je hier doet

C++:

String test = (const char*)packet.data();  

Je hebt een AsyncUDPPacket-object waar je de methode data() van aanroept. Return type daarvan is een uint8_t pointer. Deze cast je vervolgens naar een const char pointer. Vervolgens maak je een String-object aan waar je dit via operator overloading aan toevoegt. Beetje omslachtig dus.

Daarnaast hoeft packet.data() volgens mij niet null-terminated te zijn. Het dus zomaar als string (char pointer/array) is dus gevaarlijk. Volgens mij ben je zelf verantwoordelijk om te checken dat je nog in de data zit door middel van data.length() of door het te lezen met .read() (ook al is het wel raar dat read(void) int als return type heeft...).

Dus denk dat het een goed moment is om een stap terug te nemen en even goed te bedenken (en te beschrijven) wat je wilt bereiken. Want zo met snippets helpen is ergggg lastig.

[Shattering]

Hey allen! Recent gestart met arduino's. Wat leuk! Ik was op zoek naar een webshop waar ik accessoires, kabels & dergelijk kon aankopen. Hebben jullie tips?

Bedankt!

[Accretion]

Shattering schreef op zaterdag 26 juni 2021 @ 18:43:
Hey allen! Recent gestart met arduino's. Wat leuk! Ik was op zoek naar een webshop waar ik accessoires, kabels & dergelijk kon aankopen. Hebben jullie tips?

Bedankt!

Binnenkort moet je BTW en invoerrechten betalen vanuit China.

Dus wellicht een starterkit van eBay en een paar Arduino-clones.

Maar ook bijvoorbeeld arrangement aan weerstandjes, LED's, knopjes e.d.

[Septillion]

Binnenkort is over 4 dagen... Dus voor China bestellingen zonder BTW en PostNL toeslag ben je al te laat

[AteGjalt]

Shattering schreef op zaterdag 26 juni 2021 @ 18:43:
Hey allen! Recent gestart met arduino's. Wat leuk! Ik was op zoek naar een webshop waar ik accessoires, kabels & dergelijk kon aankopen. Hebben jullie tips?

Bedankt!

bitsandparts.nl en tinytronics.nl zijn wel goede hobby shops, heb er zelf geen enkele klacht over.

[Shattering]

Hey! Heb gisteren een hoop spulletjes besteld op bitsandparts.nl.
Nu nog wat leuke projecten verzinnen .

[AteGjalt]

@Shattering kijk eens op hackster.io voor wat inspiratie.

[Raven]

Raven schreef op vrijdag 4 juni 2021 @ 09:36:
Weet iemand toevallig waar de Arduino IDE de entries uit network ports (in menu ports) bewaart? Er staat een NodeMCU met OTA sketch dubbel in omdat ik na het (over verschillende subnets ) werkend krijgen van OTA static DHCP aan heb gezet en 't ding een ander IP heeft gekregen, waardoor entry nr 2 verscheen. Ik zie niet hoe ik de oude eruit kan halen...

Anyone? Op het Arduino-forum weten ze het niet en heb Total Commander alle Arduino IDE gerelateerde files laten doorzoeken op de naam van de netwerkpoort die ik eruit wil hebben, niks gevonden.

[Raymond P]

@Raven AFAIK leunt de Arduino IDE network discovery op Multicast DNS (mDNS).
Je entry zou dus moeten verdwijnen als je de IDE restart, daar wordt (door de IDE) geen cache van bijgehouden.

[ Voor 0% gewijzigd door Raymond P op 22-07-2021 14:43 . Reden: typo ]

[Raven]

@Raymond P mDNS ben ik mee bekend, heb er een programma op de router-pc voor moeten installeren om die datapakketjes naar een ander VLAN te krijgen zodat ik vanuit elk netwerk van OTA gebruik kan maken.

... en dat was het inderdaad, had de hele tijd de IDE open gehouden, blijkbaar "vergeet" ie pas de entries bij een herstart.

[Raymond P]

Ja die hele flow is een beetje klungelig. Zeker als je een aantal actief hebt.

Ik gebruik arduino-cli en espota.py zodat ik daar geen last van heb en gewoon een hostname of ip mee kan geven.
snelle copy/paste:

code:

#!/bin/sh

arduino-cli compile --build-cache-path /home/ray/sketchbook/cache --fqbn esp8266:esp8266:d1_mini:ssl=basic,dbg=Disabled /home/ray/sketchbook/sensor

python3 /home/ray/.arduino15/packages/esp8266/hardware/esp8266/2.7.2/tools/espota.py -i temperature.iot.lan.int -p 8266 --auth="temperature" -f "/home/ray/sketchbook/sensor/sensor.esp8266.esp8266.d1_mini.bin"

[Mee_]

Eenvoudig vraagje: ik heb een Arduino Nano 33 IoT, maar deze heeft - waar hij zit - niet genoeg wifi-signaal. Is het mogelijk om de range hiervan te verbeteren met een externe antenne?

[Toiletman]

'avond. Na een aantal jaar geen Arduino meer aangeraakt te hebben ligt er een mooi project in het verschiet: het automatiseren van de tuinberegening:

Ruwe situatieschets:

Outputs:
7x 24V AC kleppen (solenoids)
1x 230V AC Pomp
1x 230V AC Heater

Inputs:
- weersvoorspelling
- temperatuursensor technische ruimte
- waternivosensor (waterdichte drukmeter?)
- watersensor overstort
- watersensor lekkage
- (luchtvochtigheid)
- (T buiten)
- (lichtintensiteit buiten?)

Ik zit nog een beetje te twijfelen over de aanpak maar ik zat te denken aan een Arduino setup via ethernet. Datalogging kan dan via de NAS, en eventueel parsen van weerdata en instellen van irrigatieplannen ook. Dat kan dan via ethernet naar de arduino als input.

Qua hoeveelheid inputs/outputs zou het gewoon met een Uno moeten kunnen, waarbij ik me echter afvraag of de hoeveelheid geheugen wel ok is?

Een alternatief zou zijn om meer werk op de Arduino zelf te doen en de NAS minder te laten doen (alleen logging?). Het lijkt me dat je dan al echt wel op een Mega uitkomt?

Hoe kijken jullie hier tegenaan? Uno of Mega? Of zou het met allebei wel moeten lukken?

Qua verdere hardware ben ik nog een beetje aan het rondshoppen, qua outputs heb ik in ieder geval deze relais gevonden:
8CH 5V relais bordje
5V 40A 230V SSR
Het 8CH bordje zal via een aparte 5V voeding moeten worden gevoed omdat de Arduino niet genoeg stroom kan leveren.
De 230V relais lijken me wel handig om in een aparte behuizing te doen en de pomp trekt max 6A, dus met de meeste 'dev boardjes kom je er toch niet.

In totaal levert dit al wel een hoop voedingen op:
5VDC voor de 8CH relais
7/9VDC voor de Arduino zelf
24VAC voor de kleppen
(en natuurlijk 230V voor alles)... kan dit nog op een fraaiere manier?

Qua aansturing via ethernet is er natuurlijk het ethernet shield van arduino, maar ik kwam ook dit boardje tegen: goedkoper en ook een stuk minder 'intrusive'. Iemand ervaring met (één van) beide oplossingen?

Naar het hele sensorgebeuren moet ik nog gaan kijken, dat wordt waarschijnlijk volgend weekend.

Hoe kijken jullie hier tegenaan? Ben ik op de juiste weg? Andere ideeën?

In domotica is natuurlijk behoorlijk wat te vinden van mensen die middels HA of domoticz of dergelijke platforms soortgelijke dingen doen, maar wij hebben verder nog geen domotica, dus ik wilde nog niet meteen in die hele wereld duiken.

[itcouldbeanyone]

Toiletman schreef op zondag 8 augustus 2021 @ 21:52:
'avond. Na een aantal jaar geen Arduino meer aangeraakt te hebben ligt er een mooi project in het verschiet: het automatiseren van de tuinberegening:

Ruwe situatieschets:

Outputs:
7x 24V AC kleppen (solenoids)
1x 230V AC Pomp
1x 230V AC Heater

Inputs:
- weersvoorspelling
- temperatuursensor technische ruimte
- waternivosensor (waterdichte drukmeter?)
- watersensor overstort
- watersensor lekkage
- (luchtvochtigheid)
- (T buiten)
- (lichtintensiteit buiten?)

Ik zit nog een beetje te twijfelen over de aanpak maar ik zat te denken aan een Arduino setup via ethernet. Datalogging kan dan via de NAS, en eventueel parsen van weerdata en instellen van irrigatieplannen ook. Dat kan dan via ethernet naar de arduino als input.

Qua hoeveelheid inputs/outputs zou het gewoon met een Uno moeten kunnen, waarbij ik me echter afvraag of de hoeveelheid geheugen wel ok is?

Een alternatief zou zijn om meer werk op de Arduino zelf te doen en de NAS minder te laten doen (alleen logging?). Het lijkt me dat je dan al echt wel op een Mega uitkomt?

Hoe kijken jullie hier tegenaan? Uno of Mega? Of zou het met allebei wel moeten lukken?

Qua verdere hardware ben ik nog een beetje aan het rondshoppen, qua outputs heb ik in ieder geval deze relais gevonden:
8CH 5V relais bordje
5V 40A 230V SSR
Het 8CH bordje zal via een aparte 5V voeding moeten worden gevoed omdat de Arduino niet genoeg stroom kan leveren.
De 230V relais lijken me wel handig om in een aparte behuizing te doen en de pomp trekt max 6A, dus met de meeste 'dev boardjes kom je er toch niet.

In totaal levert dit al wel een hoop voedingen op:
5VDC voor de 8CH relais
7/9VDC voor de Arduino zelf
24VAC voor de kleppen
(en natuurlijk 230V voor alles)... kan dit nog op een fraaiere manier?

Qua aansturing via ethernet is er natuurlijk het ethernet shield van arduino, maar ik kwam ook dit boardje tegen: goedkoper en ook een stuk minder 'intrusive'. Iemand ervaring met (één van) beide oplossingen?

Naar het hele sensorgebeuren moet ik nog gaan kijken, dat wordt waarschijnlijk volgend weekend.

Hoe kijken jullie hier tegenaan? Ben ik op de juiste weg? Andere ideeën?

In domotica is natuurlijk behoorlijk wat te vinden van mensen die middels HA of domoticz of dergelijke platforms soortgelijke dingen doen, maar wij hebben verder nog geen domotica, dus ik wilde nog niet meteen in die hele wereld duiken.

Zou prima met een uno kunnen, kwa geheugen hangt van je programming skills af

[AteGjalt]

Toiletman schreef op zondag 8 augustus 2021 @ 21:52:
'avond. Na een aantal jaar geen Arduino meer aangeraakt te hebben ligt er een mooi project in het verschiet: het automatiseren van de tuinberegening:

Ruwe situatieschets:

Outputs:
7x 24V AC kleppen (solenoids)
1x 230V AC Pomp
1x 230V AC Heater

Inputs:
- weersvoorspelling
- temperatuursensor technische ruimte
- waternivosensor (waterdichte drukmeter?)
- watersensor overstort
- watersensor lekkage
- (luchtvochtigheid)
- (T buiten)
- (lichtintensiteit buiten?)

Ik zit nog een beetje te twijfelen over de aanpak maar ik zat te denken aan een Arduino setup via ethernet. Datalogging kan dan via de NAS, en eventueel parsen van weerdata en instellen van irrigatieplannen ook. Dat kan dan via ethernet naar de arduino als input.

Qua hoeveelheid inputs/outputs zou het gewoon met een Uno moeten kunnen, waarbij ik me echter afvraag of de hoeveelheid geheugen wel ok is?

Een alternatief zou zijn om meer werk op de Arduino zelf te doen en de NAS minder te laten doen (alleen logging?). Het lijkt me dat je dan al echt wel op een Mega uitkomt?

Hoe kijken jullie hier tegenaan? Uno of Mega? Of zou het met allebei wel moeten lukken?

Qua verdere hardware ben ik nog een beetje aan het rondshoppen, qua outputs heb ik in ieder geval deze relais gevonden:
8CH 5V relais bordje
5V 40A 230V SSR
Het 8CH bordje zal via een aparte 5V voeding moeten worden gevoed omdat de Arduino niet genoeg stroom kan leveren.
De 230V relais lijken me wel handig om in een aparte behuizing te doen en de pomp trekt max 6A, dus met de meeste 'dev boardjes kom je er toch niet.

In totaal levert dit al wel een hoop voedingen op:
5VDC voor de 8CH relais
7/9VDC voor de Arduino zelf
24VAC voor de kleppen
(en natuurlijk 230V voor alles)... kan dit nog op een fraaiere manier?

Qua aansturing via ethernet is er natuurlijk het ethernet shield van arduino, maar ik kwam ook dit boardje tegen: goedkoper en ook een stuk minder 'intrusive'. Iemand ervaring met (één van) beide oplossingen?

Naar het hele sensorgebeuren moet ik nog gaan kijken, dat wordt waarschijnlijk volgend weekend.

Hoe kijken jullie hier tegenaan? Ben ik op de juiste weg? Andere ideeën?

In domotica is natuurlijk behoorlijk wat te vinden van mensen die middels HA of domoticz of dergelijke platforms soortgelijke dingen doen, maar wij hebben verder nog geen domotica, dus ik wilde nog niet meteen in die hele wereld duiken.

Ik zou voor de zekerheid voor een mega gaan, afhankelijk van de sensoren en libraries kan het aardig in het geheugen gaan zitten. De extra IOs zijn dan mooi meegenomen voor eventuele uitbreidingen.
Je kan van tevoren een sketch maken met alle nodige libraries geimporteerd en alle stukjes voorbeeld en dan kijken of t wil compilen voor de uno.
Voor waterniveau kan je ook kijken of ultrasoon een optie is of een magnetische vlotter en een aantal reedswitches.

[mcDavid]

@Toiletman ik zou uberhaupt afraden zoveel functionaliteit op één arduino te hangen. Niet omdat het niet kan, maar praktisch is anders. Waarschijnlijk zitten niet al die sensoren in één behuizing, dus krijg je allereerst al te maken met grote kabellengtes waar niet alle sensoren mee overweg zullen kunnnen. Daarnaast wordt de firmware flink ingewikkelder naar mate je meer dingen "parallel" wilt doen (iets wat op een uC eigenlijk niet kan natuurlijk).

Ik zou gewoon een handjevol ESP8266's pakken en niet teveel tegelijk op één apparaat willen doen.

[Septillion]

@Toiletman Ik zou zelf nooit voor een Mega gaan, wat een hel aan draadjes maak je er dan van. Gezien je ethernet wilt, een ESP'tje? En dan gewoon er een paar IO extenders aan hangen, blijft het veel netter van.

Of zoals @mcDavid ook suggereert, een handje vol ESP's als het niet allemaal bij elkaar zit.

Qua power, als je voor een 3v3 Arduino gaat kan je gewoon alles vanaf de 5V doen. Als je voor een 5V versie gaat zou ik 12V relays pakken en dit ook gewoon aan de Arduino voeren. Even een diode en een condensator er tussen en gaan. Onboard regulator van meeste bordjes is wat krap maar als je niet zo veel stuurt op 5V gaat het wel. Anders extern een step down converter naar 5V ertegenaan gooien.

[Tom]

Ik heb een Arduino MKR WiFi 1010 besteld, samen met de MRK IoT carrier. Zover ik gezien heb is dat erin klikken, voeding eraan en gaan. Voor een testje zou ik ook graag een camera bestellen (pré als er ook een microfoontje in zit). Kwaliteit is ondergeschikt (mits niet 15 jaar terug gsm-camera in de tijd qua kwaliteit), het is meer voor een proof-of-concept.

Nu kom ik wel camera's tegen, maar ik weet niet goed welke compatible zijn (en voor een leek ook aan de gang te krijgen binnen Arduino). Het liefst zonder te solderen, maar die eis moet ik denk ik laten vallen? Of is er iets met een stekkertje dat op dat carrier-bordje past?

[AteGjalt]

Tom schreef op maandag 9 augustus 2021 @ 14:24:
Ik heb een Arduino MKR WiFi 1010 besteld, samen met de MRK IoT carrier. Zover ik gezien heb is dat erin klikken, voeding eraan en gaan. Voor een testje zou ik ook graag een camera bestellen (pré als er ook een microfoontje in zit). Kwaliteit is ondergeschikt (mits niet 15 jaar terug gsm-camera in de tijd qua kwaliteit), het is meer voor een proof-of-concept.

Nu kom ik wel camera's tegen, maar ik weet niet goed welke compatible zijn (en voor een leek ook aan de gang te krijgen binnen Arduino). Het liefst zonder te solderen, maar die eis moet ik denk ik laten vallen? Of is er iets met een stekkertje dat op dat carrier-bordje past?

Denk dat je moet kijken naar een arducam oid. Een ESP32-CAM is misschien ook een optie.
Beeld en geluid wordt lastig voor een arduino, dan moet je overstappen naar wat krachtigers als een raspberry.

[Tom]

Thanks. Vergeten om te vermelden dat het geen live-feed hoeft te zijn. Als ik er met een event een still (jpg) uit kan halen is dat voldoende.

[Toiletman]

Bedankt voor alle input!

itcouldbeanyone schreef op maandag 9 augustus 2021 [~ i.Stijn] 07:19:
[...]
Zou prima met een uno kunnen, kwa geheugen hangt van je programming skills af

Die zijn niet zo denderend, vandaar .

AteGjalt schreef op maandag 9 augustus 2021 @ 09:49:
[...]
Ik zou voor de zekerheid voor een mega gaan, afhankelijk van de sensoren en libraries kan het aardig in het geheugen gaan zitten. De extra IOs zijn dan mooi meegenomen voor eventuele uitbreidingen.
Je kan van tevoren een sketch maken met alle nodige libraries geimporteerd en alle stukjes voorbeeld en dan kijken of t wil compilen voor de uno.
Voor waterniveau kan je ook kijken of ultrasoon een optie is of een magnetische vlotter en een aantal reedswitches.

Thx! Interessant idee om met een ultrasoon aan de slag te gaan, die zou ik zelfs nog wel moeten hebben liggen.

mcDavid schreef op maandag 9 augustus 2021 @ 10:01:
@Toiletman ik zou uberhaupt afraden zoveel functionaliteit op één arduino te hangen. Niet omdat het niet kan, maar praktisch is anders. Waarschijnlijk zitten niet al die sensoren in één behuizing, dus krijg je allereerst al te maken met grote kabellengtes waar niet alle sensoren mee overweg zullen kunnnen. Daarnaast wordt de firmware flink ingewikkelder naar mate je meer dingen "parallel" wilt doen (iets wat op een uC eigenlijk niet kan natuurlijk).

Ik zou gewoon een handjevol ESP8266's pakken en niet teveel tegelijk op één apparaat willen doen.

mbt 'parallel' is dat niet echt aan de orde, 1x per minuut dataloggen is waarschijnlijk al overkill, dus het alles mag gewoon sequentieel en het mag nog lang duren ook.

Septillion schreef op maandag 9 augustus 2021 @ 10:13:
@Toiletman Ik zou zelf nooit voor een Mega gaan, wat een hel aan draadjes maak je er dan van. Gezien je ethernet wilt, een ESP'tje? En dan gewoon er een paar IO extenders aan hangen, blijft het veel netter van.

Of zoals @mcDavid ook suggereert, een handje vol ESP's als het niet allemaal bij elkaar zit.

Qua power, als je voor een 3v3 Arduino gaat kan je gewoon alles vanaf de 5V doen. Als je voor een 5V versie gaat zou ik 12V relays pakken en dit ook gewoon aan de Arduino voeren. Even een diode en een condensator er tussen en gaan. Onboard regulator van meeste bordjes is wat krap maar als je niet zo veel stuurt op 5V gaat het wel. Anders extern een step down converter naar 5V ertegenaan gooien.

Ik pak jullie reacties mbt ESP en draadjes even samen hoor:
Die ESP's had ik al wel eens van gehoord, maar vooral als wifi chip. Er zit blijkbaar ook ethernet bij, maar kaartjes waar die ook daadwerkelijk gebruikt zijn een stuk prijziger dan de typische paar dollar. Ik ben zelf niet zo denderend qua elektronica solderen en dergelijke, dus ik heb het liefst iets dat out of the box al redelijk goed werkt.
Of bedoelen jullie om gewoon met de wifi versies aan de slag te gaan? Qua beveiliging en ethervervuiling heb ik het liever bedraad.
Het voordeel van ESP's met extenderboardjes is dat je dan de draadjes fysiek wat beter van elkaar kunt scheiden? Of begrijp ik het verkeerd?

Qua draadjes is de grootste bende natuurlijk de 8 kleppen, maar die leken me redelijk netjes weg te werken door het relaisbord en de kleppen redelijk dicht bij elkaar te zetten en de signaaldraden vanuit de mega middels UTP kabel te doen (dus één draad met een hoop aders).
Het sensorgebeuren moet ik nog wat dieper induiken, maar dat zou inderdaad nogal een zooitje kunnen worden met wat er allemaal heen en weer moet... maar ook daar wellicht dat één of twee UTP kabels een hoop kunnen vervoeren zonder een enorme chaos.

Je voedingsadvies snijdt wel hout, ik zal eens kijken wat de opties voor 3,3V arduino zijn, of anders 12V relais.

[LooneyTunes]

Toiletman schreef op maandag 9 augustus 2021 @ 22:57:

Qua draadjes is de grootste bende natuurlijk de 8 kleppen, maar die leken me redelijk netjes weg te werken door het relaisbord en de kleppen redelijk dicht bij elkaar te zetten en de signaaldraden vanuit de mega middels UTP kabel te doen (dus één draad met een hoop aders).

Let dan vooral op de lengte van je kabel (heen en terug) en het stroomverbruik van de kleppen. (~1 Ampère schijnt normaal te zijn bij 24v AC)
Ethernetkabel is niet gemaakt voor stroom .
En natuurlijk geleiders van koper en geen aluminium en/of ijzer.

[ Voor 5% gewijzigd door LooneyTunes op 10-08-2021 11:23 ]

[mcDavid]

LooneyTunes schreef op maandag 9 augustus 2021 @ 23:53:
[...]

Ik pak jullie reacties mbt ESP en draadjes even samen hoor:
Die ESP's had ik al wel eens van gehoord, maar vooral als wifi chip. Er zit blijkbaar ook ethernet bij, maar kaartjes waar die ook daadwerkelijk gebruikt zijn een stuk prijziger dan de typische paar dollar. Ik ben zelf niet zo denderend qua elektronica solderen en dergelijke, dus ik heb het liefst iets dat out of the box al redelijk goed werkt.
Of bedoelen jullie om gewoon met de wifi versies aan de slag te gaan? Qua beveiliging en ethervervuiling heb ik het liever bedraad.
Het voordeel van ESP's met extenderboardjes is dat je dan de draadjes fysiek wat beter van elkaar kunt scheiden? Of begrijp ik het verkeerd?

Oh, dat er ethernetvarianten bestaan wist ik niet eens. Ik zou gewoon lekker met wifi werken. Hoeveel "ethervervuiling" verwacht je van een boardje dat 1x per minuut een handjevol TCP pakketjes verstuurt? Duty cycle zal nog geen honderste zijn van je telefoon of zo. En wifi is over het algemeen een stuk veiliger dan ethernet. Tenzij je 802.1x geimplementeerd hebt maar dat betwijfel ik (en twijfel nog harder of uC-libraries dat ondersteunen).

[Septillion]

@Toiletman Als je de boel stabiel wilt hebben zal je toch echt moeten solderen, alles met een bende Dupond draadjes doen is ook wel vragen om problemen in een project van dit formaat. Zeker omdat als je wat lengte hebt naar sensoren je waarschijnlijk ook nog wel een beetje filtering wilt doen.

En ja, de ESP kan ook wel werken met bedraad ethernet, volgens mij ook wel met de gelinkte module, maar het is wel wat meer werk dan gewoon de wifi. Voor ethervervuiling hoef je niet bang te zijn als je nu al wifi hebt. Bordje zal daar amper aan bijdragen, zeker als hij maar 1x per uur wat moet loggen. En beveiliging, als je nu ook wifi draait verandert een extra wifi client daar natuurlijk niets aan. Dus tenzij je nu helemaal geen Wifi hebt is dat geen issue.

Extra voordeel van een ESP over een klassieke 8-bit Arduino is dat je veel meer rekenkracht en geheugen hebt, erg fijn als je internet/netwerk zaken gaat doen.

En ja, als je wat behapbare modules hebt kan je die mooi kort aansluiten op waar het nodig is. Zet ze op een printplaat met wat connectoren / aansluitingen (en filtering) voor de sensoren etc. Want daar zie ik meer draden rommel (samen met dat een Arduino altijd te weinig power en GND aansluitingen heeft). Zoveel draadjes op een Mega aansluiten eindigt naar mijn idee altijd alleen maar in spaghetti bolognese. Niet zo zeer door de draadlengtes maar meer dat het gewoon veel draadjes zijn. Ook al pak je UTP, het blijven veel draadjes om aan te sluiten op een Mega. Printjes maken (en dat kan gewoon met experimenteerprint) waar je modules in drukt (ESP's, port expanders maar ook liever een Nano / Pro Mini ipv een Uno/Mega) en dan connectoren maakt de boel al stuk netter. Ook kan je dan makkelijk het project in delen hakken om te ontwikkelen en om te testen.

En relais board wil je gewoon dicht bij je microcontroller hebben. De draden naar de kleppen kunnen lang zijn. Vergeet daar de blusdiode (indien DC of snubber indien AC) niet.

[AteGjalt]

Tom schreef op maandag 9 augustus 2021 @ 15:40:
Thanks. Vergeten om te vermelden dat het geen live-feed hoeft te zijn. Als ik er met een event een still (jpg) uit kan halen is dat voldoende.

Dan zou ik gewoon voor een ESP32-CAM gaan, genoeg voorbeelden beschikbaar op internet.
Zelf gebruik ik er ook één om elke 10min een foto naar een http server te sturen.

[Raven]

Kent iemand toevallig een >=16bit ADC met samplerate dat hoog genoeg is om een sinus van 50Hz te kunnen meten en dat een Arduino library heeft? Zit al even te zoeken, helaas zonder succes. Er zijn genoeg ADC's, maar een beetje rappe ADC (>=10ksps) met Arduino lib heb ik nog niet kunnen vinden.

[Atmoz]

Kan iemand mij uitleggen hoe (of nog beter: waarom* ) onderstaande code precies werkt?

code:

void breatheUpdate(const uint8_t * segment, const uint32_t increment, const uint8_t step, const uint8_t lowLimit)
{
  static uint32_t lastTimeChange = 0;
  static uint8_t direction = 1;
  static uint8_t value = lowLimit;
  if(millis() - lastTimeChange > increment)
  {
    value += (direction * step);
    if (value <= lowLimit || value >= 255)
    {
      direction = direction * -1;
    }
    for(uint8_t i = 0; i < sizeof(segment); i++)
    {
      strip.setPixelColor(segment[i], strip.Color(0, 0, value));
    }
    strip.show();
    lastTimeChange += increment;
  }
}

Boven setup() doe ik:

const uint8_t mySegment[] = {0,1,2,3};

In de main-loop roep ik dit aan als:

breatheUpdate(mySegment, 5, 1, 0);


Wat ik dus echt niet snap is hoe dit kan werken zonder dat er "ergens" (extern) buiten de functie zélf een variabele wordt gebruikt om de huidige "status" in op te slaan. Iets dat ik zelf wel altijd gebruik om vervolgens met behulp van millis() iets te doen.

Iemand die dit kan uitleggen?


*ik heb deze code ergens online gevonden en hij werkt perfect --> 4 LED's van een NeoPixel LED-strip faden hiermee netjes aan/uit


[edit]

Ik vraag dit overigens niet alleen uit interesse/nieuwsgierigheid, ik zou het ook graag weten om een probleempje op te lossen:

De aanroep in de main-loop werkt opzich heel goed, maar als ik tussendoor iets anders heb gedaan (servotje laten bewegen) dan knipperen de LED's eerst even heel snel (dus niet meer "breathend").

Dat vind ik niet mooi en zou ik graag willen oplossen. Dus daarom was ik opzoek naar die "externe" variabele om het "breathen" opnieuw te laten beginnen

De 2e vraag is dan eigenlijk ook: hoe kan het dat de LED's ineens heel snel gaan knipperen nadat de microprocessor even iets anders heeft gedaan? Het lijkt er net op alsof "er iets in te halen is" ofzo

[ Voor 21% gewijzigd door Atmoz op 28-10-2021 10:04 ]

[DataGhost]

Classic fout haha.
Om te beginnen, de staat wordt opgeslagen in de static variabelen. In het kort komt het erop neer dat de initiële toewijzing aan een static variabele slechts de eerste keer dat de functie wordt aangeroepen wordt gedaan en dat de variabelen zelf (binnen de scope van de functie) blijven bestaan. Dus de eerste aanroep is lastTimeChange 0, als deze in de functie veranderd wordt naar 5, zal deze in de volgende aanroep ook 5 zijn en niet op 0 gezet worden.

Nou naar het "classic" gedeelte. Op regel 6 wordt gekeken hoeveel tijd er verstreken is, en of dat meer is dan increment. Dus zegmaar tijdVerstreken = millis() - lastTimeChange. Als tijdVerstreken > increment dan moet er iets gaan gebeuren. Tot zover logisch. Alleen op regel 18 wordt iets gedaan waardoor de naam van lastTimeChange niet meer klopt. De laatste keer dat er iets veranderd is is namelijk op millis() en niet op lastTimeChange + increment. Als je dus je increment op 5ms hebt, en je CPU is 200ms met iets anders bezig, duurt het 40 calls voordat lastTimeChange weer bij is met millis(). Dus je functie wordt heel vaak heel snel achter elkaar uitgevoerd. De makkelijke fix is increment op regel 18 vervangen door millis(). Liefst doe je maar 1 aanroep naar millis() en sla je die op in een variabele trouwens, voor het geval deze tussen regel 6 en 18 verhoogt, maar die kans is in dit geval niet heel groot. Wat er dan gaat gebeuren is dat je breathe gewoon eventjes stilstaat terwijl je CPU bezig is, en daarna verder gaat waar 'ie mee bezig was. Als je dat wilt veranderen zal je de aansturing van je servo non-blocking moeten maken (net als deze breathe), en misschien ook de breathe-functie nog verder aanpassen zodat de snelheid afhangt van de precieze hoeveelheid verstreken tijd, anders zal deze alsnog marginaal langzamer gaan breathen als er veel servo-aansturing gedaan wordt.

[Atmoz]

DataGhost schreef op donderdag 28 oktober 2021 @ 10:44:

...uitgebreid + interessant verhaal...

Wow! Dat wist ik écht niet... *schaam schaam*

En thanks voor je uitgebreide en duidelijke antwoord
Weer wat geleerd vandaag!

Super bedankt

[SToRM666]

Even dit topic een beetje vanonder het stof halen. Ik heb recent ook een leuk project (bijna) afgewerkt, ik heb namelijk een shuffleton gebouwd.

Een korte uitleg van hoe het werkt. Je speelt met maximum 4 spelers over verschillende rondes. Elke beurt probeer je met 7 munten een zo hoog mogelijke score te gooien door in de gaten te gooien. Dit gaat door tot iemand een totaalscore van over de 6000 heeft. De huidige ronde wordt dan nog afgewerkt en de winnaar is dan degene met de hoogste totaalscore.

Je ziet 5 scoreschermpjes, degene in de hoeken zijn de totaalscores per speler en degene net onder het midden is de gegooide score in de huidige beurt voor een speler. De kleine scores zijn de gegooide gaten en bij een bonus (bovenste 3 gaten of de 2 buitenste) worden deze in het groen weergegeven

Het systeem van een munt betalen per speler heb ik vervangen door een knop met LED verlichting. En daarnaast heb ik dan nog een knop voorzien om naar de volgende speler te gaan. Ik heb als extra optie ook nog ingebouwd dat je kan bepalen tot welke score er gegooid moet worden (zit niet in het origineel).

Hij is nog niet helemaal af, maar hij werkt nu wel volledig! Het scorebord moet nog afgewerkt worden en ik zit er ook aan te denken om geluid toe te voegen (als ik de originele geluiden zou kunnen vinden zou dat super zijn).

Wat foto's :





Voor de gaten heb ik zelf een huls ontworpen en geprint waar een sensor in past:



En dit is zo ongeveer de laatste status:



Dat zwarte vlak is een stuk plexiglas dat ik wat donkerder gemaakt heb, zodat de scores nog af te lezen zijn. Uiteindelijk wil ik op die plek een groot plexiglas plaatsen met een "shuffleton" sticker erop en dan het plexiglas donkerder maken waar de scores zitten.

Het is echt een erg leuk spel om met een biertje erbij te spelen. Ik heb met de bouw van deze in ieder geval al enorm veel nieuwe dingen geleerd die ik in een nieuwe versie anders zou willen doen
Een originele Shuffleton kan je al niet meer nieuw kopen, maar je kan ze soms nog wel tweedehands vinden.

[ Voor 12% gewijzigd door SToRM666 op 17-11-2022 21:37 ]

[SToRM666]

Ik ben ondertussen weeral wat verder aan het ontwikkelen en ik heb nu een update klaar staan met een full-color P4 LED matrix van 32x64 pixels:



Ziet er behoorlijk goed uit en het is echt veeel gemakkelijker qua soldeerwerk en dergelijke

[theorganiser]

Ik heb hier al een tijd van alles liggen denk aan :
bijna alles is nog nieuw

1. Arduino Nano v3
2. Allerlei weerstandjes
3. ledlampjes, display
4. allerlei andere kleine accessoires ( zat ook in een starterpakket)

voor de liefhebber mag dit afgehaald worden in Naarden, of voor een 10tje wil ik het ook wel opsturen.
Stuur een prive berichtje bij interesse

Edit:
Opgehaald !

[ Voor 8% gewijzigd door theorganiser op 09-12-2022 11:50 ]

[lloullou]

Voor diensten en betaalde opdrachten hebben we vraag en aanbod, zie onder andere
categorie: Software development

[ Voor 78% gewijzigd door _ferry_ op 19-03-2023 14:41 ]

[barrymossel]

Ik ben bezig met een klein projectje om een virtuele (bluetooth) muis te laten bewegen op meerdere manier op basis van MQTT.

Momenteel is de loop:

Arduino:

void loop() {
  if (command == 1) {
    Serial.println("Ik doe helemaal niks");
    delay(1000);
  } else if (command == 2) {
    Serial.println("Move mouse pointer up");
    Mouse.move(0,-1);
    delay(1000);
    Serial.println("Move mouse pointer right");
    Mouse.move(1,0);
    delay(1000);
    Serial.println("Move mouse pointer down");
    Mouse.move(0,1);
    delay(1000);
    Serial.println("Move mouse pointer left");
    Mouse.move(-1,0);
    delay(1000);
  } else if (command == 3) {
    int distance = random(10, 600);
    int x = random(3) - 1;
    int y = random(3) - 1;
    for (int i = 0; i < distance; i++) {
    
    Mouse.move(x, y, 0);
    delay(move_interval);

  }
  
  if (random(0,7) == 3 )
        Mouse.click(MOUSE_RIGHT);
  
  delay(loop_interval);
  }

  mqttClient.loop();
}

Die delays blokkeren de loop en dat is niet wenselijk. Dit kan ik voorkomen door het gebruik van millis, maar hoe doe ik dit dan bij mijn "command==2"? Dus met:

Arduino:

    Serial.println("Move mouse pointer up");
    Mouse.move(0,-1);
    delay(1000);
    Serial.println("Move mouse pointer right");
    Mouse.move(1,0);
    delay(1000);
    Serial.println("Move mouse pointer down");
    Mouse.move(0,1);
    delay(1000);
    Serial.println("Move mouse pointer left");
    Mouse.move(-1,0);
    delay(1000);

[DataGhost]

Eigenlijk op dezelfde manier maar dan moet je ook de huidige state bijhouden, die je na elke sub-actie verandert dus.

[SToRM666]

SToRM666 schreef op woensdag 7 december 2022 @ 21:52:
Ik ben ondertussen weeral wat verder aan het ontwikkelen en ik heb nu een update klaar staan met een full-color P4 LED matrix van 32x64 pixels:

[Afbeelding] [Afbeelding]

Ziet er behoorlijk goed uit en het is echt veeel gemakkelijker qua soldeerwerk en dergelijke

Met dit type scherm heb ik nu net mijn laatste versie van mijn darts scorebord gemaakt (met de stem van Russ Bray):



Deze stuur je dus via rf aan met het losse toetsenbord, maar die ga ik nog wat herwerken😊
Er zijn al losse accu’s onderweg en ik ga de toetsen zelf en de onderlinge afstand nog wat aanpassen. Het zijn cherry mx blue toetsen, dus dat typt wel vrij goed.

[ Voor 7% gewijzigd door SToRM666 op 24-01-2024 09:08 ]

[breinonline]

Vraagje. Ik probeer een serie leds te starten op basis van een tijdslijn. Sommige in een keer, sommige via een fade en 2 die moeten knipperen in een bepaald ritme. Die laatste werkt prima als losse functie (dus alleen knipperen uploaden naar de arduino) maar in de totale tijdslijn gaat de led op pin 8 zwakker mee in het ritme. Kan iemand mij verklaren waar dat hem in zit?

C++:

// =============== Voyager LED sequence =============== //
// Note: Total duration per fade: (miliseconds) = maxPWM / fadeIncrement * fadeInterval

// =============== Configuration =============== //
// Configuration strobes
const int pin_Strobe[] = {7, 8, 8, 7};                                      // Strobe LED pins are triggered in this sequence after the period in array_Strobe has passed
unsigned long array_Strobe[] = {3250, 50, 150, 50};                         // Array {OFF, ON, etc.}. How in setup the leds are initalized determines the first state (LOW = off, HIGH = on)
const byte interval_Strobe = sizeof(array_Strobe) / sizeof(unsigned long);  // Tracker for how many intervals have past
byte civ_Strobe = 0;                                                        // Current Interval Value counter
unsigned long pmillis_Strobe = 0;                                           // Millis start value

// Configuration fade: all arrays are only nessessary for fading leds. But they are all filled so a pwm led can be on each position in the sequence.
// Lights(indexnrs): Cabin(0), Navigation(1), strobes(2), Deflector(3), Impulse(4), Nacelles(5), Floodlight(6), Torpedo(7) 
//                              { 0,    1,    2,   *3,   *4,   *5,   *6,    7     }  // Array index number (* = PWM function in use)
const int LED[8] =              { 6,    12,   7,    11,   10,   9,    3,    5     }; // Pin nrs
const int maxPWM[8] =           { 255,  255,  255,  255,  255,  255,  255,  255   }; // Max brightness
const int Time[8] =             { 1000, 1000, 4000, 5500, 7000, 8500, 10500,10500 }; // Start time for led to go on (counted from time = 0)
int fadeValue[8] =              { 0,    0,    0,    0,    0,    0,    0,    0     }; // Start fade higher then 0 (from start timeline)
int fadeInterval[8] =           { 50,   50,   50,   50,   50,   50,   50,   50    }; // How fast to increment?
byte fadeIncrement[8] =         { 5,    5,    5,    2,    3,    3,    3,    5     }; // How smooth to fade? Lower = smoother.
unsigned long pmillis_Fade[8] = { 0,    0,    0,    0,    0,    0,    0,    0     }; // millis() timing Variable for fading
unsigned long pmillis_Seq = 0;                                                       // millis() timing Variable for startsequence
byte fadeDirection = 0;                                                              // Variable for fade Direction (0 = up, 1 = down)

// =============== SETUP =============== //
void setup()
{
  for (int y=0; y < 8; y++) {            // Look up all led pins in array,
    pinMode(LED[y], OUTPUT); }             // and set all LED's in the array to output
  digitalWrite(8, LOW);                  // Write initial state of strobe light 1
  digitalWrite(LED[2], LOW);             // Write initial state of strobe light 2
  for (int x=3; x < 7; x++) {            // Look up all PWM led pins in array (only possible if next to each other in the array),
    analogWrite(LED[x], fadeValue[x]); }   // and write initial state of fade leds
}

// =============== FUNCTIONS =============== //
void Strobe(unsigned long now) {                                                    // Strobes function
  if (now - pmillis_Strobe >= array_Strobe[civ_Strobe]) {                           // If the time interval has elapsed,
     civ_Strobe = civ_Strobe + 1;                                                     // select the next interval in the list,
        if (civ_Strobe >= interval_Strobe) {                                            // if all intervals in array have been past,
           civ_Strobe = 0; }                                                            // reset the array to start,
    digitalWrite(pin_Strobe[civ_Strobe], not digitalRead(pin_Strobe[civ_Strobe]));    // change state of the LED each next interval step,
    pmillis_Strobe = now; }                                                           // save the time of change
}

void Fade(unsigned long now, int x) {                          // Fade function
   if (now - pmillis_Fade[x] >= fadeInterval[x]) {             // If the time interval has elapsed,
      fadeValue[x] = fadeValue[x] + fadeIncrement[x];            // select the next interval in the list,
         if (fadeValue[x] >= maxPWM[x]) {                          // if all intervals have been past,
            fadeValue[x] = maxPWM[x]; }                            // end fade and keep it max,
      analogWrite(LED[x], fadeValue[x]);                         // write brightness to led,
      pmillis_Fade[x] = now; }                                   // save the time of change.
}

// =============== LOOP =============== //
void loop()
{
  unsigned long now = millis(); // Get current value of millisecond counter for functions

// Start startsequence
 for (int y=0; y < 8; y++) {                  // For each index in the array
    if (now - pmillis_Seq > Time[y]) {          // If time in array has past (counted from start timeline), 
       if ( y==3 || y==4 || y==5 || y==6 ) {      // if index is a pwm led,
          Fade(now, y); }                         // call fade function with current millis
       else if ( y == 2 ) {                     // Else if index is the strobes,
          Strobe(now); }                          // call the strobes function
       else {                                   // If not pwm led of strobe,
          digitalWrite(LED[y], HIGH);}            // just switch on led
    }
 }
  Strobe(now);                                // Update strobes

}

[Septillion]

@breinonline Voor pin 8 zet je nooit de pinMode.

Waarom is überhaupt pin_Strobe een losse array? Of andersom, waarom niet een array per functie? Nu heb je dus veel variabelen in arrays die je nooit gebruikt.

Daarnaast, de indentatie en brackets zijn wel een beeeetje all over the place...

[breinonline]

Septillion schreef op zondag 23 juni 2024 @ 14:06:
@breinonline Voor pin 8 zet je nooit de pinMode.

Dat was hem! Dank

Waarom is überhaupt pin_Strobe een losse array? Of andersom, waarom niet een array per functie? Nu heb je dus veel variabelen in arrays die je nooit gebruikt.

Daarnaast, de indentatie en brackets zijn wel een beeeetje all over the place...

Dank voor de opbouwende kritiek. Het is mijn eerste project in C++...
De strobes wil ik 200ms na elkaar hebben. Dat is te doen met twee losse functies (dat had ik eerst). Ik wil nog combineren met een dubbele schakelaar dat de lichten een voor een starten (deze code) en de andere schakeloptie alles maar zonder de strobes. Alle pogingen daartoe leiden er steeds toe dat de strobes toch vaak out-of-sync gaan lopen.
Om dat te voorkomen heb ik ze juist samengevoegd. Maar dan moet de ene keer naar de ene pin geschreven worden (2x: aan en uit) en dan naar de andere. Dat bereik ik met deze array. Maar als dat handiger kan dan hoor ik het graag.

[Raven]

Is er iemand toevallig bekend met de ESP-201?



Aangesloten zoals ^, maar Arduino IDE krijgt geen verbinding, al zie ik tijdens het connecting de blauwe LED wel knipperen, maar verder niets. Eindigt met "A fatal esptool.py error occurred: Failed to connect to ESP8266: Timed out waiting for packet header"

GPIO0 hangt uiteraard aan de ground tijdens het flashen.

[Septillion]

@Raven Je zegt, GPIO0 hangt aan GND, maar reset je hem daarna ook wel?

[Raven]

@Septillion Jup, zowel resetknop geprobeerd als de 3.3V lijn erachter weg.

[Septillion]

@Raven Je USB Serial doet op de datalijnen ook netjes 3v3?

En Rx en Tx zitten goed? Eventueel keer omdraaien voor als de labels toch voor de counter part bleken.

En als het op een breadboard is, alle verbindingen triple checken.

[Raven]

@Septillion Check, sterker nog, deze FTDI-kabel is berucht Het is die van Sparkfun die door een communicatiefout wel 3.3V datalijnen heeft, maar 5V op de VCC draad heeft

Originally, the cable was designed to have 3.3V VCC, however something was lost in translation between SparkFun and our supplier and we got stuck with a whole bunch of FTDI cables that have a slight mix up in wiring. These have 5V VCC, and 3.3V I/O. The 5V Vcc output shouldn't be a problem unless this cable is being used to power a sensitive circuit such as a sensor.

uiteraard AMS1117 eraan voor 3.3V.

Rx/Tx meerdere keren gechecked en als ik ze omdraai (verkeerd plaats) dan licht de blauwe LED niet op bij activiteit.

Inderdaad breadboard, alles gecheckt. Enige wat ik nog kan doen is een andere ESP-201 (heb er 2) erop drukken, alleen moet ik bij die de niet-breadboard vriendelijke UART-header eraf solderen en vervangen door een ge-angled versie. Die zit namelijk dezelfde richting op gesoldeerd als de headers aan de zijkanten

edit: Net ff 5V ergens anders weggehaald, voor het geval de FTDI-kabel niet genoeg kan leveren, maakte geen verschil.

[ Voor 5% gewijzigd door Raven op 05-10-2024 17:25 ]

[Septillion]

@Raven Dat is wel irritant van de headers ja. Überhaupt borden zonder auto-reset zijn irritant

Loopback test van de kabel lukt wel gewoon?

[Raven]

@Septillion Check, kabel is goed.

[Raven]

@Septillion Het ingebakken AP (AI-THINKER_CC4822) werkt overigens wel (mits boot normale modus), kan er verbinding mee maken, maar IP-adres in browser openen geeft connection refused.

[kitao]

Debugging not supported ...
Jammer want ik had graag wat register waardes in de codeflow willen zien bij een Arduino Assembly programma.
In Micro Chip Studio 7 blijkt dit wel mogelijk te zijn, na het maken van een New Project, via het veldje Arduino Projects.
Dit is me alleen gelukt met de oudere Arduino IDE-versie 1.8.19, met de meest recente versie 2.3.4 loopt het spaak (?)
Mogelijke oorzaak daarvan staat hier :
https://forum.microchip.c...5C3l000000MfQzEAK/t388636
Onderste post, verouderde zooi

Voor wie het ook wil proberen, of tips heeft over de gevolgde methode, kijk deze twee videos, die onderdeel zijn van playlists :

YouTube: Assembly via Arduino (part 1) - Introduction
YouTube: #56 Programming the Arduino Uno Using Atmel Studio 7

De tweede video is nodig om de Uno via Usb vanuit MCS7 te programmeren/uploaden.
Het assembly gedeelte heb ik handmatig kunnen toevoegen, dat betreft de eerste video.
Rechtsklik op het bestand en Add File (bij de rode pijl) :



Resultaat is dat een Arduino sketch in assembly geschreven kan worden en met MCS7 gedebugged en opgeladen kan worden op een bordje. Of in een simulator, zie mijn post in EL-kroeg.

[kitao]

Voorbeeldje overzetten van Assembly Arduino IDE naar Proteus Debugger :



YouTube: Assembly via Arduino (part 1) - Introduction

YouTube: Assembly via Arduino (part 5) - Programming LCD

Kuzechie legt uit dat de ino.file en de s.file dezelfde naam moeten hebben in de Arduino IDE.

In Proteus moet de main-file main.ino blijven heten.











Het is voor mij geen eitje gebleken om dit draaiend te krijgen met al die paths en project wizzards en dit is dan ook geen Instructable maar meer een globale wegwijzer naar de mogelijkheden.

============================= EDIT ================================

Hoewel het bovenstaande wel werkt met getoond LCD programma van Kuzechie lukt dat niet met een aantal anderen uit diezelfde serie.
Dat is op te lossen met op de gewone manier in Arduino IDE 2 de Kuzechie sketch te compilen en op te slaan, de Arduino IDE af te sluiten en dan vanuit Proteus die opgeslagen sketches handmatig met 'Add Existing File' toe te voegen en die nu dus wel dezelfde namen hebben.



En dit wordt dan de Proteus Wizard instelling :

[ Voor 32% gewijzigd door kitao op 20-12-2024 01:18 . Reden: Voortschrijdend inzicht ]

[kitao]

kitao schreef op zondag 15 december 2024 @ 14:14:
[Afbeelding]

Debugging not supported ...
Jammer want ik had graag wat register waardes in de codeflow willen zien bij een Arduino Assembly programma.
In Micro Chip Studio 7 blijkt dit wel mogelijk te zijn, na het maken van een New Project, via het veldje Arduino Projects.
Dit is me alleen gelukt met de oudere Arduino IDE-versie 1.8.19, met de meest recente versie 2.3.4 loopt het spaak (?)
Mogelijke oorzaak daarvan staat hier :
https://forum.microchip.c...5C3l000000MfQzEAK/t388636
Onderste post, verouderde zooi

Correctie : Inmiddels lukt het wel om Arduino IDE 2.3.4 op MCS7 te laten draaien.
Post wijzigen ging niet meer en ik wil geen software benadelen met bevindingen die achteraf niet helemaal kloppen, ook al weet ik niet waarom het nu wel werkt.

De Arduino sketchsjes met assembly zijn over te zetten naar zowel Proteus als naar MCS7.
Van die twee vind ik Proteus het fijnst om mee te oefenen.
Bij MCS7 kon ik niet uit een loop komen waarin Input werd gevraagd - van buitenaf, bijvoorbeeld een externe spanning op de ADC pinnen van de Arduino.
Step Out bleek niet te lukken bij MCS7 en bij Proteus wel.
Sowieso gaat daar het veranderen van input waardes makkelijker hoewel ik niet beweer dat dat bij MCS7 niet kan maar ik vermoed dat je dan een MCU erop aangesloten moet hebben met een MicroChip programmer ofzo. Of een speciaal bestandje :

Stimulus is the simulation of hardware signals/data into the device.
https://onlinedocs.microc...33-AC8D-4348B11BB2DB.html

Hieronder een voorbeeldje van een loop waar ik met Proteus wel kan Step Outen.



Dus al met al is mijn projectje om Arduino met assembly code, oftewel AVR Assembly, op zowel MCS7 als Proteus te debuggen en te simuleren best aardig gelukt

https://ww1.microchip.com...et-Manual-DS40002198A.pdf

Correctie 2 :

Register waarden kunnen eenvoudig handmatig gewijzigd worden. Dus een externe Stimulus is (in dit geval) niet nodig.
Het gaat bijvoorbeeld om onderstaande loop waar een ADCSAR-flag getest wordt of die op 1 staat.
Die blijkt handmatig ingevoerd te kunnen worden :

[ Voor 13% gewijzigd door kitao op 24-12-2024 15:31 . Reden: Voortschrijdend inzicht ]

[kitao]

kitao schreef op zondag 15 december 2024 @ 14:14:
[Afbeelding]

Debugging not supported ...
Jammer want ik had graag wat register waardes in de codeflow willen zien bij een Arduino Assembly programma.

Correctie 3 :
Het blijkt dus wel mogelijk te zijn om te debuggen in IDE2 als je maar het juiste boardje aansluit. Genoemd wordt bijvoorbeeld de Zero met onboard debug chip.

https://docs.arduino.cc/s...utorials/ide-v2-debugger/

[Danielson]

Waren kopen jullie je Arduino Nano's? Ik bestel ze over het algemeen op AliExpress of Amazon, maar dit zijn allemaal "Fake CH340" chips.

Waar vind ik orginele?

[Raven]

@Danielson Adafruit of NL-dealer Kiwi?

[Dutchess_Nicole]

Danielson schreef op dinsdag 14 januari 2025 @ 08:44:
Waren kopen jullie je Arduino Nano's? Ik bestel ze over het algemeen op AliExpress of Amazon, maar dit zijn allemaal "Fake CH340" chips.

Waar vind ik orginele?

Kiwi electronics is mijn go-to voor dit soort spul. Tinytronics ook voor andere boards.

[Septillion]

Danielson schreef op dinsdag 14 januari 2025 @ 08:44:
Waren kopen jullie je Arduino Nano's? Ik bestel ze over het algemeen op AliExpress of Amazon, maar dit zijn allemaal "Fake CH340" chips.

Waar vind ik orginele?

Naar mijn idee bestaat er niet zoiets als "fake CH340" chips... Dat is namelijk al gewoon een goedkoop China design. Afgezien van mensen die misschien geen drivers installeren er nooit een issue mee gezien. En geef zelf dus juist de voorkeur aan de CH340 boven FTDI of Silicon Labs chips omdat daar juist wel veel fakes voor in omloop zijn. (Die overigens in de basis prima werken maar door de driver kreupel gemaakt worden )

[Accretion]

Is d'r geen Nano variant van de Leonardo?

De 32u4 vindt ik ook wel leuk, juist omdat deze geen afzonderlijke usb-serial chip nodig heeft.

Alhoewel, tegenwoordig gebruik ik toch voornamelijk ESP32 gebaseerde bordjes.

[kitao]

De micro zie ik staan en daaronder nog wat alternatieven :

The Micro is a microcontroller board based on the ATmega32U4 (datasheet), developed in conjunction with Adafruit. It has 20 digital input/output pins (of which 7 can be used as PWM outputs and 12 as analog inputs), a 16 MHz crystal oscillator, a micro USB connection, an ICSP header, and a reset button. It contains everything needed to support the microcontroller; simply connect it to a computer with a micro USB cable to get started. It has a form factor that enables it to be easily placed on a breadboard.

The Micro board is similar to the Arduino Leonardo in that the ATmega32U4 has built-in USB communication, eliminating the need for a secondary processor. This allows the Micro to appear to a connected computer as a mouse and keyboard, in addition to a virtual (CDC) serial / COM port.

https://store.arduino.cc/en-nl/products/arduino-micro

[kitao]

In het midden een Avr Isp bootloader shield.

https://www.bitsandparts....ISP%20Shield%20Manual.pdf

https://github.com/RalphBacon/Bootloader-Shield-8MHz

Om een bootloader up te loaden zet je het shield op de Uno en dan kan er een bootloader in de zif-chip worden geprogrammeerd. Toen ik het shield bestelde dacht en hoopte ik eigenlijk dat ik zo ook andere 'normale' sketches kon uploaden in de 328P zif-chip. Dat blijkt niet te gaan want in de ISP-blokjes, die in elkaar klikken, zitten dan de Reset aan Reset vast, oftewel PC6 van de programmeerder Uno zit dan verbonden met de PC6 van de ontvanger.



https://www.diymore.cc/pr...rammer-for-arduino-uno-r3

Vandaar dat ik het blauwe draadje met pin 10, SS, op de Uno heb verbonden.
Dan blijkt het wel mogelijk een sketch in de Zif-chip te flashen, dit is een paar keer getest met blink-variaties na verplaatsing van de aldus geprogrammeerde chip naar het breadboard ernaast.

Wat ik mij nu afvraag is hoe het kan dat er wel met ingeklikte shield een bootloader in de ontvangende chip kan worden geschoten maar niet op dezelfde manier een andere sketch ?
Want, zo heb ik begrepen, een bootloader 'is ook maar een sketch net als iedere andere' en komt in hetzelfde geheugenblok terecht net als iedere andere sketch.

Paar andere linkjes die in relatie staan tot dit onderwerp :

YouTube: #119 Bootloader Shield 🛡️ and 8Mhz Arduino Barebones (made easy)

https://docs.arduino.cc/b...-isp/ArduinoToBreadboard/

kitao in "De EL-kroeg - Deel 4"



======================== Edit ==================================

Na verder rommelen met dit ding en iets strikter navolgen van de handleiding blijkt het toch mogelijk te zijn om met ingeklikt shield een normale sketch in de zif 328P chip te schieten.

Dit is de handleiding
https://github.com/RalphBacon/Bootloader-Shield-8MHz
en er staat in 5.1 om een folder in Examples te plaatsen maar je kunt net zo goed deze Ino-file
https://github.com/RalphB.../master/OPENSMART_ISP.ino
in een lege sketch plakken en dan volgens de handleiding naar de Uno uploaden met MKII programmer geselecteerd.

Eenmaal geupload via Tools de Programmer terugzetten naar Arduino as ISP, zie handleiding 5.2 stap 4, en in plaats van 'burn bootloader' kun je in die stap en met 'Upload using Programmer' een normale sketch erin schieten, bijvoorbeeld een Blink.

Inmiddels ook erachter gekomen dat met ingeklikt shield de bootloader die erin zit uitgelezen kan worden mbv de Board_Detector sketch en via de Serial Port Monitor op 115200 baud.
Waarover hier meer :

kitao in "De EL-kroeg - Deel 4"

[ Voor 24% gewijzigd door kitao op 05-02-2025 18:01 . Reden: Github link toegevoegd ]

[kitao]

Logic Analyzer 8 CH, 24MHz USB

Daar gaat deze post in het kort over, voor wie er nog niet zo bekend mee is. Heb het zelf jaren niet gebruikt en het moest op een andere computer geinstalleerd worden met Windows 11 en ik heb van de stappen een paar snips gemaakt.

Produkt


Website voor de software




https://www.saleae.com/pages/downloads

Wizzard


Geinstalleerd en in actie - het betreft overigens wel een demo versie, dus metingen opslaan zal wel niet gaan.


Dit apparaatje kost ca. 14 euro, o.a. bij Bol en is handig bij het monitoren van digitale schakelingen.
Voor die prijs zijn het gekloonden, ook die ik heb, maar de officiele software van Saleae is er blijkbaar toch compatible mee. Hetgeen mij niet heel vanzelfsprekend lijkt en zover ik gezien heb niet aangegeven staat bij de verkoop informatie.

[ Voor 7% gewijzigd door kitao op 08-02-2025 18:36 ]

[kitao]

Het volgende gaat ook over Arduino software maar die is niet gratis.
Hier kunnen pakketten worden geselecteerd
https://www.labcenter.com/buy-vsm/
Er zit een gratis demo pakket bij maar ik zou eerst proberen of er daar een uno mee geblinkt kan worden.
Op basis van deze video
YouTube: Assembly via Arduino - Programming DS1307 RTC
met deze code
https://akuzechie.blogspo...a-arduino-ds1307-rtc.html
een RTC Max7219 geprobeerd op te bouwen maar dat werkte niet goed met het aangetaste printje wat ik nog ergens had liggen

In zulke gevallen of als ik een onderdeel mis komt een simulator van pas.
Simulide is wel gratis en vind ik persoonlijk zelfs leuker als Proteus
https://simulide.com/p/
maar is beperkter met de beschikbare onderdelen.
Toch kan je daar best veel mee, het heeft ook een RTC en een Max7219 maar die is gekoppeld aan een matrix

Op Proteus lukte het uiteindelijk om de sketch, dat overigens in assembly is geschreven, in beeld te krijgen, met een common cathode display.

Het is wel een stuk lastiger om de project instellingen, libraries, compiler paths, files toevoegen etc om die bij Proteus goed te krijgen maar uiteindelijk is er wel meer mee mogelijk als met Simulide.

Ps, zie svp
kitao in "arduino uren en minuten verstellen"
De Sda en Scl 10K weerstanden zouden pull ups moeten zijn.
.

[ Voor 3% gewijzigd door kitao op 23-02-2025 16:24 ]

[kitao]

Dit gaat over RFID RC522 die ik nog ergens had liggen en een toepassing voor heb gezocht. Eerst naar een Uno standaardvoorbeeld gekeken
https://arduinogetstarted.com/tutorials/arduino-rfid-nfc

Dat is een goed artikel en introduceert ook Logic Level Shifters maar ik wou dit overzetten naar een Atm32.
Om die te programmeren gebruik ik Atmel Studio en de zoekcombinatie Atm32 + RC522 leverde dit op:

https://medium.com/@riyay...rocontroller-31c32df78861

Dat verwijst naar diverse goeie sites maar ook naar Git waar het hele project is gecodeerd
https://github.com/Riya00...-Using-Atmega32/tree/main

Klik de groene <>Code knop en download de Zip.
Dan vanuit Atmel Studio in Solution Explorer klik op Add Existing Items



En voeg de 4 files die Zip- gedownload waren toe



Dit compileerde in 1 keer maar helaas de Rfid opstelling werkte niet
In main.c staat het volgende :

C:

[i]int main()
{
    DDRB |= (1<<rs)|(1<<en)|(1<<buzzer);
    DDRC &= ~((1<<pin0)|(1<<pin1)|(1<<pin2)|(1<<pin3));
    PORTB |= (1<<buzzer);[/i]

Verander de DDRC in :

DDRC |= (1<<pin0)|(1<<pin1)|(1<<pin2)|(1<<pin3);

DDRC staat voor Data Direction Register C en met het &= ~( wordt daar een Input van gemaakt hetgeen naar mijn idee niet klopt als je vanuit Port C een LCD van data wil voorzien.


https://microcontrollersl...facing-examples-features/

Verbindingen:
RC522 : Vcc op 3.3V , TX naar RX ATM32, RX naar TX Atm32.
Atm32 : PB0 naar RS LCD, PB1 naar EN LCD, PC7-4 naar D7-4 LCD, PB2 aan een Buzzer of Ledje, Kristal 8MHz.
LCD : RW aan GND leggen.



Dit is allemaal best omslachtig want hetzelfde kan veel makkelijker en sneller worden bereikt met de Arduino IDE en bijvoorbeeld een Uno of Nano. Het op deze manier programmeren geeft wel iets meer uitdaging en is net een een graadje lastiger als de standaard methode.
De Arduino IDE heb ik in het begin gebruikt voor het testen van de componenten maar het voordeel van Atmel/Microchip Studio is dat het meer mogelijkheden tot debuggen biedt.

[ Voor 7% gewijzigd door kitao op 13-04-2025 18:17 ]

[kitao]

Hi, misschien dat iemand hier wat meer kan vertellen over een level-shifter en Uno R3 voltages ?

Ik gebruik de Uno o.a. om signalen naar een Altera Max II te sturen maar die draait op 3.3V. De gebruikte signalen zijn voor een 3x8-decoder volgens deze webpagina:
https://www.engineersgara...d-8x3-encoder-using-vhdl/

Gecompileerd in Quartus verscheen na wat instellingen dit plaatje op Modelsim:



De sim werkt dus naar behoren en de volgende stap was om dit op breadboard te zetten met in de Uno een aangepaste versie van dit programma : https://projecthub.arduin...led-binary-counter-defdd9



Op de foto is het goed aangesloten maar dat was eerst niet zo, ik had namelijk totaal niet verwacht dat er onder en boven VCC en GND op de level-shifter zouden zitten dus had VCC rechtstreeks op pin 3 staan



Iemand enig idee waarom dit dubbel is uitgevoerd ?
Met dit soort bordjes wordt op de cent winst gemaakt dus lijkt mij nogal overbodig?

En is er een manier om in de getoonde opstelling de level shifter er tussen uit te halen ? Dat er rechtstreeks 3.3 V uit de gebruikte pinnen van de Uno komt ?

Ps, deze is ook handig voor dit soort dingen


.
Ps2, als mogelijk antwoord op mijn eigen vraag, de dubbele uitvoering van VCC en GND is waarschijnlijk om twee of meerdere Logic Level Shifter Bi-Directional 5V/3.3V Modules te 'daisy chainen', aan elkaar door te lussen.
.

[ Voor 13% gewijzigd door kitao op 18-06-2025 10:27 ]

[Septillion]

kitao schreef op woensdag 18 juni 2025 @ 07:28:
Iemand enig idee waarom dit dubbel is uitgevoerd ?
Met dit soort bordjes wordt op de cent winst gemaakt dus lijkt mij nogal overbodig?

Denk voor gemak voor daisy chain inderdaad. Want hoe zeer ze ook proberen te bespraken is de grootste besparing vaak dat ze het niet zelf bedacht hebben

En is er een manier om in de getoonde opstelling de level shifter er tussen uit te halen ? Dat er rechtstreeks 3.3 V uit de gebruikte pinnen van de Uno komt ?

Direct, nee. Simpele spanningsdeler zou ook voldoen.

[kitao]

@Septillion
Ja bedankt voor de tip van een spanningsdeler, zoiets als dit denk ik dan aan


https://arduinokitproject...uetooth-arduino-tutorial/

Kort na mijn vorige post in dit topic over een Uno gekoppeld aan een CPLD kwam ik toevallig iets soortgelijks tegen, zie
kitao in "Het grote 'breadbord computer' topic"


https://eecs.blog/8-bit-computer-in-an-fpga/#more-detail

en daar staan 3 level shifters op met iets van 24 x 2 lijnen totaal
Op zich is dat al een zooitje maar met op iedere lijn een spanningsdeler met weerstanden zal nog meer een warboel worden vrees ik.
Niet dat ik al zeker weet dit project uit te gaan voeren maar een beginnetje is gemaakt en het kan ook per module opgezet worden waarschijnlijk. Nu schijnt het wel mogelijk te zijn om een Arduino Uno te 'hacken' dat er 3.3V uit de I/O komt, zie
https://learn.adafruit.co...echniques/3-3v-conversion
maar dat is nogal een drastische vrijwel onomkeerbare botte mes ingreep.

Toch heb ik het in een andere vorm geprobeerd en dat gaat inderdaad



Atmega 328P stand-alone geprogrammeerd met Arduino IDE via een FTDI FT232RL USB en vervolgens op 3.3V labvoeding aangesloten waardoor er 3.3V Out op de Led-pin ontstaat.

En er zullen ook andere Arduino borden zijn die standaard op 3.3V draaien maar makkelijkste is als ik er vertrouwd mee ben en ook dat er in de gebruikte sketches niet van pin positie gewisseld hoeft te worden met dat project
https://github.com/EECSB/8Bit-Computer
en dan lijkt mij dit een geschikte kandidaat :
If you used Arduino Nano in your projects in the past, the Nano 33 BLE is a pin-equivalent substitute. Your code will still work, but remember, it operates at 3.3V.
https://store.arduino.cc/products/arduino-nano-33-ble
.

[ Voor 5% gewijzigd door kitao op 23-06-2025 05:35 . Reden: typo ]

[Septillion]

@kitao De ATmega328P kan inderdaad prima op 3v3 werken en dan komt er ook 3v3 uit de IO. Maar officieel is de standaard 20MHz buiten spec om hem op 3v3 te laten werken. Dan zal je het crystal moeten vervangen voor een (uit mijn hoofd) 16MHz exemplaar.

[kitao]

@Septillion

Ja, tnx, dat is inderdaad iets om rekening mee te houden



https://ww1.microchip.com...-ATmega328P_Datasheet.pdf

en iets scherper kijkend zie ik nu dat genoemde 3.3 V Nano helemaal geen Atmega Nano is
The Arduino Nano 33 BLE is based on the nRF52840 microcontroller
https://store.arduino.cc/products/arduino-nano-33-ble

[vanaalten]

OK, misschien ben ik hier helemaal verkeerd, maar je moet toch ergens beginnen:
Ik heb een klein hobbyproject in gedachten. Ben over het algemeen niet zo bezig met elektronica, programmeren en zo, maar wat ik graag zou willen:

• Functie: IR-commando ontvangen van een Logitech Harmony remote en dan een Wake-on-Lan via ethernet het netwerk opsturen.
• Het nog-te-maken device staat 24/7 aan, liefst dus low-power, zero-maintenance.
• Moet een ethernet-aansluiting hebben (duh...) en, om adapter uit te sparen, Power-over-Ethernet gevoed zijn. Natuurlijk kan het functioneel ook prima draadloos werken, maar ik wil dingen bij voorkeur bedraad.
• Op de een of andere manier dus een IR-ontvanger hebben.

Na wat google, rondzoeken enzo kwam ik uit op een Arduino Leonardo ETH2 met PoE. Ik ben wel gecharmeerd van Arduino als concept, heb ik een heeeeel ver verleden wel eens iets met Arduino gedaan dus dit leek mij wel een goede basis.

Echter: dit bord blijkt End-of-Life, dus zal lastig aan te komen zijn. Wat zijn dan mijn alternatieven?
Arduino Uno + Arduino Ethernet Shield 2 + Ag9000-S PoE module?

Of zijn er beter, desnoods niet-Arduino, keuzes te maken?

[_ferry_]

De Arduino code kun je doorgaans ook op een ESP32 draaien, en er zijn wel wat bordjes met een ESP+LAN+PoE te vinden denk ik zo, dat is inderdaad beter dan die laatstgenoemde optie. Ook heb je dan volgens mij een makkelijkere implementatie qua ethernet interface dan met zo'n shield.

Edit, dat laatste is niet zo'n issue bij het ethernet shield. Maar wel bij de shield met ENC... Chippies er op.

Anyway, voor de prijs van een shield heb je een ESP bordje wat alles al aan boord heeft, behalve de IR ontvanger dan

[ Voor 29% gewijzigd door _ferry_ op 13-12-2025 20:28 ]

[Raven]

_ferry_ schreef op zaterdag 13 december 2025 @ 20:07:
De Arduino code kun je doorgaans ook op een ESP32 draaien, en er zijn wel wat bordjes met een ESP+LAN+PoE te vinden denk ik zo,

https://www.olimex.com/Pr...-ISO/open-source-hardware

[_ferry_]

Raven schreef op zondag 14 december 2025 @ 09:33:
[...]

https://www.olimex.com/Pr...-ISO/open-source-hardware

Precies, of evt deze;
https://www.olimex.com/Pr...POE2/open-source-hardware
Of van een andere fabrikant;
https://www.tinytronics.n...s3-w5500-ethernet-met-poe

[ Voor 12% gewijzigd door _ferry_ op 14-12-2025 09:58 ]

[vanaalten]

Dank voor het meedenken! En dat zijn wel leuke kleinere oplossingen. Binnenkort even wat meer in verdiepen en dan hopelijk rond oud&nieuw wat hobbyen.

[kitao]

vanaalten schreef op zaterdag 13 december 2025 @ 15:31:
OK, misschien ben ik hier helemaal verkeerd, maar je moet toch ergens beginnen:
Ik heb een klein hobbyproject in gedachten. Ben over het algemeen niet zo bezig met elektronica, programmeren en zo, maar wat ik graag zou willen:

• Functie: IR-commando ontvangen van een Logitech Harmony remote en dan een Wake-on-Lan via ethernet het netwerk opsturen.
• Het nog-te-maken device staat 24/7 aan, liefst dus low-power, zero-maintenance.
• Moet een ethernet-aansluiting hebben (duh...) en, om adapter uit te sparen, Power-over-Ethernet gevoed zijn. Natuurlijk kan het functioneel ook prima draadloos werken, maar ik wil dingen bij voorkeur bedraad.
• Op de een of andere manier dus een IR-ontvanger hebben.

Na wat google, rondzoeken enzo kwam ik uit op een Arduino Leonardo ETH2 met PoE. Ik ben wel gecharmeerd van Arduino als concept, heb ik een heeeeel ver verleden wel eens iets met Arduino gedaan dus dit leek mij wel een goede basis.

Echter: dit bord blijkt End-of-Life, dus zal lastig aan te komen zijn. Wat zijn dan mijn alternatieven?
Arduino Uno + Arduino Ethernet Shield 2 + Ag9000-S PoE module?

Of zijn er beter, desnoods niet-Arduino, keuzes te maken?

In stappen opdelen is waarschijnlijk het meest effectief, te beginnen bij de IR-detectie. In het verleden eens in verdiept en toevallig vandaag een stukje ervan weer opgepakt, zie Hfdst.7 pag. 81
https://www.digikey.nl/ht...understanding-signals.pdf
Getoond wordt hoe een Sony IR-signaal gedetecteerd en ontcijferd kan worden. Welk protocol jouw afstandbediening gebruikt weet ik niet maar dat kan dus verschillen per fabrikant.
https://www.sbprojects.net/knowledge/ir/sirc.php


.

[vanaalten]

kitao schreef op zondag 14 december 2025 @ 17:18:
[...]


In stappen opdelen is waarschijnlijk het meest effectief, te beginnen bij de IR-detectie. In het verleden eens in verdiept en toevallig vandaag een stukje ervan weer opgepakt, zie Hfdst.7 pag. 81
https://www.digikey.nl/ht...understanding-signals.pdf
Getoond wordt hoe een Sony IR-signaal gedetecteerd en ontcijferd kan worden. Welk protocol jouw afstandbediening gebruikt weet ik niet maar dat kan dus verschillen per fabrikant.
https://www.sbprojects.net/knowledge/ir/sirc.php

[Afbeelding]
.

Ik ging er eigenlijk van uit dat een willekeurig microprocessor bord (Arduino of wat dan ook) met een standaard IR-ontvanger-IC al goed genoeg gaat zijn, dus had mij daar nog niet zo in verdiept.
Het gaat om een Logitech Harmony, dus in principe kan die van alles sturen. Maar dit stukje van de puzzel gaat denk ik wel het meeste tijd kosten.

Dank voor de link naar informatie!

[NewGuest]

Wellicht dat je van dit aardig oude project nog wat inspiratie kan op doen. https://www.picbasic.nl/rc5-rc6_transceiver.htm

[kitao]

@vanaalten
Persoonlijk ben ik nog geen uC of board tegengekomen dat standaard is voorzien van een IR-optie, maar goed, ik wist ook nog niet dat er via de ethernetkabel spanning geleverd kon worden. Ik zag wel in de vorige links een bluetooth-optie en met een app op je telefoon heb je dan, afhankelijk van jouw toepassing en wensen, waarschijnlijk geen IR-afstandsbediening meer nodig. De webpagina hieronder heb ik een tijdje geleden nog gedaan, dat ging best goed en aan het eind ervan staan nog enkele doorverwijzingen.
https://arduinokitproject...uetooth-arduino-tutorial/

Inmiddels wat nazoek gedaan via de Copiloot en om PoE mogelijk te maken zou een speciale switch of injector nodig zijn? ESP tot nu toe nooit gebruikt maar mogelijke Arduino alternatieven zijn o.a.
https://wiki.dfrobot.com/...OE_Mainboard_SKU__DFR0342
https://www.seeedstudio.c...oard-with-PoE-p-4822.html
https://docs.arduino.cc/r...o-ethernet-rev3-with-poe/
https://github.com/SuperHouse/EtherUno

Inderdaad staat er retired bij de arduino-ethernet-rev3-with-poe maar die zullen waarschijnlijk via bijvoorbeeld een Ali nog steeds goed verkrijgbaar blijken te zijn. Hieronder de DFRobot optie.


.

[vanaalten]

kitao schreef op maandag 15 december 2025 @ 07:49:
@vanaalten
Persoonlijk ben ik nog geen uC of board tegengekomen dat standaard is voorzien van een IR-optie, maar goed, ik wist ook nog niet dat er via de ethernetkabel spanning geleverd kon worden. Ik zag wel in de vorige links een bluetooth-optie en met een app op je telefoon heb je dan, afhankelijk van jouw toepassing en wensen, waarschijnlijk geen IR-afstandsbediening meer nodig. De webpagina hieronder heb ik een tijdje geleden nog gedaan, dat ging best goed en aan het eind ervan staan nog enkele doorverwijzingen.
https://arduinokitproject...uetooth-arduino-tutorial/

Ah, nee, zo modern ben ik niet.
Een IR-afstandbediening blijft nodig: TV en receiver zijn beiden nog uit de vorige eeuw en spreken geen moderne draadloze protocollen. Los daarvan lijkt een enkele afstandbediening die alle apparaten kan bedienen mij handiger dan een telefoon-app.

Oh, bedenk mij net dat ik de hele use-case van m'n project niet heb uitgelegd, want leek mij niet zo noodzakelijk:
Ik heb onlangs een mediaspeler-PC in elkaar gezet om een Intel NUC mediaspeler te vervangen. Echter: de NUC kan je via infrarood aanzetten, dus daadwerkelijk vanuit de uit-stand aan. De nieuwe mediaspeler kan dat helaas niet. Bios opties geprobeerd, maar nee: uit is uit en dan moet je met de aan-knop op het apparaat 'm aan zetten. En ik kan wel sleep-mode als alternatief gebruiken, maar dat vind ik een beun-oplossing en niet leuk. Dus idee is om een Arduino - of, nu waarschijnlijker, een ESP32 - te gebruiken die een specifiek IR-commando omzet naar een wake-on-lan via ethernet en op die manier de mediaspeler aan zet.

Inmiddels wat nazoek gedaan via de Copiloot en om PoE mogelijk te maken zou een speciale switch of injector nodig zijn?

Check: mijn Unifi switches hebben een aantal poorten met PoE, dus die gebruik ik al om een paar apparaten via ethernet te voeden.

[_ferry_]

Andere optie er zijn IC's die je kunt inleren qua IR, en dat kan ook met een arduino.
Zie bijv. https://docs.arduino.cc/libraries/irremote/
Heb ze ooit gebruikt, en daarmee stuurde ik dan een uitgang van de mircrocontroller waarmee ik de powerknop verbond. Zo kon ik ook met de IR remote de PC aanzetten. Zonder LAN (voeden via de USB bijvoorbeeld) en een stuk minder hardware.

[ Voor 12% gewijzigd door _ferry_ op 15-12-2025 09:42 ]

[Septillion]

Voor ontvangen van IR signalen is het inderdaad het makkelijkste om een all in one te namen op de juiste frequentie, meestal 38kHz. Iets als een TL1838 of TSSP4038 ofzo. Dan rollen de bitjes er zo uit. En dan kan je gewoon een van de Arduino libraries gebruiken om er begrijpbare data van te maken.

[kitao]

Naar aanleiding van deze post: kitao in "De EL-kroeg - Deel 4"
en deze video: YouTube: Arduino UNO + 7-Segment LCD Display - Full Tutorial (How to use segm...

Voor wie interesse heeft in het aansturen van een Segmented Display.
De video verwijst naar een Github Ino sketch: https://github.com/upiir/arduino_7segment_lcd_display
De sketch is dus niet bedoeld voor een 7-segment display maar een Common Cathode 7-segment display op een breadboard kan er wel mee aangestuurd worden. De pin indeling voor een Uno is als volgt :

C#:

 pinMode(SEG_COM, OUTPUT); // set pin 2 as output
  pinMode(SEG_A, OUTPUT); // set pin 8 as output
  pinMode(SEG_B, OUTPUT); // set pin 9 as output  
  pinMode(SEG_C, OUTPUT); // set pin 5 as output  
  pinMode(SEG_D, OUTPUT); // set pin 4 as output  
  pinMode(SEG_E, OUTPUT); // set pin 3 as output  
  pinMode(SEG_F, OUTPUT); // set pin 7 as output  
  pinMode(SEG_G, OUTPUT); // set pin 10 as output  
  pinMode(SEG_DP, OUTPUT); // set pin 6 as output 

In het origineel kloppen de comments ernaast niet vandaar dat ik dit stukje code heb geplaatst. Voor de rest werkt de sketch prima en heb deze in Proteus met een Arduino Uno als microcontroller gesimuleerd. Alle Commons en alle Segments op 1 pinnetje gaat in het echt natuurlijk niet maar de simulatie accepteert het en het gehele display wordt zichtbaar:



Omdat een segmented display aangestuurd wordt met een AC-signaal maakt het volgens mij eigenlijk niet uit of je een CC of CA 7-segment display met diezelfde sketch aanstuurt. Op breadboard heb ik alleen de CC getest maar in een Simulide simulatie heb ik ze allebei erin gezet:



https://simulide.com/p/ Pin 2 heeft een periode van 20 ms en bij de CA had eigenlijk ook een weerstandsblokje moeten zitten.

Deze video van dezelfde autheur simuleert een transparant display met Wokwi, zie minuut 09:45

YouTube: Thank You for 100K - Here is Your Gift!



https://wokwi.com/
.

[ Voor 26% gewijzigd door kitao op 20-12-2025 12:13 . Reden: Plaatje toegevoegd ]

[Septillion]

@kitao Als je dat soort herhalende commentaar naast je code zet kan je beter geen commentaar gebruiken. Beste commentaar herhaal je jezelf niet in. Ofwel, geen variabele waardes etc noemen. Als je nu je variabele wijzigt wordt je alleen maar op het verkeerde been gezet door je commentaar.

[DjoeC]

@Septillion Ik gen een groot voorstander van uitgebreid commentaar ter plekke zolang dat de bedoeling van het statement blok weergeeft. Maar commentaar moet net zo goed worden bijgewerkt als de onderliggende code.

Aangenomen dat je verwijst naar het stukje segment<>pin vertaling zie ik niet iets herhalends of overbodig - als gezegd: mits onderhouden.

[Septillion]

@DjoeC Ik ben ook groot voorstander van commentaar. Maar als een regel code super duidelijk is hoeft die geen commentaar. Zeggen wat een regel doet is geen commentaar, je wilt uitleggen wat je wilt bereiken. Dus bijvoorbeeld "Pinnen voor 7-segment configureren".

En waardes van een variabele herhalen in je commentaar is naar mijn idee een doodzonde. Dan zou je net zo goed geen variabele kunnen gebruiken als je die toch gaat lopen herhalen. Goed commentaar hoef je dus ook niet aan te passen als je doel hetzelfde blijft maar je implementatie verandert.

[kitao]

Septillion schreef op zondag 21 december 2025 @ 10:15:
@kitao Als je dat soort herhalende commentaar naast je code zet kan je beter geen commentaar gebruiken. Beste commentaar herhaal je jezelf niet in. Ofwel, geen variabele waardes etc noemen. Als je nu je variabele wijzigt wordt je alleen maar op het verkeerde been gezet door je commentaar.

Bedankt voor de tip, ik snap wat je bedoelt
Zelf codeer ik niets maar probeer het wel enigzins te kunnen lezen en na deze sketch in Atmel Studio met een debug te hebben doorlopen wist ik zeker dat de code comments niet klopten.
Het volgende is uit het origineel:
https://github.com/upiir/...segmented_lcd_display.ino

C++:

#define SEG_COM 2
#define SEG_A 8
#define SEG_B 9
#define SEG_C 5
#define SEG_D 4
#define SEG_E 3
#define SEG_F 7
#define SEG_G 10
#define SEG_DP 6
[...]
void setup() {
  
  // set all the needed Arduino pins as outputs (7 pins for 7-segment display, 1 pin for decimal point, 1 pin for common electrode)
  pinMode(SEG_COM, OUTPUT); // set pin 2 as output
  pinMode(SEG_A, OUTPUT); // set pin 3 as output
  pinMode(SEG_B, OUTPUT); // set pin 4 as output  
  pinMode(SEG_C, OUTPUT); // set pin 5 as output  
  pinMode(SEG_D, OUTPUT); // set pin 6 as output  
  pinMode(SEG_E, OUTPUT); // set pin 7 as output  
  pinMode(SEG_F, OUTPUT); // set pin 8 as output  
  pinMode(SEG_G, OUTPUT); // set pin 9 as output  
  pinMode(SEG_DP, OUTPUT); // set pin 10 as output              
}

Ik heb van het void setup blokje de comments aangepast mocht iemand van plan zijn dit projectje met een 7-segment led display te willen gaan uitvoeren zodat er geen pinnetjes geroosterd gaan worden bij iemand met minder ervaring ermee. In dat opzicht ben ik op het gebied van LCD-displays zelf een beginner dus moet daar ook mee oppassen wil ik zoiets gaan aansluiten. Momenteel heb ik geen los exemplaar dus vandaar dat ik het even met een 7-seg led op breadboard uittestte.

Ik heb inmiddels wel zo ongeveer begrepen dat zo'n LCD werkt als condensator component dus dan in principe zou mijn Proteus simulatie ook in het echt zo opgesteld kunnen worden?
Als ik een simulatie meting verricht gaat er nauwelijk stroom door de leiding heen. Of meet ik verkeerd?



Het is dezelfde simulatie als in de vorige post met enkel een AC amperemeter erin gevoegd.
De periode van IO2 is 20 ms en de simulatie draait op diezelfde Github code van autheur Upir.
.

[DjoeC]

Septillion schreef op zondag 21 december 2025 @ 10:32:
@DjoeC Ik ben ook groot voorstander van commentaar. Maar als een regel code super duidelijk is hoeft die geen commentaar. Zeggen wat een regel doet is geen commentaar, je wilt uitleggen wat je wilt bereiken. Dus bijvoorbeeld "Pinnen voor 7-segment configureren".

En waardes van een variabele herhalen in je commentaar is naar mijn idee een doodzonde. Dan zou je net zo goed geen variabele kunnen gebruiken als je die toch gaat lopen herhalen. Goed commentaar hoef je dus ook niet aan te passen als je doel hetzelfde blijft maar je implementatie verandert.

Je hebt gelijk. En ik zie in de .ino dat de pinnummers al in de #DEFINE gekoppeld zijn. Dan is het "risico" op miscommunicatie in een later stadium door niet aangepast commentaar een heel stuk groter.

[kitao]

DjoeC schreef op zondag 21 december 2025 @ 10:26:
@Septillion Ik ben een groot voorstander van uitgebreid commentaar ter plekke zolang dat de bedoeling van het statement blok weergeeft. Maar commentaar moet net zo goed worden bijgewerkt als de onderliggende code.

Aangenomen dat je verwijst naar het stukje segment<>pin vertaling zie ik niet iets herhalends of overbodig - als gezegd: mits onderhouden.

Mits goed onderhouden is herhalend en goed gekozen commentaar erg nuttig, vooral voor gebruikers zoals ik die niet al te goed thuis zijn in het coderen. Maar zoals ik het begrepen heb is achteraf wijzigen van commentaar regels nogal een opgave als het IC's betreft met 80+ pinnen en vele honderden regels aan code in een programma. Op zich in deze besproken Ino-file hadden de comments beter meteen achter de Define's kunnen worden gezet want voor een niet-codeur is een regel zoals hieronder nogal vaag:

C++:

#define SEG_A 8

Want wat is pin 8?
Op een Atmega 328 is dat niet dezelfde pin als op een Uno. Pin 8 is namelijk Gnd
Met Pin 8 op de Uno zou dan overzichtelijker PortB0 kunnen worden genoemd ofzo met als voordeel dat het ook makkelijker naar bijvoorbeeld een Nano kan worden overgezet.

[DjoeC]

@kitao Ik snap je doel en de problemen. Hier is een stukje uit 1 van mijn .ino's waar - naar mijn idee - commentaar zowel nuttig is maar niet compleet onderhouden (850 vertraging ipv 900 uit het commentaar) Ik ben ook absoluut geen Arduino programmeur (wel in andere talen):

code:

void readDS18B20()
{
                                        // Get somewhat accurate time from router. 
  setup_UDP();
  gettime_UDP();
                                        // Start temp calculations on all sensors
  sensors1.requestTemperatures();
  sensors2.requestTemperatures();
                                        // 1 second later all calculations should be complete
                                        // @ highest (12 bit) resolution.  11 bit takes max 0.375 sec.
                                        // But why rush.....
//  delay(1000)
                                        // Made 900 ms to keep 60 sec turnaround per reading
  delay(850);
                                        // For debugging purposes: Print # sensors per port which we 
                                        // identified earlier.
  Serial.print("sensNum1 : ");                    
  Serial.println(sensNum1, DEC);                  
  Serial.print("sensNum2 : ");                    
  Serial.println(sensNum2, DEC);                  
                                        // Go get all temps per port
  Serial.println("==>getTemp1<==");
  for (i = 0; i < sensNum1; i++)
    {
    getTemp1(sensTab [i]);
    processTemp();
    }
                                        // Careful:  When using more than 2 ports this needs to be changed
                                        // together with some other things....
  Serial.println("==>getTemp2<==");
  for (i = sensNum1; i < sensNumTot; i++)
    {
    getTemp2(sensTab [i]);
    processTemp();
    } 
  Serial.println("==>ReadyTemps<==");
}

Code kwaliteit zal best iets op aan te merken zijn maar dit werkt voor mij om tientallen DS18B20 temperatuur sensoren in 1 keer uit te lezen

[Accretion]

DjoeC schreef op zondag 21 december 2025 @ 23:19:

code:

void readDS18B20()
{
                                        // Get somewhat accurate time from router. 
  setup_UDP();
  gettime_UDP();

"Get somewhat accurate time from router."
"gettime_UDP"

Dat soort commentaar heb ik een hekel aan.
Dat de 'getTime_UDP' tijd ophaalt via UDP heb ik niets aan.
Ik vraag mij af waarom je op dat punt tijd ophaalt, zeker gezien het niet naar een variabele geschreven wordt én daar verder niets mee gedaan wordt in dezelfde functie?

En daarnaast, wat is het verschil tussen getTemp1 en getTemp2?

Ik heb liever een block comment boven de functie die uitlegt wat de functie doet dan per regel.
Dat werkt ook beter met programma's die documentatie genereren.

Commentaar kan ook beter boven de regel staan dan ernaast, is makkelijker als je twee IDE windows naast elkaar hebt staan. Zo allemaal op een lijn proberen te krijgen is alleen maar onhandig als je een lijn toevoegt die weer langer is en je alles weer moet uitlijnen.

[kitao]

DjoeC schreef op zondag 21 december 2025 @ 23:19:
@kitao Ik snap je doel en de problemen. Hier is een stukje uit 1 van mijn .ino's waar - naar mijn idee - commentaar zowel nuttig is maar niet compleet onderhouden (850 vertraging ipv 900 uit het commentaar) Ik ben ook absoluut geen Arduino programmeur (wel in andere talen):

code:

void readDS18B20()
{
                                        // Get somewhat accurate time from router. 
  setup_UDP();
  gettime_UDP();
                                        // Start temp calculations on all sensors
  sensors1.requestTemperatures();
  sensors2.requestTemperatures();
                                        // 1 second later all calculations should be complete
                                        // @ highest (12 bit) resolution.  11 bit takes max 0.375 sec.
                                        // But why rush.....
//  delay(1000)
                                        // Made 900 ms to keep 60 sec turnaround per reading
  delay(850);
                                        // For debugging purposes: Print # sensors per port which we 
                                        // identified earlier.
  Serial.print("sensNum1 : ");                    
  Serial.println(sensNum1, DEC);                  
  Serial.print("sensNum2 : ");                    
  Serial.println(sensNum2, DEC);                  
                                        // Go get all temps per port
  Serial.println("==>getTemp1<==");
  for (i = 0; i < sensNum1; i++)
    {
    getTemp1(sensTab [i]);
    processTemp();
    }
                                        // Careful:  When using more than 2 ports this needs to be changed
                                        // together with some other things....
  Serial.println("==>getTemp2<==");
  for (i = sensNum1; i < sensNumTot; i++)
    {
    getTemp2(sensTab [i]);
    processTemp();
    } 
  Serial.println("==>ReadyTemps<==");
}

Code kwaliteit zal best iets op aan te merken zijn maar dit werkt voor mij om tientallen DS18B20 temperatuur sensoren in 1 keer uit te lezen

Dank je voor de toelichting en gezien het toch pittige commentaar van Accretion hierop zijn er denk ik een aantal voorwaarden te bedenken bij de keuze van stijl van de commentaar regels. Zoals: Is het commentaar voor iemand zelf die later de eigen code weer opduikelt of is het voor derden, al dan niet geoefend of beginnend? En sommige IDE's, zoals MPLab hebben een automatische tekstregel wrap optie, dwz dat er geen horizontale scrollbar nodig is en de code regels niet uit beeld verdwijnen en het zich aanpast aan de window breedte.

De Github pagina waar ik naar verwees
https://github.com/upiir/arduino_7segment_lcd_display
is voor de beginnende derden categorie dus het onjuist pin nummeren in zijn commentaar regels was nogal slordig van autheur Upir, die overigens wel een recent en zeer rijk Youtube Arduino Uno Display kanaal heeft:
https://www.youtube.com/@upir_upir/videos

Ik heb zelf wel eens geprobeerd te programmeren met o.a. Basic, PBasic, Assembly, C, C++ en Arduino Ide* maar ik ben ermee gestopt vanwege gebrek aan aanleg ervoor en liep vast naarmate het moeilijker werd (story of my life)
* Arduino uses C++ — but with a custom framework and build system on top.

Tegenwoordig ben ik ook een beetje bezig met Cpld's en Fpga's en dan worden er weer andere programmeertalen gebruikt zoals Verilog en Vhdl dus het wordt sowieso toch al teveel om dat te gaan leren en blijft het bij copy/pasten en af en toe wat aanpassen van een paar regeltjes.

Overigens ging mijn vraagje niet zozeer over het coderen maar over het aansturen van een segmented LC-display zoals opnieuw afgebeeld in dit plaatje:


klik

Alle 36 display pinnen zitten op 1 Uno pin, namelijk pin 2 oftwel PortD2 waarmee het gehele display in de simulatie zichtbaar wordt. Ik heb in diezelfde simulatie een AC amperemeter direkt na pin2 er tussen geplaatst, zie vorige post en die slaat nauwelijks uit dus nu vraag ik me af of deze opstelling ook in het echt zo zou werken?
Verstandig lijkt me dan wel om per keer 1 dipswitchje te activeren om eventueel een verhoogde aanloopstroom te voorkomen indien alle dipswitches geactiveerd zijn terwijl er spanning op wordt gezet. Kortom > opstarten met alle schakelaars op OFF.
Ik heb zo'n type LCD'tje besteld


40PIN TN Positive 4-Digits Segment LCD Panel White/Blue/Yellow Green Backlight Static Drive 5V Industrial Digital Display Screen

en dan probeer ik het met een stand alone Atmega328P chip die ik nog op breadboard heb staan met een amperemeter er tussen.
.

[ Voor 4% gewijzigd door kitao op 23-12-2025 04:08 . Reden: Plaatje toegevoegd ]

[DjoeC]

Accretion schreef op maandag 22 december 2025 @ 07:14:
[...]


"Get somewhat accurate time from router."
"gettime_UDP"

Dat soort commentaar heb ik een hekel aan.
Dat de 'getTime_UDP' tijd ophaalt via UDP heb ik niets aan.
Ik vraag mij af waarom je op dat punt tijd ophaalt, zeker gezien het niet naar een variabele geschreven wordt én daar verder niets mee gedaan wordt in dezelfde functie?

En daarnaast, wat is het verschil tussen getTemp1 en getTemp2?

Ik heb liever een block comment boven de functie die uitlegt wat de functie doet dan per regel.
Dat werkt ook beter met programma's die documentatie genereren.

Commentaar kan ook beter boven de regel staan dan ernaast, is makkelijker als je twee IDE windows naast elkaar hebt staan. Zo allemaal op een lijn proberen te krijgen is alleen maar onhandig als je een lijn toevoegt die weer langer is en je alles weer moet uitlijnen.

Ik gebruik vooral Global variabelen want dat werkt het beste voor mij. Dat je in de clip geen gebruik ziet zegt verder niets (nee, ik ga niet de hele .ino delen). Waarom daar? Ik haal die timestamp 1x op om in elke temperatuur observatie (loopje wat je niet ziet) aan de meting toe te voegen.

getTemp1 & getTemp2 zijn 2 instanties van een one-wire netwerk op 2 verschillende pin's, eerder in de sketch gedocumenteerd. De functie als zodanig stuurt 1 commando naar het one-wire netwerk en zegt: Alle DS18B20 op dit netwerk luister: "Bepaal de temperatuur op dit moment". Die wordt in een loopje na de delay (850ms) per sensor uitgelezen. Voordeel: ipv elke sensor individueel laten rekenen met 1 sensor per 375ms bij 11 bits volgens commentaar elders in de INO:

code:

                                        // Accuracy:  9 bit = 0.5    C, calc time =  93.75 ms  
                                        //           10 bit = 0.25   C,           = 187.5  ms
                                        //           11 bit = 0.125  C,           = 375    ms
                                        //           12 bit = 0.0625 C,           = 750    ms

wordt er nu in totaal 375ms gerekend. Dat scheelt bij de (maximaal) 60 sensoren in deze opzet 59*375ms. En dat maakt dat de ESP langer in deep-sleep gaat tussen metingen.

Enneh, programma's die zelf documentatie genereren houd ik dan weer niet van.... "In principe" dienen programma code zelf documenterend te zijn, als dat niet is heb je zut gemaakt. In mijn geval was dit mijn eerste Arduino poging na wat met examples (en dus ook met C (?) gekloot te hebben en had ik dus behoefte aan een beschrijving voor mijzelf:

code:

/*    WeMos D1 mini V2 with multiple sensors
      Version 2016-08-06
      Control via MQTT, debug Serial
      
      Hookup guide:
        - connect D0 to RST in order to wake op from deep sleep
        - DS18B20:
          + connect 5V (3.3V does not work properly with many sensors) to VDD pin of DS18B20 
          + connect G(round) to GND pin of DS18B20
          + Connect DS18B20 DQ data pin to D4, D5, ...
*/

Kan het beter? Natuurlijk! Is mijn manier DE manier? Natuurlijk niet. Maar deze methode - zeker met mijn vorm van programmeren en als je door de hele .ino heen loopt werkt voor mij. Het is (wordt) geen open-source, het draait inmiddels 9 jaar met in die 9 jaar minimaal onderhoud en heeft inmiddels zo'n 250.000.000 metingen geleverd aan de tegenhanger, een Python programma op een Raspberry dat mbv Grafana (toen ook allemaal nieuw voor mij) de boel verder verwerkte naar database, acties, alerts.

OK, beetje afgedwaald want het ging om wat zinvol commentaar is of niet. Meningen daarover verschillen dus en dat mag. We zijn het er over eens dat commentaar niet letterlijke beschrijving moet zijn van het statement en zeker niet in herhalingen hoort te vallen. Commentaar moet bijdragen aan het begrip van wat waarom moet gebeuren en commentaar moet onderhouden worden. Voor mij blijft meespelen dat de code eigenlijk door de keuze van variabele namen (kort of lang) en de bijbehorende documentatie alsook de structuur van het proggie begrijpelijk wordt. Nogmaals, er is niet 1 correcte methode.

En om je een idee te geven hoe dat werkt, ik ben opgeleid met VSP, Volmac Structured Programming. De commentaren hieronder, waar over VSP gemijmerd wordt, geven iets meer insight en zegt vast ook iets over mijn leeftijd

[vanaalten]

vanaalten schreef op zaterdag 13 december 2025 @ 15:31:
OK, misschien ben ik hier helemaal verkeerd, maar je moet toch ergens beginnen:
Ik heb een klein hobbyproject in gedachten. Ben over het algemeen niet zo bezig met elektronica, programmeren en zo, maar wat ik graag zou willen:

• Functie: IR-commando ontvangen van een Logitech Harmony remote en dan een Wake-on-Lan via ethernet het netwerk opsturen.
• Het nog-te-maken device staat 24/7 aan, liefst dus low-power, zero-maintenance.
• Moet een ethernet-aansluiting hebben (duh...) en, om adapter uit te sparen, Power-over-Ethernet gevoed zijn. Natuurlijk kan het functioneel ook prima draadloos werken, maar ik wil dingen bij voorkeur bedraad.
• Op de een of andere manier dus een IR-ontvanger hebben.

Na wat google, rondzoeken enzo kwam ik uit op een Arduino Leonardo ETH2 met PoE. Ik ben wel gecharmeerd van Arduino als concept, heb ik een heeeeel ver verleden wel eens iets met Arduino gedaan dus dit leek mij wel een goede basis.

Echter: dit bord blijkt End-of-Life, dus zal lastig aan te komen zijn. Wat zijn dan mijn alternatieven?
Arduino Uno + Arduino Ethernet Shield 2 + Ag9000-S PoE module?

Of zijn er beter, desnoods niet-Arduino, keuzes te maken?

Even afronding:
De tip van @_ferry_ was een hele bruikbare, ik heb uiteindelijk een Olimex ESP32-POE2 aangeschaft - met als doorslaggevend argument dat de fabrikant ook een mooie passende behuizing (BOX-ESP32-POE2) verkoopt. Inclusief verzending was ik zo'n 55 euro kwijt.
Een bruikbare infraroodontvanger had ik nog liggen (Vishay TSOP32238), evenals wat flatcable en een connector voor de UEXT poort. Dus simpelweg die TSOP32238 aan pinnen 1, 2 en 3 van de UEXT connector verbinden en de hardware was klaar.

Software: dat was wat puzzelen. Infrarood ontvangen kon met IRremote library die best goed gedocumenteerd was. Maar voor mij was het dan puzzelen als beginner of die (*Arduino*-IRremote) bruikbaar was voor ESP32, twijfels over of de pinnummer het GPIO nummer of fysieke IC pinnummer moest zijn. Als je dan ook de serial debugger baudrate op 115200 hebt gezet, maar aan de ontvanger kant nog op 9600 staat, dan verloopt het debuggen wat moeizaam.

Anyway, de afstandbediening die ik gebruik (voor een FLIRC receiver) wordt niet direct als protocol herkent, maar met 'raw code' kan je 'm toch bruikbaar ontvangen. Dus dat gedeelte was goed oplosbaar.

Ethernet was ook wat puzzelen. Het verbinden en IP-adres krijgen stelde weinig voor, met dank aan de goede voorbeelden van de fabrikant. Hoe een UDP pakketje voor WOL te verzenden was vooral trial&error. De AsyncUDP library bleek uiteindelijk bruikbaar, maar qua documentatie vond ik het wat karig (moet je nou connecten voor je wat kan sturen? En moet je vervolgens writeTo, sendTo of broadcastTo gebruiken?). Met behulp van tcpdump/wireshark pakketjes monitoren en vergelijken met een 'echt' wake-on-lan commando hielp mij hier wel bij.

Ofwel, uiteindelijke code:

code:

#ifndef ETH_PHY_TYPE
#define ETH_PHY_TYPE   ETH_PHY_LAN8720
#define ETH_PHY_ADDR   0
#define ETH_PHY_MDC   23
#define ETH_PHY_MDIO  18
#define ETH_PHY_POWER 12
#define ETH_CLK_MODE  ETH_CLOCK_GPIO0_OUT
#endif

#include <ETH.h>
#include <AsyncUDP.h>
#include "PinDefinitionsAndMore.h"
#include <IRremote.hpp>
#define IR_RECEIVE_PIN 4  // GPIO4

#define WOL_PORT 9
#define WOL_MAC 0xA0AD9F162A1F

static bool eth_connected = false;
unsigned char MagicPacket[102];
AsyncUDP udp;

void onEvent(arduino_event_id_t event) {
  switch (event) {
    case ARDUINO_EVENT_ETH_START:
      Serial.println("ETH Started");
      // The hostname must be set after the interface is started, but needs
      // to be set before DHCP, so set it from the event handler thread.
      ETH.setHostname("esp32-ethernet");
      break;
    case ARDUINO_EVENT_ETH_CONNECTED:
      Serial.println("ETH Connected");
      break;
    case ARDUINO_EVENT_ETH_GOT_IP:
      Serial.println("ETH Got IP");
      Serial.println(ETH);
      eth_connected = true;
      break;
    case ARDUINO_EVENT_ETH_LOST_IP:
      Serial.println("ETH Lost IP");
      eth_connected = false;
      break;
    case ARDUINO_EVENT_ETH_DISCONNECTED:
      Serial.println("ETH Disconnected");
      eth_connected = false;
      break;
    case ARDUINO_EVENT_ETH_STOP:
      Serial.println("ETH Stopped");
      eth_connected = false;
      break;
    default: break;
  }
}

void setup() {
  // Set-up serial debugger:
  Serial.begin(115200);

  // Set-up IR receiver:
  IrReceiver.begin(IR_RECEIVE_PIN);
  Serial.print(F("Ready to receive IR signals of protocols: "));
  printActiveIRProtocols(&Serial);
  Serial.println(F("at pin " STR(IR_RECEIVE_PIN)));

  // Set-up ethernet:
  Network.onEvent(onEvent);
  ETH.begin();

  // Build magic packet: 6 x 255, 16 x MAC address to wake:
  for (int i=0; i<6; i++)
    MagicPacket[i] = 255;
  for (int i=0; i<16; i++)
    for (int j=0; j<6; j++)
      MagicPacket[6 + j + (6*i)] = char((WOL_MAC>>(40-(8*j)))&255);

  Serial.print("Magic packet: ");
  for (int i=0; i<sizeof(MagicPacket); i++) Serial.print(MagicPacket[i], HEX);
  Serial.println();
}

void loop() {
  if (IrReceiver.decode()) {
    auto tDecodedRawData = IrReceiver.decodedIRData.decodedRawData; // uint32_t on 8 and 16 bit CPUs and uint64_t on 32 and 64 bit CPUs
    if (IrReceiver.decodedIRData.flags & IRDATA_FLAGS_IS_REPEAT) {
      Serial.println(F("Repeat received."));
    } else {
      Serial.print(F("Raw data received: 0x"));
      Serial.println(tDecodedRawData, HEX);
    }
    if (tDecodedRawData == 0x89D547CF) {
      Serial.println("Waking up remote machine");
      udp.writeTo(MagicPacket, sizeof(MagicPacket), ETH.broadcastIP(), WOL_PORT);
    }
    IrReceiver.resume();
  }
}

(en ja, er zal vast genoeg aan te verbeteren zijn - maar vooralsnog voldoet dit voor mij)

Dank nogmaals aan iedereen die mee dacht en mij deze richting op stuurde!

[kitao]

@vanaalten
Mooi dat je het in werking hebt gekregen, is geen makkelijk project als je aan zoiets van de grond af aan begint.
Met name dit hieronder, uit jouw link, gaat in het begin meestal wel goed bij mij:

Important notice: ESP32-POE2 has no galvanic isolation from Ethernet's power supply, this might be a problem for ground loops. This also means that when you program the board via the USB connector the Ethernet cable should be disconnected (if you have power over the Ethernet enabled)! Any board with own external power supply attached to ESP32-POE2 can be dangerous. Consider using Olimex USB-ISO to protect your computer and board from accidental short circuit (do not use external power for the USB-ISO!).

maar na een tijdje ben ik dat dan weer vergeten en flash ik zo de Usb van de laptop aan gort

Met wat rode tape probeer ik gekluns schade te voorkomen:


.

[kitao]

Gisteren een Uno Q 2GB uit het doosje gehaald


https://www.arduino.cc/en/uno-q/
datablad 37 pagina's: https://docs.arduino.cc/r...ts/ABX00162-datasheet.pdf

en niet om reclame te maken maar misschien van belang is dat die niet via Arduino maar via Digikey besteld is.
https://www.digikey.nl/en...arduino/ABX00162/27526619
Scheelt in kosten want het board is goedkoper en met gratis verzending boven de $60,- maar mogelijk dat het te lang op de plank heeft gelegen en de pre-installatie software of het image verouderd was?

Om de Q te kunnen gebruiken is er Arduino App Lab nodig en de 'normale' Arduino IDE.
https://docs.arduino.cc/software/app-lab/
Dus eenmaal App Lab geopend en board aangesloten verscheen de melding :
"Het systeem van het board is verouderd en adviseerde me om "Flasher Tool te installeren."
Op dat punt bleef App Lab steken dus er was geen andere keus als de Flasher Tool te installeren en daarmee een nieuw image op de MPU te flashen, volgens deze instructie:
https://docs.arduino.cc/tutorials/uno-q/update-image/
Vervolgens brak er een ca. 10 uur durende marathon aan met een CoPiloot die uiteindelijk tot de conclusie kwam dat er geen online Arduino Q OS beschikbaar is en heeft na die 10 uur een ticket gefabriceerd om te sturen naar klantenservice, waarvan hieronder een gedeelte daarvan, auto-vertaald vanuit Engels:

Toen ik voor het eerst de gloednieuwe UNO Q met Arduino App Lab verbond, meldde de software onmiddellijk dat het systeem van de board verouderd was en adviseerde me om "Flasher Tool te halen." Ik volgde deze prompt precies zoals aangegeven. Ik downloadde de Arduino Flasher CLI van de officiële Arduino-softwarepagina en gebruikte het zoals voorgeschreven.

Het flashen is succesvol voltooid, maar het hulpmiddel installeerde een Debian 13 (trixie) basisimage in plaats van het volledige Arduino UNO Q-besturingssysteem. Na het flashen start de board normaal op, maar de volgende problemen doen zich voor:
Het systeem meldt:
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
Het qboard-subsysteem ontbreekt:
dpkg -l | grep qboard geeft geen resultaten
De qboard-pakketten zijn niet beschikbaar in de repository:
apt search qboard geeft niets terug.
Het Arduino OS-meta‑pakket (arduino-unoq-os) kan niet worden geïnstalleerd
De LED-matrix en App Lab-integratie werken niet omdat de benodigde services niet aanwezig zijn
Na het bekijken van de documentatie van de tool ontdekte ik dat de Arduino Flasher CLI Debian-images flasht, niet het volledige Arduino UNO Q OS. Dit verklaart waarom het bord op een basisniveau van Linux functioneel werd, maar alle UNO Q-specifieke services zoals qboard en matrixsupport verloor.
etc.
*****************************************************

Board werkt wel met de standaard voorbeelden. Voor mij is het vrij nieuw zo'n combinatie tussen Mcu en Mpu maar mogelijk herkent iemand dit beter met mogelijk een tip hierover.



Arduino App Lab is designed specifically for the Arduino UNO Q board, which combines a microcontroller (MCU) and a microprocessor (MPU) running Linux. It allows you to build Apps that can include both C++ sketches for the MCU and Python scripts for the MPU, connected via the Bridge API. It also integrates Bricks — prebuilt modules such as AI models, web servers, or API connectors — that run in parallel with your Apps, often as Docker containers. App Lab supports multiple modes:
Desktop Mode (USB) for direct programming from PC.
Network Mode (Wi-Fi) for wireless development.
SBC Mode to use the UNO Q as a standalone computer.
.

[ Voor 10% gewijzigd door kitao op 25-01-2026 13:37 . Reden: link toegevoegd ]

[Accretion]

kitao schreef op zondag 25 januari 2026 @ 12:50:
Gisteren een Uno Q 2GB uit het doosje gehaald

Klinkt als niet de beste 'out of box experience'.

Wel goed dat ze naar STM gewisseld zijn, USB-C gebruiken en interessant dat ze een on-board QWIIC connector hebben.

"App lab" had ik ook nog niet gezien, die drag&drop mogelijkheid ziet er leuk uit om ook jeugd geïnteresseerd te krijgen in embedded spul.

De combinatie van MPU en MCU is interessant, maar vaak heb je maar een van beide nodig, dus denk niet dat ik snel een Q ga bestellen.

[kitao]

@Accretion

Klinkt als niet de beste 'out of box experience'.

Nee niet echt maar het Q-board is momenteel voor een groot deel functioneel en zonder de specifieke testjes van de Copiloot had ik waarschijnlijk nog niet eens gemerkt dat de brug tussen MPU en MCU ontbreekt want de uitgeprobeerde standaard voorbeelden doen het tot dusver.
Hier een aantal links voor de geinteresseerde:
- https://docs.arduino.cc/tutorials/uno-q/user-manual/
- https://docs.arduino.cc/tutorials/uno-q/debian-guide/
De tweede link is een sub van de eerste.
- https://docs.arduino.cc/r.../ABX00162-full-pinout.pdf

Dit is een korte analyse van de Copiloot van het Brug probleem:

🟩 1. The MCU side is fully intact
You can upload sketches.
You can use Arduino Core.
You can control GPIO, matrix, LEDs, etc.
This part is fine.
🟧 2. The Linux side can run Python and Debian normally
You can use it as a small Linux computer.
🟥 3. The Bridge cannot be restored without the official Arduino OS image
Because:
qboard is missing
App Lab runtime is missing
arduino-router service is missing
systemd units are missing
GPIO initialization scripts are missing
MCU handshake logic is missing
Python integration is missing
The only way to restore the Bridge is to reflash the official Arduino OS image

Dat moet dan via klantenservice komen want die staat niet online volgens de AI.
en :
qboard is the Linux-side software stack that makes the UNO Q behave like an Arduino. It includes the matrix driver, App Lab runtime, RPC layer, and MCU communication services. Your board has Debian and the MCU firmware, but qboard is missing.

Dus tja, afwachten wat klantenservice naar me gaat mailen, ik heb al een auto-mail gekregen maar dat leverde geen oplossing. Toch kan ik er nu al wat mee stoeien en dit bevalt me ook wel:
You can use it as a small Linux computer.
Ik heb wel eens een Linux partitie op mijn PC gehad maar door wat geklungel ging de lap op slot en zit dat nog steeds dus dat was best een prijzig experimentje, zeker vergeleken met dit boardje.

Hier het Brug Mechanisme:
https://docs.arduino.cc/t...rocedure-call-rpc-library


.

[kitao]

Nog even kort samengevat:
Q-board vanuit de doos aangesloten met Arduino App Lab geopend waarna dit verscheen:
"Het systeem van het board is verouderd, installeer "Flasher Tool".
Op dat punt bleef App Lab steken dus er was geen andere keus als de Flasher Tool te installeren en daarmee een nieuw image op de MPU te flashen, volgens deze instructie:
https://docs.arduino.cc/tutorials/uno-q/update-image/
en deze:
How to Reflash the Operating System to Your Arduino UNO Q
https://www.digikey.com/e...f9341633f1522f5a792eb622c

Dat flasht dan een nieuwe Debian erin maar dat is blijkbaar niet het Arduino OS image.

Na bezig te zijn geweest met Secure Shell SSH, het gaat stapje voor stapje allemaal, is er een error verdwenen.
Dit command /$ systemctl status ssh en met het Q-board in Netwerk modus had als resultaat dat de Router tussen MPU en MCU goed herkend wordt en blijft.

Maar volgens de Cop assistent is dit de huidige situatie:



This is exactly what happens when the board is flashed with a Debian-only image instead of the full Arduino OS image.

Kern van het probleem is dus waar een Full Arduino OS image voor het Q-board 2GB te vinden en te installeren valt. Ondertussen wachtend op Klantenservice is het board goed te gebruiken want er zit een OS op maar blijkbaar niet (meer) het OS waarmee het geleverd werd of dat erin had moeten zitten.
.

[ Voor 6% gewijzigd door kitao op 27-01-2026 06:43 . Reden: link toegevoegd ]

[kitao]

Update:
Netjes en snel persoonlijk antwoord gekregen per email van Arduino klantenservice. Dit heeft, volgend op de eerdere aanwijzingen van de Copiloot, de laatste plooitjes glad gestreken en het Q-board is nu zoals het hoort te zijn. Er blijkt bijvoorbeeld dat na een 'power-cycle' of een sudo reboot de MCU sketch niet 'auto-runt' zolang daar geen apart knopje voor wordt omgezet, zie afbeelding rechtsboven en link daaronder.



https://docs.arduino.cc/t...running-an-app-at-startup

De foto hieronder van het Q-board is van een matrix voorbeeld die er nu op draait volgens deze link:
https://docs.arduino.cc/t...q/user-manual/#led-matrix



Om terminal commands te geven en om de Linux files te bekijken op de MPU heb ik Visual Studio Code geinstalleerd maar er zijn daar meerdere opties voor om dat te kunnen doen.



Ik heb dus geen spijt van de aankoop en eigenlijk heeft het verouderde OS waarvan het image vervangen moest worden er indirect toe geleid om het board beter te leren kennen.
https://docs.arduino.cc/tutorials/uno-q/update-image/

Of iedere klant daar blij mee zal zijn is de vraag
.