Hulp bij board keuze

Ik zou dit in een ESP32 doen, als je toch wifi wilt is dat het eenvoudigste. Je kunt die PWM frequentie gewoon instellen. Op die manier zijn updates ook simpel, via wifi zonder iets open te maken.

Daar zat ik ook in eerste instantie aan te denken, maar ik weet niet of het kan. Ik heb wat minder goede ervaringen gehad bij een ander project. Daar had ik dit ding gekocht.
https://www.conrad.de/de/p/espressif-esp32-c3-devkitm-1-entwicklungsbo…
Dit is gebaseerd op een ESP32-C3-MINI-1. Daar had ik 3x PWM fan en 4x PWM leds op gepland. Kijken naar de hoeveelheid PWM pinnen moest dat makkelijk lukken. Echter, in realiteit kon je maar 5 pinnen tegelijk PWM laten geven. Om dat werkend te krijgen moest ik zelfs compiler dwingen bepaalde PWM pinnen op bepaalde timers te zetten anders werkte het ook niet. Ik heb toen wat PWM functionaliteit moeten opofferen wat op zich wel kon. Bij dit lamp project is dat ondenkbaar.

Waar ik mij ook zorgen om maak is het zowel ontvangen als zenden van IR op 1 chip. Bij Arduino's moeten dit soort dingen volgens mij op interupts zitten wat volgens niet helemaal goed gaat met zowel zenden als ontvangen. Zeker weten doe ik dit echter niet. Ik weet niet of dit problemen geeft bij een ESP32.

Edit:
Ik ben nog even wat bij aan het lezen. ESP32-C3-MINI-1 zou 6 hardware PWM's moeten hebben, echter de PWM frequentie gaf daar issues aangezien 4 pinnen op 1 timer zitten, en 2 op een andere timer. Daar zat het probleem toen.

Ik ben nu wat aan het kijken naar dit ding.
https://www.tinytronics.nl/en/development-boards/microcontroller-board…

Hier zou ik een PCB antenne aan kunnen zetten en die op een gunstigere plek plaatsen. Dat zou kunnen werken. Ook zit hier de ESP32-S2-WROOM op die 8 hardware PWM zou moeten hebben. Dat is niet voldoende maar omdat het LEDs zijn en geen PWM fans neem ik aan dat software PWM ook wel moeten werken?

Edit 2:
Of ding ding. 16 hardware PWM channels
https://www.tinytronics.nl/en/development-boards/microcontroller-board…

Die laatste zou ook mijn keuze zijn, al is het alleen maar voor de LEDs.

Daar had ik 3x PWM fan en 4x PWM leds op gepland. Kijken naar de hoeveelheid PWM pinnen moest dat makkelijk lukken. Echter, in realiteit kon je maar 5 pinnen tegelijk PWM laten geven.

Volgens mij klopt dat niet en je zou 16 PWM tegelijk moeten hebben.
Waarom zouden al PWM op een andere frequentie moeten? Volgens mij kan dat allemaal op 1 frequentie

Veel pinnen hebben wel meer dan 1 functie of moet je ergens anders voor gebruiken. En anders een GPIO expander zoals bv een PCF8575 gebruiken.
https://www.benselectronics.nl/pcf8575-i2c-i-o-expansion-board.html?so…

Als dat zou kunnen is dat goed om te weten.
Wat bij mijn weten probleem was, is dat PWM fans 25kHz moeten krijgen. Echter, de PWM led libary draait op 1kHz (uit mijn hoofd). Dit conflicteert.

Dit was de setup.

output:
#PWM fans
- platform: ledc
pin: GPIO6
id: fan_left
channel: 0 #Channel 0,1,2,3 --> Timer group 1
frequency: 25000 Hz # typical PWM freq for PC fans is 25 kHz
- platform: ledc
pin: GPIO7
id: fan_mid
channel: 1 #Channel 0,1,2,3 --> Timer group 1
frequency: 25000 Hz # typical PWM freq for PC fans is 25 kHz
- platform: ledc
pin: GPIO5
id: fan_right
channel: 2 #Channel 0,1,2,3 --> Timer group 1
frequency: 25000 Hz # typical PWM freq for PC fans is 25 kHz

#LEDs
- platform: ledc
pin: 3
id: pwm_led_0
max_power: 10% #Limit brightness
channel: 4 #Channel 4,5 --> Timer group 2
- platform: gpio
pin: 0
id: bin_led_1
- platform: gpio
pin: 1
id: bin_led_2
- platform: gpio
pin: 10
id: bin_led_3
- platform: ledc
pin: 21
id: pwm_led_4
channel: 5 #Channel 4,5 --> Timer group 2

Nu ik dit typ zie ik dat ik ook de LEDs had kunnen forceren op 25kHz. Dat is dezelfde libary als de PWM fans. Dat was niet zo slim. Maar dan nog blijf je steken op 6 hardware PWM's want dat is de max van de chip. Ik heb me destijds niet in software PWM verdiept.

Terug naar mijn oorspronkelijk vraag
Zien jullie problemen met zowel IR sturen als ontvangen op 1 chip? Dat gaat niet conflicteren met interrupts enzo?

Nee daar zijn interrupts juist voor. Een ESP kan heel hard rekenen, die is echt niet onder de indruk van een paar interrupts van je IR ontvanger.

Wat die PWM kanalen betreft, er zijn nogal wat varianten van de ESP32, en sommige hebben inderdaad 16 hardware PWM kanalen.

Oké.
Ik ga me er eens in verdiepen. Een test schema bedenken en de spullen om het uit te proberen.
Bedankt voor de hulp

Voor de leds kan je perfect een PCA9685 gebruiken. Hoef je met PWM en timing al geen rekening te houden in je software. Als de leds meer dan 25mA of 400mA samen verbruiken, dan kan je best de MOSFET schakeling van figuur 26 op blz 35 van de datasheet gebruiken. Wil je de 5V minder belasten zijn de MOSFET ook een optie. Er staat wel geen weerstand getekend tussen IC en MOSFET. Volgens bepaalde bronnen op internet, oa NXP, is het niet dwingend noodzakelijk maar kan een 10Ω geen kwaad.

Voor de temperatuur zou ik DS18B20 gebruiken. Je hebt dan maar 1 I/O nodig voor alle sensoren. 7 sensoren lijken me ook overkill.

Waarom 4 uitgangen voor SK6812? Kan toch perfect op 1. Zelfs 100 na elkaar is geen enkel probleem.

edit: software update laat ik altijd gebeuren via een webinterface. Heeft nog nooit gefaald. OTA is een ander verhaal. Soms zie je de device verschijnen in de connecties. De kans is dan nog reëel dat die plots verdwijnt. Meestal verschijnt die niet.

edit 2: de PCA9685 misbruik ik om 16 servo's te sturen en ernaast staan er nog 2 die elk 16 leds aansturen.

Die PCA9685 en DS18B20 zijn geen onaardig nee. Daar ga ik eens over nadenken.

4 uitgangen voor de SK6812? Hoe meer hoe beter. Wordt het betrouwbaarder van. Achteraf had ik misschien weg moeten blijven bij die adresseerbare leds. Als er eentje stuk gaat, valt alles daarna uit. Het in 4 stukken hakken helpt in ieder geval iets.

Als je de individuele adresseerbaarheid bij nader inzien toch niet wilt gebruiken, dan kun je alle data ingangen parallel zetten. Dan krijgen ze allemaal dezelfde functie, waarbij er geen keten met leds meer is die afhankelijk zijn van een voorganger...

Hoeveel ingangen komen er dan parallel te staan? Het signaal moet namelijk misschien gebufferd worden om voldoende stroom te leveren.

Het is een LED strip. Dus die truc gaat niet werken

RGB ledstrip gebruiken en ook aan de PCA hangen met mosfet. Tenzij je alle leds een andere kleur wil geven. 3 uitgangen op de PCA is voldoende. Anders extra PCA op een ander adres en dan kan je er 5 verschillende sturen.

De SK6812 gaan nog niet zo snel stuk. Alleen voor zorgen dat ze geen overspanning krijgen. En niet de maximale lichtsterkte nastreven. Voor een skipiste heb ik een 'lamp' gemaakt met >100 WS2812. Wordt de ganse periode van augustus tot Pasen dagelijks meerdere uren gebruikt. 4:45 wit en 0:15 rood. NTP server voor de correcte tijd. Draait al ruim 4 jaar.

Ik weet het. Zo had het moeten zijn. Ik heb de ledstrip echter al gekocht. Dus hij gaat er toch maar in.
Maar aldoende leert men. Voor een volgend project

Update:
Het duurde even voordat ik tijd had om een testopstelling te bouwen en dit allemaal te testen. De resultaten zijn niet goed. Dit is het verhaal.

Ik draai ESPHome. Oorspronkelijk was ik dit van plan
7 temp sensors. Uiteindelijk allemaal via 2x ADS1115 gedaan.
10x PWM led.
1x PWM fan (dit heb ik nog niet getest bedenk ik me nu al verwacht niet veel issues, en anders offer ik dit op)
Dat ging goed totdat ik ook dit toe ging voegen.
4x SK6812
1x RF receive
1x IR send

Dit gaat voor geen meter. Om te beginnen krijg ik 4x SK6812 al niet voor elkaar. De combinatie van 1x SK6812 met RF reive ging ook al fout. Het helpt waarschijnlijk niet dat mijn RF receiver een raw signaal naar de ESP stuurt.

1x RF receive en 1x IR send ging dan wel weer goed tot mijn verbazing. Ik had hier timing issues verwacht. Al heeft de RF afstandbediening geen 100% succes percentage. Maar ik twijfel of dat aan de ESP ligt.

Al met al is het duidelijk dat de SK6812 de deur uit moet. Dit gaat wel tot tig meer PWM kanalen zorgen omdat ik RGB strips ga gebruiken. Dus dat zal ik op moeten vangen met 2x PCA9685. Wat dan wel meteen als voordeel heeft dat ik die lokaal kan plaatsen, wat mijn bedrading wel wat op schoont. Ik hoop dat 0.5m nog wel wil lukken met I2C. Ik kan altijd nog de frequentie wat omlaag zetten van de I2C. Het zijn maar LEDs niet waar

Een RF receiver die zelf de codering doet van het signaal zou ook nog iets verlichting kunnen geven voor de ESP. Maar mogelijk kan ik wel zonder.

Ik mag de testsetup weer gaan wat gaan verbouwen

Kun je iets meer toelichten wat er fout gaat? Want op het eerste oog zou de combinatie prima moeten kunnen werken.
Plus als je ir commando’s aan het ontvangen bent hoef je niets met de leds op dat moment te doen. Bendes benieuwd wat er exact misgaat en hoe je de code hebt opgebouwd

Die SK6812 is een serial led die behoorlijk tijdkritisch zijn (1 bits= 1.25μs±600ns) aka neopixel leds. Je moet daarvoor alle interrupts uitschakelen om dat stabiel werkend te krijgen (1 rij led updates).

Er zijn ook leds die een serial clk gebruiken waarbij je dit probleem niet hebt, ik weet even zo de type nummers niet. Daar kun je fatsoenlijke software voor maken zonder timing ellende.

Wil je toch die "timing kritische" leds gebruiken zou je een truuk met DMA kunnen doen, dan vul je een buffer met data waarvan je alleen Bit 0 gebruikt om je timing patroon in te zetten. Dan gebruikt je de DMA controller om de data naar een I/O pin te schrijven. Je bent dan 4-5 bytes per bitje kwijt oid.
Op een RPi heb ik eens gevonden dat iemand dat deed. Kost wel veel RAM.

-edit-
APA102 is er zo een. Ook in led-strips te krijgen, je hebt dan 1 I/O pinnetje extra nodig.

Nog een paar: SK9822 / HD107 / APA107

Klopt. Daar komt het wel op neer.
Dat raw RF signaal zorgt voor heel wat interrupts. Of ik kon het al niet eens compilen. Ik weet het niet meer.

Dan zat je met die SK6812 nog met het probleem dat je framework Arduino moest gaan, anders mocht je volgens mij vrij weinig leds hebben. Op framwork arduino heb 4x SK6812 strips geconfigureerd maar uiteindelijk werden die 4 allemaal aan het laatste strip variabele geknoopt en waren ze dus niet afzonderlijk te besturen. ALs ik chat GPT even mag citeren (altijd dubieus)
eps32_i2s --> 1 strip only
esp32_rmt --> Several strips but conflicts with RF

Zoiets was het volgens mij.
Al met al, heel veel timing ellende.

Ik had je post nog nooit gelezen, nu pas. Anders had ik je op voorhand kunnen vertellen dat het niet gaat werken met die neopixel dingen zonder clock.
10 jaar geleden al de APA102 gevonden wat tig keer makkelijker is als je wat meer in je CPU wilt doen dan alleen de ledjes aansturen.

[Bericht gewijzigd door henri62 op maandag 23 maart 2026 19:54:56 (31%)]

ESP32 blijft een beetje een raar ding. Hij heeft wel veel rekenkracht met zijn dualcore 240MHz CPU. Maar hij heeft ook de firmware in een externe seriele flash chip. Dus dat betekent dat de code telkens bit voor bit door een 25MHz SPI pin moet worden binnengehaald. En dat kost tijd. Dus de processor moet regelmatig toch even wachten op de code voor de volgende instructies. En dat is niet zo handig voor real-time processen.

Toch begrijp ik het niet. Als je bezig bent met je RF luisteren of zenden (als dat aan de orde is) dan ben je toch niet bezig met de leds anders instellen?
Na een RF commando stop je even de RF. Pas je de leds aan. En zet je RF weer aan. Alle functies hoeven toch niet perse tegelijk te gebruiken te zijn?

Ha, leuk dat dit project nog loopt.

Staat je code ergens online? (github, gitlab, codeberg.org)

Goed, ledstrips aansturen is timing-kritisch. Maar eenmaal aangestuurd blijven die LED's doen wat de vorige opdracht was. Dus dat hoeft niet continue. Daar kun je waarschijnlijk tijd winnen. Als je ze alleen ververst als er wat veranderd is... Of voor animaties zeg 20x per seconde... Dan kan de chip ondertussen wat anders.

IR kun je pollen, maar als je ondertussen wat anders wilt doen wellicht beter in een interrupt. Hetzij een flankgestuurde interrupt op de de IR ingang. Hetzij een timer-interrupt om sneller-dan-de-baudrate zo af en toe eens naar die pin te kijken (te samplen). Daar kun je waarschijnlijk tijd winnen.

Raw RF geeft teveel interrupts zeg je. Zit dat nu op een flankgestuurde interrupt? Tsja, je hebt geen idee wat de "ruis" in de lucht doet, misschien is "sneller dan de baudrate samplen" op een timer-interrupt daar iets. Timer loopt af -> pin samplen en bitje in register schuiven -> return from interrupt. En na 8 bitjes het byte in een buffer schuiven en pas daarna return. En dan af en toe eens in die buffer kijken of je er wat mee moet. Elke seconde ofzo... Of als de buffer vol begint te raken...

Met wat mazzel kun je zelfs een hardware SPI module oid gebruiken in plaats van zelf in de interrupt met bitjes te schuiven. Win je nog meer tijd. Ik ken de ESP-32 hardware niet echt goed, dus ik weet niet of die een bruikbare SPI heeft maar zou het vermoeden. Zowel voor data in als voor het aansturen van de LEDstrips. Maar ik denk dat die ESP dit (makkelijk) kan. (En anders... Probeer 's een Raspberry Pi Pico met wifi als het moet)

ChatGPT kan je misschien meer aanknopingspunten geven op bovenstaande, maar houd er rekening mee dat het slechts grammaticaal correcte zinnen ophoest. Technisch inhoudelijk hoeft het niet te kloppen. Idealiter geeft het een bronvermelding en kun je het aldaar zelf nagaan.

(Als ik dingen vraag over boeken worden er soms bestaande schrijvers gekoppeld aan boeken die ze niet geschreven hebben... Immers: "Kuifje van de bolhoeden-flat, ISBN 0131969188, is geschreven door Paulien Cornelisse" is een grammaticaal correcte zin. Het is zelfs een bestaande schrijfster, en een bestaand ISBN, en een plausibele boektitel.)

Je zult je eigen verstand moeten toevoegen wil het wat werkends worden. Anders krijg je code die in het beste geval niet compiled, en in het slechtste geval lijkt te doen wat lijkt op wat het zou moeten doen, met wat ongedocumenteerde verassingen. (dat is een typefout, maar we hadden het over worst-case, dus ik laat 'm staan).

Op maandag 23 maart 2026 20:34:01 schreef rudig76:
Toch begrijp ik het niet. Als je bezig bent met je RF luisteren of zenden (als dat aan de orde is) dan ben je toch niet bezig met de leds anders instellen?
Na een RF commando stop je even de RF. Pas je de leds aan. En zet je RF weer aan. Alle functies hoeven toch niet perse tegelijk te gebruiken te zijn?

Als je via RF je lampen wil aan/uit doen, wil je toch niet dat de kleurfading van de leds stopt. Des te meer leds, des te meer bits dienen er verzonden.

Waarschijnlijk zit het probleem in het gelijktijdig gebruik van tijd kritische zaken.

Aan de andere kant is het wel wat dubbel op. Gebruik van ESP-home, RF en IR. BT en BTSerial is ook nog een mogelijkheid. Ik zou het bij 1 oplossing houden.

Dat is ook waar ik denk dat het fout gaat. Ik zit nu nog met 2 tijdkritische dingen. RF ontvangen en IR zenden. Dat leek nog goed te gaan totdat ik de dimmer knip op de RF afstandbediening toe ging voegen aan het project. Kennelijk zendt die op een hoger tempo signalen uit. Nu komt er alleen nog maar brij uit de IR zender. Ik moet dit nog verder onderzoeken.

Het zou een idee zijn met de RF ontvanger uit te schakelen tijdens het verzenden van IR. Ik weet alleen niet of ik daar vrolijk van ga worden omdat ik dan RF commando's ga missen. Ik moet dit nog bekijken.

@Lucky Luke
Leuk je weer te zien in een topic van mij! Je hebt me inderdaad al eerder geholpen bij dit project.
Ik moet beschamend toegeven dat dit project nog steeds loopt ja. Ik heb er jaren niet meer aan gewerkt. Maar elke keer als ik zo'n pod uit de kast haal en hem aanzet weet ik weer dat dit project afgemaakt moet worden. Die pods zijn zo waanzinnig mooi! Het komt helaas niet goed over op foto's.

Ik heb eigenlijk geen idee wat die libraries allemaal uitspoken bij dat ESP32 project en of ze inderdaad gebruik maken van interruptpinnen. Je zou verwachten van wel voor tijdkritische dingen.

De code staat niet op github, maar je mag hem zo hebben. Even om mij zelf in te dekken, deze code is enkel bedoelt om de functionaliteit te testen is dus gewoon een beunproject met bijna niets erin Ooit zal ik alles compleet herschrijven en functioneel maken. Maar dat doe ik wel als de lamp aan het plafond hangt
Code

Ik heb jullie hulp weer nodig. Ik kom ergens niet uit. Ik zal wel iets fout doen.

Ik bedacht, laat ik die RF ontvangen en IR zenden loskoppelen van elkaar door het door 2 chips te laten doen. IR zenden doet de ESP32 en RF ontvangen een Arduino uno. De uno stuurt zijn informatie door via UART. Dat zou niet timing gevoelig moeten zijn heb ik begrepen.

Echter, het wil maar niet werken. Zelfs als ik het heel basaal weet ik te maken. De Uno stuurt een signaal. Ik gebruik een level converter om naar 3,3V te gaan en de ESP32 lijkt het te negeren. Ik zie wel dat de UART op start maar er komt niets binnen. Ik ben er al een tijdje mee bezig maar krijg niets voor elkaar. Ik kan met mijn scoop zien dat er wel een signaal naar de ESP32 gaat.

Zo ziet het er uit.

Code Arduino

#include <SoftwareSerial.h>
#include <Arduino.h>

// TX only (pin 11)
SoftwareSerial espSerial(-1, 11);

void setup() {
  espSerial.begin(9600);
}

void loop() {
  espSerial.println("HELLO");
  delay(1000);
}

Code ESP32

esphome:
  name: eettafellamp
  friendly_name: Eettafellamp

esp32:
  board: esp32dev
  framework:
    type: arduino
api:

wifi:
  networks:
  - ssid: "iets"
    password: "iets"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
      ssid: "Iets"
      password: "Iets"

ota:
  - platform: esphome
    password: "Iets"

packages:


uart:
  rx_pin: 16
  baud_rate: 9600
  debug:
    direction: RX
    after:
      timeout: 10ms
      
logger:
  level: VERY_VERBOSE
  baud_rate: 0

Überhaupt geen slim idee dit?