search

tinue / apa102-pi

Pure Python library to drive APA102 LED stripes; Use with Raspberry Pi.
GNU General Public License v2.0
202 stars 72 forks source link

I changed the Code a bit to make it run on an micropython ESP8266/8285 #33

Closed mindforger closed 6 years ago

mindforger commented 6 years ago

but this will break ith the original code, so branching would be an option

i had to add an selectable chipselect and the changed the pin mapping tomatch the hardware SPI, but it shouldn't be changed at all except for the chipselect because i have no idea how to use the bitbanging SPI on the ESP.

The SPI from micropython requires arrays to work with and the list(self.leds) call made the ESP run out of memory.

There is also no SPI.close() but i added memory cleanup as the script tends to block up a good amount of memory that has to be reclaimed to work properly.

The show speed is awesome and is somewhere around 1ms/10LEDs@1Mhz ... there is quite some overhead depending on how much LEDs you are using but with 8Mhz and 100LEDs it is 2mS in preparation and the startframe, 1.5mS for the actual LEDs data and a little more than 1.5mS for the end frame around 5mS for 100LEDs in total and arund 6mS total for 300LEDs

mindforger commented 6 years ago

added a picture of my setup

https://puu.sh/BfaLh/3293deeee3.jpg

lower rail is 5V, and the upper 3.3V is powered through the ESP module (resistor in series because inserting the SD rebooted the ESP) the Gate is an74HC132 quad nand with schmitt triggers and i wired in the CS so SD Card and LEDs can coexist, as long as micropython does not access the SD during a call from the script (like in between raising and dropping the chip select)

outputs are those red marked ones, clock at the lower and data on the upper side, double inverted

mindforger commented 6 years ago

another update, i am having several performance issues with setting the pixels and how theendframe is done, i am still working on it and will update as soon as i have something more clean and faster ... omitting the loop and simply using bytearray(n) with n being the formula used in the loop head worked wonders at speeding up the end frame, now i have to find out why the start frame takes 2ms ... maybe calling methodes is not handled well by the ESP

jerobins commented 6 years ago

Just curious, have you tried it on an ESP32? What your describing is exactly why folks are looking at the 32 to replace their 8266's. Similar power requirements with 2 cores and double the clock (reliably).

mindforger commented 6 years ago

I got one but the bluetooth gives me headache and micropython was not available back then... I may switch over

tinue commented 6 years ago

Sorry for not answering earlier, I'm currently a bit underwater. I like your idea, thanks! I have a number of ESP8266 lying around (and some ESP32), but never tried MicroPython so far. I'll definitely give it a try. I started a branch "gpiozero" a while ago, but so far didn't get anywhere. It does look a bit similar to the Micro Python GPIO library, maybe they can somehow be unified. For now, until I find some time to try it out, please add to your pull request if you have further changes. Thanks again! Martin

tinue commented 6 years ago

One more thing: You might want to rebase, because I merged a branch that was tested successfully. There are no functional changes, but there was some restructuring to make the library installable.

mindforger commented 6 years ago

I thought i did, let me pull this straight when i am back at my pc

tinue commented 6 years ago

I only just fast-forwarded an hour ago, so it's entirely my fault that your pull request now has conflicts.

mindforger commented 6 years ago

oh now i see, don't know why github did not notify me. I will have to fix a few things speedwise before, also like i said earlier it may be better to leave this in a branch because it looks like uPython does not like some Syntax formats and the spi is quite different.

mindforger commented 6 years ago

oh well i totally blanked out on this one, and i did not find any time to work on improvements either, so i will have to delay my fixes until next weekend, but then i will have my LED tube back together and can work on the code again

so i close this one for now, sorry for not being very productive on this one yet :(

tinue commented 6 years ago

No problem! I created a branch that you can use if you want to make another pull request. Right now, it's just a copy of "master". So far I managed to find a NodeMCU assembly, and could flash MicroPython to it. Now I need to stitch together the NodeMCU and an LED strand with a level shifter to get a test running. So far I didn't find time to do this, unfortunately.