1.Don't check the return value of nxsem_init or nxmutex_init
2.Fix some style issue
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
0c3db448bb
added the option to generate the waveforms to drive ws2812 and similar LEDs using different
hardware (e.g. RP2040 PIO instead of SPI).
For that new mode, the concept of CONFIG_WS2812_FREQUENCY is different. Instead of
the SPI frequency (commonly a few MHz), it is the frequency of the actual output waveform
(commonly 400 or 800 kHz).
There was an attempt to express the SPI frequency divided by 10, but it's not actually the
case either (it would be divided by 8).
I think it is clearer to explain in Kconfig what CONFIG_WS2812_FREQUENCY means for each mode
and go back to the previous behaviour for the original SPI mode (also to avoid breaking
out-of-tree boards).
It's not necessary to send a reset pulse after sending the RGB data
since the first thing that a new transmission does is sending the long
reset pulse. I have left 1 reset byte after the RGB data to keep some
padding given that the bits inside the byte are shifted by 1 bit although
I think it wouldn't be necessary either. But just in case.
This reduces the memory usage (you can easily save 60 bytes) and increases
the maximum refresh rate.
Previously only 4 MHz and 8 MHz were allowed. Given the tolerance
allowed in the WS2812 timing spec, frequency ranges around those
two can be used too which is useful for boards in which it is
difficult to generate those specific frequencies.
The WS2812 is very common in LED strips as it is an integrated
controller and LED. It is driven by a single data line, but
the timing requirements can be met by using most SPI controllers
and the use of DMA.
This driver has been validated on the nRF52 arch both with a
single LED and a strip of 144.
Signed-off-by: Brennan Ashton <bashton@brennanashton.com>
