Close

Multithreaded python on an embedded microcontroller

A project log for A Hacker's Wedding Centerpiece(s)

Im getting married :D. I've been put incharge of making the coolest* centerpieces ever! (*coolest acording to me)

bveinabveina 06/29/2018 at 22:040 Comments

TL;DR: time synchronization is hard.

TL;DR 2: Keep it simple stupid

ive been working on the firmware for the modules.  taking a page out of 

kitesurfer1404's playbook on github i made a python class to work with the APA102 Leds on the circuit boards.i defined many animation modes.

I went a little overboard on the next part though. i decided "Why not make this multithreaded and have one process for each led ring? ill treat the entire strip as a shared resource and use locks!" it it didnt work half bad. I reminded myself of a lot of OS concepts from back in school. had a great time.

For all of this i used the uasyncio library from [peterhinch] . its pretty great and i was easily able to get different animations running on different rings of the centerpiece, even though it was all on the same "strip"!

the striped down version is available for reference as a gist.

In truth if i only needed one centerpiece, id be done. it works great. the problem came when i loaded this onto half a dozen items at once. due to...physics (temp differences, crystal inaccuracy, you name it.) ... every esp8266 ran at a slightly different speed making things slowly drift out of sync. this was especially annoying when trying to strobe or blink every centerpiece at once.

Ill be honest, i spent weeks on this. i read RFCs i implemented NTP sync options. I couldn't overcome the inherent latencies of the system. one day i looked at the code base and saw that almost 40% of the lines were due to synchronization. i was pretty disheartened; I had started with an elegant solution (heaven save us from elegant solutions). but to support that elegance i had put so much lipstick on the proverbial pig....not really sure where that analogy goes...

I had to take a step back and come at this from a different angle, but, with the wedding getting closer i began to worry a bit.

then inspiration struck and i realized:

why am i letting these dumb nodes decide their own timing. i should just send every step of the animation and let a server decide the timing. this revalation came about as i was picking up some theatrical lighting from a friend, and reminded me there is already a networking protocol for "intelligent" lighting named artnet. i had never used it before.

and i said to myself:

"Surely it is far to heavy weight to run on a microcontroller!"  nope its a UDP packet.

"Surely ill have to implement this myself, right?" nope its been done.

"I bet the lighting control software will cost a fortune. ill need to write a quick and dirty driver." nope FOSS is pretty all encompassing

it only took about 2 hours to hook up everything. lesson learned. keep it simple.

now i just need to finish the battery packs! ...what is that burning plastic smell...

well that could be a problem. 

To Be Continued....

Discussions