Bootloader for Teensy 3.1 that supports Bluetooth

Status
Not open for further replies.

cclavio

Member
Does anyone know how hard it would be to re-write the teensy 3.1 bootloader to support uploading new sketches via bluetooth? I purchased a HC-06 bluetooth module thinking uploading new sketches over bluetooth would be as easy as connecting power and the serial pins. Unfortunately, I found out after the fact that uploading new sketches is handled by the bootloader which is currently only set up to work over a wired USB connection. Connecting the serial pins is only good for bluetooth (serial) communication on a running sketch. This functionality would be very useful for applications where the teensy is installed in hard-to-access places.

Is this a feasible idea? How difficult would it be? Currently, reprogramming a bootloader is far beyond my skill level. There are two other posts in the forum that address this topic but there is no conclusive answer. They are also both from several years ago. They are linked below for reference. Any input or suggestions are welcome. I'm sure this functionality would be a valuable asset to the maker community.

Teensy 3.1 - programming over Bluetooth connected to pins 7 & 8 - Last post 2014
Teensy 3.0 Re-program wirelessly - Last post 2012

Best,
Chris
 
My understanding is that this clashes with the 'unbrickable Teensy' concept since reliable bootloading really requires offboard hardware that you don't touch as the main IC wipes it's brain (an tampers with things like clock registers) to put things back together in the event of a power outage/reset/corrupt load. The Teensy3 has this in the mini54 but it isn't configured to take a serial data input. So while a wireless teensy would be wonderful doing it properly means custom, or at lest more complex code in the already fully utilised companion IC and a redesign of the PCB to bring out some pins to allow streaming data to it. Doing it badly leads to dead products and a tech support death spiral.

There has been some success with people using a raspberry Pi using the command line installer to download hex files via USB, which works well if you are after 'global internet accessible reprogramming' but less useful in the 'I want to reprogram the unit in the roof'.

So unfortunately I don't think we will see a wireless Teensy unless somebody does the requisite design legwork (and some massive multiple OS user testing) or Paul manages to clone himself a couple times.

GW
 
Ok, after more digging and a reply from stevech on the Teensy 3.1 - programming over Bluetooth connected to pins 7 & 8 post, I learned that a solution is possible but requires some heavy lifting from some EE gurus. There is currently no off the shelf solution for uploading a new sketch over bluetooth but hopefully a solution is underway. You can read about that discussion here. You can also take a look at uTasker's USB-MSD and UART boot loader for Teensy 3.1 post which is certainly in the ballpark but would need modification to support uploading over bluetooth. Thanks to everyone who is actively working on a solution! Hopefully there will be a solution in the coming months that allows novice makers like myself to upload some pre-written code and, presto!, be able to upload a sketch from the Arduino IDE to the Teensy 3.1 over bluetooth.
 
Thanks GW, that is indeed what I found after more research. I love the idea of using the RasPi with a command line installer to download hex files via USB, although it seems like more work than it's worth as my projects are of the 'I want to reprogram the unit in the roof' sort.

Cheers,
Chris
 
Command interpreters are surprisingly simple to write. You wouldn't have the perfect flexibility of being able to upload a HEX file, but you could get something working quickly and you could transmit new programs by any means that you can transmit data such as Bluetooth.

Here's an outline of how it could work:

Before you installed the Teensy, you would program it with a sketch that was able to accept new instructions. The sketch would have two arrays, let's call them pgm and mem. Each entry in the pgm array would be one instruction containing an operation code and a little bit of other data needed to perform the operation, such as a couple of small values or indices into the mem array. The main loop of your sketch maintain a program counter which is simply an index into the pgm array. It would use the operation code of instruction as the selector in a switch statement. Each case of the switch statement would evaluate the corresponding instruction. If you have instructions for logic operations, memory assignment, conditional branches, arithmetic and I/O, you could by changing the contents of the pgm array, reprogram your Teensy. You would probably also want to add support for operations relevant to your particular application, such as controlling peripherals.

In my Morse code application, I have a command interpreter that accepts commands via a serial terminal emulator. I didn't add commands to make it reprogrammable in a general way as I described above, but it wouldn't be a difficult change. There's a function dispatchOnStack() that essentially treats the stack as a little program fragment for responding to a command. It would be straightforward to take instructions from an array or string instead of from the user at a terminal. It would also be straightforward to store an instruction string or replace a stored instruction string.

The key idea is seeing instructions as data.

A common objection to this approach is that it is inefficient. Yes, there's overhead from adding another level of interpretation on top of what the CPU already does. However, for most of what we build, it doesn't matter. And when it does matter, that functionality is a good candidate for having dedicated operation codes defined for it, rather than building it up from more elementary operations.

Another common objection is that inventing your own programming language fraught with peril. This is true, but the perils come when you try to scale the solution beyond a single small team building a single application. If you find yourself heading that direction, pick a good scripting language and make your interpreter a subset of it, or better still port that scripting language. Python, Lua, and Scheme are three good languages that work well on very small processors.
 
Today Teensy only supports USB-based programming.

Alternate ways are on the long-term possible feature list, at least to consider, but there's no solid, near-term plans. Sorry, there's only so much I can do in the fixed number of hours per day. A lot of other stuff is planned for the near term...
 
A little off topic, but we have a chrome app (javascript) which we use to communicate with a device we built on top of the Teensy (the MultispeQ... the project is called PhotosynQ and can be found at www.photosynq.org). We are suggesting that advanced users, who may need to update the firmware on the device, download the teensy loader. Ideally we'd like to integrate the teensy loader (or something with similar functionality) into the chrome app to make the user experience more fluid. The other options is, when the install the chrome app we identify their OS and direct them to download the teensy loader.

So, is it possible to fairly easily integrate any of the above mentioned options, or the teensy loader itself, into a chrome app? If not, we'll just go with link to download teensy loader.

Thanks,

Greg
 
A little off topic, but we have a chrome app (javascript) which we use to communicate with a device we built on top of the Teensy (the MultispeQ... the project is called PhotosynQ and can be found at www.photosynq.org). We are suggesting that advanced users, who may need to update the firmware on the device, download the teensy loader. Ideally we'd like to integrate the teensy loader (or something with similar functionality) into the chrome app to make the user experience more fluid. The other options is, when the install the chrome app we identify their OS and direct them to download the teensy loader.

So, is it possible to fairly easily integrate any of the above mentioned options, or the teensy loader itself, into a chrome app? If not, we'll just go with link to download teensy loader.

Thanks,

Greg
have you seen the generic bootloader with medium-of-your-choice (serial flash, sub-GHz wireless, BLE, Ethernet, etc.) - from uTasker? It's been talked about on these forums if you wish to search.
The concept is to coexist but use the Teensy loader rarely for certain kinds of updates.
 
Hi, unsure about the Chrome integration but you can get the command line teensy loader here
https://www.pjrc.com/teensy/loader_cli.html

Which may provide the tools to allow your ap to update the device code. I have seen several discussions on it but must of the success stories have been people using custom hardware to remote flash Teensy's (Rpi) or doing bulk burns rather than integration into customer software. Even with the source code provided suspect you don't want to do your own version of the USB protocol used to download the data.

Still should at least allow you to offer a dedicated installer with a single hex file + script as an option for those seeking the least painful option to update.

And reduce the chances that someone will load 'blink' to your device.
 
FYI,

I *just* successfully used a modified version of uTasker's SerialLoader to flash my teensy with an HC-06 bluetooth module. Yay!!!

The secret moves are:

1) Set baud to 38400 so that we can...
2) Turn off flow control since the HC-06 doesn't do a good job anyway (possibly could use HW flow control but didn't want to use extra pins)
3) It's somewhat slow, flashing a 33K binary took a solid minute+.

However... IT WORKS!
 
Any news?

it would be great to be able to upload sketches via bluetooth!


Today Teensy only supports USB-based programming.

Alternate ways are on the long-term possible feature list, at least to consider, but there's no solid, near-term plans. Sorry, there's only so much I can do in the fixed number of hours per day. A lot of other stuff is planned for the near term...
 
Status
Not open for further replies.
Back
Top