search

openshwprojects / OpenBK7231T_App

Open source firmware (Tasmota/Esphome replacement) for BK7231T, BK7231N, BL2028N, T34, XR809, W800/W801, W600/W601, BL602 and LN882H
https://openbekeniot.github.io/webapp/devicesList.html
1.5k stars 281 forks source link

WS2812B Support #176

Open joshgarde opened 2 years ago

joshgarde commented 2 years ago

I recently bought one of these cheap wifi WS2812B/WS2811/SK6812 controllers from the rainforest website - 04DCCCC5-53B3-4F0C-A56A-4A0629D55C84

I tore it open recently and successfully flashed it, but I noticed that there wasn’t any support in the firmware for WS2812B strips. The controller inside is directly attached to a bus transceiver IC to buffer the data signal from the BL602 to 5V so there’s no additional MCU to generate the data out or to run the animations.

What’s you guy’s thoughts on adding native WS2812B strip support to the firmware? I’m new to the repo, but from what I see, the firmware’s drivers aren’t really meant to have higher update rates than 1 second (from DRV_OnEverySecond()) but WS2812B strips generally need 10-15 updates a second to provide smooth animations. Adding animations would also increase the size of the compiled firmware and the amount of RAM consumed in an already resource constrained system. Let me know what you think

joshgarde commented 2 years ago

Ah - apologies, I’m still new to this codebase. I just realized this firmware is based on FreeRTOS so it also contains threading so that answers my update question. Still, there are the other downsides to contend with - WS2812B support would require a fair amount of CPU time as the protocol requires accurate data timings, a fair amount of memory if animations require a render buffer (though some animations can be simply done with on-the-fly rendering without too much memory), and space in the firmware

openshwprojects commented 2 years ago

Thanks! I haven't seen yet any BK devices with WS2812B, this is a news to me. Or wait, are you saying it's a BL602 device?

Drivers could update more often.

Animation render buffer can be only created with malloc() if animations are needed so I don't think it's a problem.

Maybe we should consider porting existing WS library?

joshgarde commented 2 years ago

Or wait, are you saying it's a BL602 device?

Yep - it's a BL602 inside that controller.

Drivers could update more often.

I was thinking of implementing the driver as a thread instead of using the driver loop, but I'm not sure if that's feasible to do as the BL602 is a single core device and it might hog CPU time just bit-banging the output, but not sure.

Animation render buffer can be only created with malloc() if animations are needed so I don't think it's a problem.

Yeah I was thinking about it from the perspective of the memory buffer required to support the amount of pixels the original firmware was designed to drive (2048 pixels 8-bits per color 3 colors / 8 bits/byte = 6144 bytes). The BL602 supports 276KB of SRAM so I just wasn't sure how much of it the firmware on its own needed.

Maybe we should consider porting existing WS library?

FastLED - https://github.com/FastLED/FastLED FastLED seems flexible, but it also seems like it includes a ton of other stuff as well. NeoPixel - https://github.com/adafruit/Adafruit_NeoPixel Adafruit's NeoPixel is lightweight, but it doesn't have a lot of features which means developing animations by hand

I think FastLED might be the better candidate, but it is a beefier library to port. I would probably make a submodule in the repo and then build off of that rather than bringing in the entire library and having to manually maintain it separate of FastLED's repo.

joshgarde commented 2 years ago

Just investigated porting the FastLED library over and it seems that FastLED needs platform specific bindings in order to work. I might try porting the library on their end first and then integrating it into this repo once those changes are accepted

joshgarde commented 2 years ago

Or hm... it might be easier to just "port" in the traditional sense. Just copy/paste their code and then port it in here to the APIs we have available - avoids the chicken/egg problem of building their library against the APIs here vs building this firmware against their libraries. I'll see if I can hack up an implementation later in a few days

alfondric commented 2 years ago

Thanks! I haven't seen yet any BK devices with WS2812B, this is a news to me. Or wait, are you saying it's a BL602 device?

I've picked up an Aldi branded floor lamp fitted with what appears be a BK7231N based module. Tracing the pins it looks like it directly drives a set of SM16703P (similar to WS2812) chips for the RGB strip, the white LEDs I think are controlled by PWM on another pin? I'd love to see WS2812B support so that I don't have to use the built-in Tuya firmware, happy to help out in any way.

Bacto commented 2 years ago

Hi,

I'm starting to work on the "LSC Smart Digital Led Strip" which is a dual led RGBCW strip.

On the board we have:

It controls 2 rubans plugged in parallel with:

The rubans have 5 pins:

The RGB leds are my problem. For what I have seen:

The SM16703P datasheet is here: SM16703ICdatasheet.pdf

Having the ability to control SM16703P chipsets would be awesome :)

Bacto commented 2 years ago

More informations about the "LSC Smart Digital Led Strip" and the potential WS2812 and SM16703P here: https://www.elektroda.com/rtvforum/topic3935979.html

sqrtroot commented 1 year ago

I don't know how far you guys got, but one trick that is sometimes used is to (miss)use the spi hardware to send the codes by encoding a 0 as 0b100 and a 1 as 0b110 and then setting the baudrate so that it corresponds to the correct timing. You can then use DMA to send out a bunch of these sequences. Do we know if the BK7231N has spi-dma ?