Over-engineering an RGB LED strip: let’s make a custom programming language
1–10 of 22 posts
Re: Over-engineering an RGB LED strip: let’s make a custom programming language
#2You had me at Lua. It's cool to think that runs on an RGB strip. I'd do it there but kudos on going all the way down!
Re: Over-engineering an RGB LED strip: let’s make a custom programming language
#3How did you implement "sleep"? For timing the effects?
I see a 'get_precise_time' command. I guess you could poll that, if you aren't worried about power use. (LEDs using far more power than your CPU.)
Re: Over-engineering an RGB LED strip: let’s make a custom programming language
#4How did you implement "sleep"? For timing the effects? I see a 'get_precise_time' command. I guess you could poll that, if you aren't worried about power use. (LEDs using far more power than your CPU.)
The interpreter will throttle the program to a certain frame rate - it will suspend the program on each ‘yield’ instruction and resume the program when a new frame is needed. It can also ignore the yields to get as high a frame rate as possible. Programs should not poll but use get_precise_time to draw what is necessary for that time stamp.
(And yes, the LEDs use way more power than the CPU here)
Re: Over-engineering an RGB LED strip: let’s make a custom programming language
#5This is very cool. And very generalizable, there are many situations where you want something like a scripting language for a MCU, and the VM implementation here is very straightforward.
Re: Over-engineering an RGB LED strip: let’s make a custom programming language
#6This is nice. I once tried to get programmatic animations running on MicroPython, but it seemed to fail to load even the simplest color conversion class (I didn't have an ESP32 back then).
I also tried streaming patterns (could've been really cool to hook it up to something like ColorCord), but my Wifi connection was definitely also too unreliable for that (hmmm, what about PoE LED strips?).
There's some project based on Javascript (I think) with in-browser previews for the patterns, but it's proprietary and only sold as pre-flashed modules. I forgot the name, but I think it has been posted here.
This bytecode-custom-language solution definitely looks over-engineered (wish I could use a language I already know to make an animation), but damn, it should be efficient. I think I'll play around with it bit.
Re: Over-engineering an RGB LED strip: let’s make a custom programming language
#7I'm surprised you didn't use floating point math, it seems cumbersome to make animations that way. My attempt at programmable LED strips used Lua (like that: https://gist.githubusercontent.com/Milek7/760a683f3480a4ff95...), though they were driven directly from Linux SBC. https://milek7.pl/.stuff/26gru.webm
Re: Over-engineering an RGB LED strip: let’s make a custom programming language
#8Related: a multi-program programmable LED strip (in Lua, allows the led strip to be split up into multiple segments) https://zeus.gent/blog/21-22/ledstrip_sandbox/ with the code on https://github.com/ZeusWPI/ledstrip_sandbox
Re: Over-engineering an RGB LED strip: let’s make a custom programming language
#9I'm surprised you didn't use floating point math, it seems cumbersome to make animations that way. My attempt at programmable LED strips used Lua (like that: https://gist.githubusercontent.com/Milek7/760a683f3480a4ff95... ), though they were driven directly from Linux SBC. https://milek7.pl/.stuff/26gru.webm
Floating point is just not very fast on ESP8266 (I believe it could even be softfloat, so emulated in software?).
Nevertheless it shouldn't be that difficult to change the interpreter to use floats instead of ints as base type (mixing the two would be more involved I think).
Re: Over-engineering an RGB LED strip: let’s make a custom programming language
#10Related: a multi-program programmable LED strip (in Lua, allows the led strip to be split up into multiple segments) https://zeus.gent/blog/21-22/ledstrip_sandbox/ with the code on https://github.com/ZeusWPI/ledstrip_sandbox
This looks cool! Lua obviously is a much more mature language. I'd expect it to use a fairly complex interpreter (LuaJIT is not available for esp8266 I assume..) so this is likely a bit less efficient (even though the Lua interpreter is probably well-optimized, it is simply more complex) but obviously much more functional than my toy language.