8000 porting fastLED · Issue #6333 · micropython/micropython · GitHub
[go: up one dir, main page]

Skip to content

porting fastLED #6333

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
kdschlosser opened this issue Aug 12, 2020 · 8 comments
Closed

porting fastLED #6333

kdschlosser opened this issue Aug 12, 2020 · 8 comments

Comments

@kdschlosser
Copy link

I am working on porting the fastLED library to MicroPython. While I am proficient in Python I am not in C/C++. If there is someone willing to lend a hand with porting the driver end of the code it would be greatly appreciated.

My goal is to keep as much of the API in tact as possible so anyone using fastLED would be able to convert their code to run in MicroPython fairly easily.

I am also curious to see how much interest there is in this being done. I also did want to mention that I would also be extending the port to include RGBW LED's

@dlech
Copy link
Contributor
dlech commented Aug 12, 2020

I think the simplest thing to do would be to leave the FastLED code as-is. Then write a .cpp file that exposes what is needed as extern "C" (and fills in any missing Arduino functions, if needed). Then write a .c file that uses the new C API to create a MicroPython module.

@kdschlosser
Copy link
Author

If it was done that way wouldn't you need to use something like Cython to compile it because the code for FastLED is CPP???

@dlech
Copy link
Contributor
dlech commented Aug 12, 2020

Yes, perhaps something like this.

Or you could just compile it at the same time as the rest of MicroPython and create your own firmware.

@kdschlosser
Copy link
Author

That PR is about converting from .elf to .mpy not compiling an extension written in C/C++ to an extension that MicroPython would be able to load. Also because of all of the code in FastLED that is specific to directly accessing the hardware I think that there may be more issues with getting it to work then what it's worth.

There is another downfall. No support for 32 bit and above colors. only RGB. This is something people have been asking to get updated in Fast LED for 4 years and it still has not been done. This is something that can be done easily making this port. The reason I say it's easy is because we can pass an array of integers along with the bit depth to be used. The driver would use that bit depth to send out the correct number of bits. The order in which the bits need to be formatted would be done before passing the data to the driver. This way if a chipset gets extended like what was seen with the ws2812 where an extra color is added and the bit order gets changed even a user would be able to write the code needed to handle that and pass it to the driver to be sent.

I have a large portion of it already ported at this point (about 50%). The parts that would need to be written in C code are the drivers for the various LED chipsets. code that is similiar to what is seen in neopixel_write. This needs to be done in order to have the speed to keep the timings correct. From looking at the code for neopixel_write I cannot imagine it would be that difficult to write the drivers. I have looked at quite a few of the chipsets that are available and there are only small differences in how the data stream needs to be formatted. The largest difference between them is the hardware communication type/speed.

@kdschlosser
Copy link
Author
kdschlosser commented Aug 17, 2020

OK I made a repository for this port. The conversions I have done already have been committed and pushed already. If I had to put an amount on it I would say that I have converted between 75% and 80% of the code that needs to be converted to Python. I have not added support for RGBW just yet. Because FastLED heavily uses HSV adding RGBW support is going to be challenging. I have not been able to locate a conversion to convert from RGBW to RGB which is what would need to be done in order to utilize many of the "goodies" in FastLED. This is what I have found that discusses this kind of a conversion, it only really dives into RGB to RGBW conversion and not the other way around.

https://stackoverflow.com/questions/21117842/converting-an-rgbw-color-to-a-standard-rgb-hsb-representation

I have not done to much digging as of yet and I am sure that I will come up with something once I get the library up and running and can run tests on it. There is going to need to be adjustments made to the RGB channels so the color is not washed out when converting from RGB to RGBW. The problem with the above solution is that it uses min() and max() so there would be no way of knowing what the RGB values should be reverted to when converting from RGBW to RGB. Math that can be reversed is what needs to be used in order to be able to convert both ways. Possibly using percentages of each channel to determine the brightness needed for the white channel is the mechanism that needs to be used.

here is the repo for the port.
https://github.com/kdschlosser/micropython_fastled

@mbtronics
Copy link

Hi, I was looking at your micropython_fastled repo, but I have no idea how to compile/include it in micropython.
I can compiling micropython, including user modules, but that is with a micropython.mk make file.
Are there any instructions how to compile your fastled module?

@kdschlosser
Copy link
Author

@mbtronics

open up an issue in my repo and I will discuss the library with you.

tannewt pushed a commit to tannewt/circuitpython that referenced this issue May 12, 2022
fix qtpy_esp32s3_nopsram neopixel pins
@jonnor
Copy link
Contributor
jonnor commented Jul 2, 2024

I believe this issue can be closed, as there is a dedicated repository linked - where any further discussions can be had.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants
0