Inderdaad.
Mijn gedachte bij het voorstel van de patronen was (is) dat leds_working een tweedimensionaal array van kleuren is.
Inderdaad.
Mijn gedachte bij het voorstel van de patronen was (is) dat leds_working een tweedimensionaal array van kleuren is.
Dus meer als dit :
LED0 = !LED0;
int leds_working[2][8] = {
{CRGB::Blue, CRGB:Blue, CRGB:black, CRGB;Black ........}
{}
} ;
Dit lijkt te werken
bool tweeKeer(int potVal)
{
LED0 = !LED0;
CRGB leds_working[2][8] = {
{CRGB::Blue, CRGB::Blue, CRGB::Black, CRGB::Black,CRGB::Blue, CRGB::Blue, CRGB::Black, CRGB::Black },
{CRGB::Black, CRGB::Black, CRGB::Blue, CRGB::Blue, CRGB::Black, CRGB::Black, CRGB::Blue, CRGB::Blue},
} ;
pwmAll(leds_working[LED0] ,16);
return true;
};
Maar nu zie ik sommige leds rood worden.
Later vandaag maar eens kijken waar dat vandaan komt.
Welke? Toevallig de laatste acht?
Chips,
Ik zie het.
IK moet 16 entries hebben in plaats van 8
Ik geef het warme weer ( 30+) gewoon de schuld ![]()
oke
Dit werkt
bool tweeKeer(int potVal)
{
LED0 = !LED0;
CRGB leds_working[2][16] = {
{CRGB::Blue,
CRGB::Blue,
CRGB::Black,
CRGB::Black,
CRGB::Blue,
CRGB::Blue,
CRGB::Black,
CRGB::Black,
CRGB::Blue,
CRGB::Blue,
CRGB::Black,
CRGB::Black,
CRGB::Blue,
CRGB::Blue,
CRGB::Black,
CRGB::Black
},
{CRGB::Black,
CRGB::Black,
CRGB::Blue,
CRGB::Blue,
CRGB::Black,
CRGB::Black,
CRGB::Blue,
CRGB::Blue,
CRGB::Black,
CRGB::Black,
CRGB::Blue,
CRGB::Blue,
CRGB::Black,
CRGB::Black,
CRGB::Blue,
CRGB::Blue},
} ;
pwmAll(leds_working[LED0], 16);
return true;
};
Alleen zie ik nu af en toe led 15. 16. 1 en 2 allemaal blauw en dat is niet goed.
Denk dat ik een derde regel moet toevoegen of een loop zodat ik even alle leds weer op zwart zet voordat de volgende "ronde" begint
Je weet dat je een zip kunt downloaden van een wokwi? Kun je het op je gemak op een PC bekijken ![]()
Dit werkt perfect voor mij
bool tweeKeer(int potVal)
{
LED0 = !LED0;
CRGB leds_working[2][16] = {
{CRGB::Blue,
CRGB::Blue,
CRGB::Black,
CRGB::Black,
CRGB::Blue,
CRGB::Blue,
CRGB::Black,
CRGB::Black,
CRGB::Blue,
CRGB::Blue,
CRGB::Black,
CRGB::Black,
CRGB::Blue,
CRGB::Blue,
CRGB::Black,
CRGB::Black
},
{CRGB::Black,
CRGB::Black,
CRGB::Blue,
CRGB::Blue,
CRGB::Black,
CRGB::Black,
CRGB::Blue,
CRGB::Blue,
CRGB::Black,
CRGB::Black,
CRGB::Blue,
CRGB::Blue,
CRGB::Black,
CRGB::Black,
CRGB::Blue,
CRGB::Blue},
} ;
pwmAll(leds_working[LED0], NUM_LEDS);
for (uint8_t cnt = 0; cnt < NUM_LEDS; cnt++)
{
pwmLed(cnt, 0);
}
return true;
};
Is dit wat jij ook bedoelde @sterretje
Ik gebruik alleen pwmAll() en zie geen vreemde effecten in mijn fysieke opstelling.
Dus die for-loop op het eind heb je niet nodig.
Zet je hele programma hier even neer (zipje).
effecten_verbeterd_led_ring.zip (15,9 KB)
hier heb je de zip file met de loop verwijderd.
Wokwi: https://wokwi.com/projects/439094829134194689
Ik heb je programma daar neergezet en het doet wat je het verteld hebt te doen; ieder LED paar verandert iedere timer tick.
De kleuren van LEDs 1, 2, 15 en 16 zijn veranderd zodat ik kan zien wat er gebeurd met die LEDs.
klopt
En zoals je dan kan zien, zie je some 4 rode blokjes waar ik maar 2 verwacht.
Als je kijkt naar het schema wat ik eerder gepost heb.
Als 14 en 1 5 rood zijn, dan zouden 1 en 2 zwart moeten zijn.
Daarom de extra loop
Ik zie dat niet gebeuren. Ik heb twee minuten ernaar zitten kijken.
Vervolgens heb ik je calcDelay() een beetje aangepast zodat het wat langzamer kan gaan.
Daarna wat debug informatie toegevoegd in tweeKeer() en in loop() het printen van rr er tijdelijk uitgehaald.
De uitvoer in seriële monitor ziet er nu zo uit:
Debug : 0, 0, 255, 255
Debug : 255, 255, 0, 0
Debug : 0, 0, 255, 255
Debug : 255, 255, 0, 0
Debug : 0, 0, 255, 255
Debug : 255, 255, 0, 0
Debug : 0, 0, 255, 255
Debug : 255, 255, 0, 0
Debug : 0, 0, 255, 255
Zoals je kunt zien gaat alles netjes; fouten zou je moeten zien doordat de regel lengte verandert (0, 0, 0, 0 is korter dan de verwachtte uitvoer, 255, 255, 255, 255 is langer).
Je kunt dan calcDelay() weer terugzetten naar de standaard waardes en testen.
Let op: dit werkt alleen omdat de 4 LEDs een rode kleur hebben, als je ze blauw maakt moet je .b gebruiken in plaats van .r; dit was het snelste om te zien of er wat fout gaat, anders moet ik een wat uitgebreidere debug schrijven.
oke
Als ik alles langzamer doe , gaat alles goed
Bij heel snel lijkt het of er wel 4 rode zijn.
Daarom denk ik er al meer over om de snelheid eruit te halen en alle effecten een vaste interval te geven.
Nog 1 effect te gaan morgen.
Of je PC kan het niet bijhouden of je je ogen ![]()
Dat is aan jou; ik zou het erin houden voor één of meer effecten zodat er mee gespeeld kan worden maar dat ben ik.
En daarna kunnen we mogelijk verbeteren / opschonen.
kan ook maar dan "moeten" we kijken naar welke getallen misschien beter passen bij welke effect.
Merk dat de huidige getallen zeker niet passen bij in ieder geval dit effect en de twee_keer.
Maar eerst maar even deze aan de praat krijgen en dan verder kijken wat de "beste" volgende stap kan zijn.
Of snelheid of de effecten naar een apart bestand.
Moet zeggen dat snelheid mij nu het meeste irriteert.
ik zat op de "staart" goed te krijgen hierna te kijken
leds[cnt] = CHSV(1, 255, cnt * 16);
Morgen weer een dag
Maar dit levert me geen hele vage blauwe kleur op
pwmLed(trails[4], CHSV(1, 255, CRGB::Blue));
Maar een rode kleur.
Zo morgen maar eens verder in de documentation duiken.
Frusterend
IK ben nu deze weg aan het proberen.
pwmLed(trails[4], CHSV( 160, 100, 255));
Maar het is een andere blauw dan CRGB::Blue en niet een vagere blauw.
Echt maar eens een nachtje over slapen.
of de functie Brightness gaan gebruiken.
Je moet een klein beetje bestuderen wat HSV is; google het. Het staat voor Hue, Saturation en Value. Ik weet ook niet alle details ervan maar de V staat voor de intensiteit en H en S bepalen de kleur; het is dus niet logisch om V de waarde CRGB::Blue te geven.
Als je de HSV waarde van een RGB waarde wilt weten kun je rgb2hsv_approximate gebruiken.
Prototype:
CHSV rgb2hsv_approximate(const CRGB &rgb)
Let op de maximale waarde van V.
Dat is inderdaad een andere kleur blauw.