WS2812B Machine code serial side loader (in leu of wireless reprogramming)

Status
Not open for further replies.
Since programming the Teensy is only possible via USB (as I understand it) I would like to create a side loader for loading compiled WS2812 patterns via bluetooth (or any wireless) serial. I envision it as such:

1. Load the side loader onto the Teensy via USB
2. Write a C function that draws the LED array and compile it with a special compiler
3. Compile the C function to machine code and send to the side loader on the Teensy via serial

With this, a simple $10 Bluetooth Serial module would give countless LED projects wireless reprogramming.

The C function "pattern" might take three arguments:

1. The LED byte array to modify
2. The length of the LED byte array
3. An integer parameter incremented by one before every call (to provide state if the LED byte array itself is not the state)

The side loader might look like this:

1. A timer interrupt that checks the serial link for a new pattern (perhaps a "start sideload" command followed by length of data to read from serial.) The data read from serial overwrites the previous pattern in memory and/or flash.
2. A loop that calls the pattern drawing function repeatedly

The pattern compiler might look like this:

1. Take a C code file with pattern function (but no main()) and compile it to machine code
2. Write the machine code over the serial link to the Teensy


The part I don't quite understand is compiling a function to machine code, copying it over the serial link, and invoking it on the Teensy. I believe it's possible as it's not unlike a simplified boot loader or even a computer virus.

Can anybody point me in the right direction?
 
If you're willing to try a much easier direction, I would suggest you compile an interpreter to run on the Teensy. To change lighting patterns, etc. send a new script to the Teensy. Incremental loading on an embedded system is much harder to debug than getting a simple interpreter to run a new program. You could either use an interpreter someone has already created; or you could write your own domain specific language. My Didah project contains a command interpreter and demonstrates persistent memory via the built-in flash EEPROM. Instead of storing simple settings, you'd store scripts.

Here's a thread on the forum from someone trying to do what you want to do here. Didn't find out if it was ever done successfully.
 
Thank you for the alternate suggestions.

I don't see an interpreter that meets my needs (supports teensy 3.0 or higher, low memory footprint.) Writing a domain specific language could indeed be useful for WS2812's, but at this point I would rather use a C or python dialect.

Bambilight is a good example of using those cheap bluetooth modules and driving non-sequenceable LEDs, but doesn't really address my core requirements for side loading algorithmically defines LED patterns.

Unless someone who understands boot loaders and compiler linking internals comes along and points me in the right direction, I see two options:

1. Learn boot loaders and compiler linking internals myself
2. Use the trinket boot loader (or similar) which works via serial on some attiny85s and find a work around for driving larger number of LED arrays (possibly with multiple attiny85s in parallel)

I really hope Paul implements a general solution for wirelessly reprogramming the Teensy soon. I've used 30ft USB repeater cables in several projects but that was such a huge pain.
 
I suspect Teensy 3.x boards (not DIY clones) won't get over the air reprogramming as exists for AVRs. (Including the RH based one I have).
Due to the lack of a bootloader within the memory space of the K20. There's a defensive dimension to this- that being anti-counterfeits. A dilemma when a reliable income is needed from open source hardware.
 
Another approach could be to use a Raspberry Pi for programming the Teensy.
You could connect via Bluetooth to the RPi which would load the incoming file to the Teensy.
Only the batch processing on the RPi needs to be solved which might be much easier than writing an interpreter.
 
Another approach could be to use a Raspberry Pi for programming the Teensy.
You could connect via Bluetooth to the RPi which would load the incoming file to the Teensy.
Only the batch processing on the RPi needs to be solved which might be much easier than writing an interpreter.
how would this work? The Teensy 3 requires a USB host connection to a computer using Windows or Mac OS (or some Linuxes) and the Teensy loader on that computer to link via that USB connection. How would Bluetooth apply?
 
I personally tend to think an interpreter going off a byte code stream would be a whole lot simpler that trying to reprogram a Teensy on the fly. Now, I'm not talking about an interpreter for something like java byte-codes (though you might have enough space in the Teensy 3.1 to host a java byte code, with paging to a SD card). I'm talking about something specific to the lights. Something like:

Turn lights 100 - 300 blue
Turn lights 301 - 400 green
Show
wait 1 second
set var = value
set var--
if var == 0 go step 1

Now, you have to think about what kind of states you need to show lights, what kind of looping you need, etc. You can initially store this information in an array, and later have some way of down loading a new copy, etc. If your 'programs' get complex enough, you would need to swap portions to a SD card.

Alternatively, since the ARM is not a Harvard architecture, you should be able to enable execution in SRAM, and you set aside a fixed portion of SRAM, that you can load code into and then jump to it. This requires a lot of coding to establish conventions, for example, having a structure that has pointers to all of the functions you would need to call, so you don't have to deal with a symbol table.

This is also the EzPort functionality on pin 33 that people trip over at times.
 
how would this work? The Teensy 3 requires a USB host connection to a computer using Windows or Mac OS (or some Linuxes) and the Teensy loader on that computer to link via that USB connection. How would Bluetooth apply?
1) Install Rasbian on the RPi
2) Attach an USB cable and connect it to the Teensy
2) Attach Bluetooth dongle to the RPi
3) Configure for receiving files via Bluetooth
4) Teensy loader for Raspberry Pi?
 
If it were me I'd do (3) via a USB WiFi adapter so I could do regular TCP/IP-ish stuff, e.g. FTP/SCP/Rsync/Samba file access, SSH for controlling (and editing?), and maybe even a web server to control the blinkies.

Actually if I were going to go that route I'd probably just write a small program on the Teensy that copied bytes from the USB serial into the OctoWS2811 buffer (maybe even just the VideoDisplay.ino example that comes with the OctoWS2811 library), and do all animation routines on the RPi.

[edit] Serendipitously, right after I post this I see someone kind of already doing it this way: http://forum.pjrc.com/threads/26307-Teensy-USB-write-speed-from-Raspberry-Pi
 
Last edited:
I am now considering using this:

http://punchthrough.com/bean/

The documentation is infuriatingly myopic. Specs page? Who needs a specs page.

It supports re-programming via bluetooth 4.0 LTE and will cost no more than a teensy + bluetooth module (with less wiring too!) The MCU is a ATmega328P (good lucking finding that info on the website!) It took me 10 minutes to even find the dimensions (I had to look at the layout file!)

But that said, except for the lack of DMA octows2812 capability and poor documentation, this is exactly what I am looking for. I hope Paul considers implementing a feature like this in the very near future (the Bean uses punchthrough's own bluetooth module which they are aggressively pricing: http://punchthrough.com/products/lbm313-module/)

Adafruit and arduino should be doing the same thing as fast as they can too.
 
Bear in mind, you are limited to the ATmega328p limitations (in particular, 2MB for memory, which limits the number of neopixels, but also no DMA equivalent to octows2811, and only a few pins available to control things). Obviously, the coin cell battery will not be usable long for the leds, so you will have to power it yourself. Given it is optimized for low power uses, it likely runs at 3.3v (or lower), which might mean problems with neopixels (3.5v being what the spec sheet for ws2812b is the lowest voltage). I didn't bother to look at what voltage it expects from the battery pin. Hopefully it will accept li-pos at 3.7v, which if it runs at 3.3v, it means you don't need level converters to deal with the neopixels. Being able to be re-programmed via radio, opens up security issues, if you are worried about them. Finally, bluetooth in general needs to be close by, so in my eyes, you are not gaining much by going with bluetooth programming over using a conventional usb.
 
Last edited:
MiechaelMeissner,

Yes it is unfortunate that DMA and octows2811 are out of the picture as I mentioned in my post too. For my applications, bluetooth range is perfect while USB is nothing but a head ache. I build things into small spaces in awkward locations so every single extra wire is a pain. I write procedurally generated patterns so I can easily manage the memory limitation. Now that constant current LED controller chips are the norm I even prefer dealing with 3.3v chips since I have gone to great lengths in past projects to deal with high power DC-DC conversions in small spaces.... one the components most likely to fail.
 
The documentation is infuriatingly myopic. Specs page? Who needs a specs page.

... and poor documentation....

I'd be very careful with such products. They tend to be over-marketed and often underperforming. The CC3000 WiFi module from Ti promised mDNS capabilities which would have allowed easy integration e.g. into ZeroConf networks e.g. Apple's Bonjour. The totally incomplete and rudimentary implementaion infuriated more than one user if one can believe the comments on their forum.
 
I'd be very careful with such products. They tend to be over-marketed and often underperforming. The CC3000 WiFi module from Ti promised mDNS capabilities which would have allowed easy integration e.g. into ZeroConf networks e.g. Apple's Bonjour. The totally incomplete and rudimentary implementaion infuriated more than one user if one can believe the comments on their forum.

every product ever...
 
Oh, depends on an RPi.
at step 2), may as well connect to a laptop or other computer, eh? The RPi has to have a keyboard and display, may as well use a laptop with OSX or Windows.

On my RPi ( which gets rare usage) there's a USB WiFi, and the RPi boots to a config with a VNC server. So a computer on the LAN can VNC into the RPi which runs headless.
Well, that's on a tangent to this thread.
 
Another thing to consider, there is a micropython effort going on. At present, it doesn't allow re-loading of the python script via wireless, and it doesn't have ws2812 support built-in, but those can be worked on: http://forum.pjrc.com/threads/24794-MicroPython-for-Teensy-3-1
I was all jazzed on playing with Teensy microPython - until recently when I read that it maxed out the 256K of the Teensy 3.1 and capability-shedding has already begun. I had a hunch this would happen, as Python's C interpreter is big and complex. I think the microPython dedicated MCU board is 1MB.

Interesting parallel.. I worked a lot with Digi International's embedded python on their ConnectPorts. Not a Linux environment. Uses a custom RTOS. Their Python environment uses the same concept as micropython is.. a zip file is 'mounted' as a file system. You put all your needed py and pyc files in a zip, move that to the target embedded by whatever means (often, TFTP), then Python starts up with this file system. Awkward, but a decent work-around for a fixed embedded system without a GB mass storage device but rather, a few 10's of MB of flash. Like the 16MB Spansion SPI flash chip I'm working with, whose cost is like $1.25.
 
Last edited:
Status
Not open for further replies.
Back
Top