Page 3 of 4

Re: SK6812 LED

Posted: Thu Apr 04, 2024 6:53 am
by mnfisher
Something is wrong....

I downloaded Testsk6812 from above - the MCU is set as ATMEGA328PTQFP (is this intended?)

Changing the target to ATMEGA328p gives ->
Pin0 of component ESP_RMT1 is connected to bit 2 of Port A but this port/bit does not exist on the new microcontroller
Flowcode then closes (crashes - for me at least). As mentioned above - for some reason it is trying to use the esp32 RMT component. Which can't work here.. The sk6812 component does use the esp32_rmt component but only for use on the esp32.

Which MCU are you trying to target (329PB implied above) and what speed is it running at (8 /16MHz/Other)

Starting from scratch with a 329P controller selected - lets me compile correctly - I don't have one to test with but can test the output on a 328P?

Martin

Re: SK6812 LED

Posted: Thu Apr 04, 2024 7:39 am
by ChrisT66
Thank you Martin,
if the SK6812 only runs on an ESP32 I have already lost.
I have a 328PB TQFP in use, but I don't think there are any differences as far as the C5 output port is concerned.
I guess it won't work with the WS2811/12 either.

Thanks again

Chris

Re: SK6812 LED

Posted: Thu Apr 04, 2024 7:51 am
by chipfryer27
Hi

I created (and can compile to Hex) a chart from scratch using a 328P and can flash each colour in turn, but as I don't have the component to test with I'd need to scope to check. Connection was default pin C5.

I notice in the component properties the data order is GRBW (non changeable) so just wondering if a typo?

Curious though as the initial post asked if there is a RGB version of the component but it appears a RGBW strip is being used.

Regards

Re: SK6812 LED

Posted: Thu Apr 04, 2024 7:54 am
by chipfryer27
PS

The attached compiles to Hex OK for me in FCv9 (using tqfp)

It flashes each colour in turn

Testsk6812_Flash-RGBW.fcfx
(13.46 KiB) Downloaded 24 times
Regards

Re: SK6812 LED

Posted: Thu Apr 04, 2024 8:20 am
by ChrisT66
Hi, the data sequence is ok.
No matter what you do, the LED only lights up white.

(I fitted an SK6812RGB on my board and only then realized that the command controls an RGBW. So of course I replaced the RGB with an RGBW. The RGB did not light up at all).
I don't think the LED is broken, but I will replace it too....

Regards

Re: SK6812 LED

Posted: Thu Apr 04, 2024 8:35 am
by chipfryer27
Hi

Did my chart compile OK for you?

Just a thought and I might be wrong (frequently so) but isn't the SK6812 an "upgraded" WS2812 in terms that is uses similar protocol? That's a RGB component so maybe worth giving that a shot?

Regards

Re: SK6812 LED

Posted: Thu Apr 04, 2024 9:56 am
by mnfisher
The timing might be a bit 'tight' on an 8MHz chip and hardware?

A while ago I posted some code for the ATTiny85 -
at85_rainbow.fcfx
(19.21 KiB) Downloaded 12 times
Where you can try 'tweaking' the timings. Note that this can be sped up by removing the 32 bit variable in Refresh and using 3 single byte 'shifts' (the AVR MCUs are 8 bit and shifting a 32 bit number involves a lot more code)

If you have a scope - you can look at the signal generated and adjust the number of 'nops' which is how I tuned this.

I believe the sk6812 needs slightly shorter pulses than the ws2812 - but have seen mention that the same timings will work too?

Martin

Re: SK6812 LED

Posted: Thu Apr 04, 2024 10:55 am
by ChrisT66
Thanks for the suggestion and the example. I was actually looking for a very simple solution to save space on the circuit board by placing one RGB LED instead of three individual LEDs.
But this is now turning into a really complex topic.... too bad.

I'll probably stick with the three LEDs.

Thanks to everyone for the help

Re: SK6812 LED

Posted: Thu Apr 04, 2024 11:17 am
by mnfisher
I have some sk6812 chips - I'll see if I can get it working in hardware for you....

Again - just to check - your board is running at 8MHz.

The alternative is a ws2812?

Martin

Re: SK6812 LED

Posted: Thu Apr 04, 2024 11:52 am
by mnfisher
Just got an SK6812 running with an Arduino - admittedly 16MHz - using the library. The solution seems to be simpler than expected - add a small delay after the initialise (it seems that the LED takes a moment to become 'ready' after power on')