Teensy loader for Raspberry Pi?

Status
Not open for further replies.
I have good news for you this morning, something I had not thought to try until now. It is possible to do the entire reload remotely if the Teensy is runing a sketch that has the teensyduino code running properly.

Paul's USB code interprets a request to set a "serial baudrate" of 134 bits/second as a request to reboot to the bootloader (this is the "USB controls" stuff that I referred to earlier). I've verified that it does exactly that, including loading a new sketch hex file. In the example below, the hex file is "dac_out.cpp.hex" ("dac_out" is my name for the sketch, your hex filename will be different). I've set up my workstation with libusb-1.0 but the pattern should still work for you.

Code:
$ stty -F /dev/ttyACM0 speed 134
9600
<<< At this point, the workstation's syslog shows that the teensy has indeed reset and restarted in its bootloader>>>
$ ./teensy_loader_cli -v -mmcu=mk20dx256 /tmp/build353870272024895909.tmp/dac_out.cpp.hex
Teensy Loader, Command Line, Version 2.1
Using libusb version is 1
Read "/tmp/build353870272024895909.tmp/dac_out.cpp.hex": 31252 bytes, 11.9% usage
Found HalfKay Bootloader
Programming...............................
Booting
$

After doing these two steps, the Teensy is indeed running the updated sketch hex file.

For this to work, the sketch must have Paul's magic "baudrate=134" USB detection code in an otherwise sane sketch. Hopefully, your teensy code is working well enough to interpret the control setting.

DO NOT place a reboot request in your sketch setup() function!!! (Actually, you are free to do that... It will cause the unit to force itself into bootloader mode instantly on starting...)

In case you don't already know, the basic Arduino executive pattern is simple: Execute the sketch function setup() once, then repeatedly call the loop() function in a while(1) {} loop. The basic idea is to put one-time-only init code in setup(), and put the main applicaton inside the loop() function. The code fragment is an illustration of how your application might reboot to the bootloader when the sketch decides that it wants to be reloaded.

Good luck, hope this helps.
 
That's great, Len! I just can't wait to try it, but I have to ask you few other questions.

1. After I load the new .hex file, does the Paul's "serial baudrate" reset still remains active in the new uploaded (.hex) sketch? I mean, do I have further chances to reload subsequent .hex files or it's just this one shot?

2. After I run "stty" command, Teensy it's running in bootloader mode no matter what? There's no testing purpose "stty" command, right? It's mandatory to load a .hex file next, am I get it straight?

3. Placing a reboot request in my sketch.. turns out to be a good or bad idea after all?

4. I have always used Arduino + Teensyduino for x86 linux (Linux Mint) to edit/compile/upload sketches on Teensy. Does it mean that I have used Paul's "genuine" reset code you've talked about?

5. I'm using the .hex code generated by the previous described setup.. it's OK to use it for generating the .hex file (then upload it using the RPi? BTW, the .hex file (solar.cpp.hex) has around 57kB.. is it too big or something?

Thanks in advance for your kind support.
 
Taking the questions one at a time...

  1. Yes, as long as the new sketch is built using the normal teensyduino software enviornment. As long as your sketch doesn't do something like lock up the unit, the code to interpret the serial-baudrate trick is always present in Paul's USB code and ready to be invoked for a subsequent firmware update.
  2. "No matter what" is a big phrase. That said, if the code in the sketch has not failed in a hard-lockup way, the teensy will be in bootloader mode after the stty command. I strongly suggest only doing the stty trick when the next act will be uploading new code. It is possible to verify that using either lsusb or monitoring the host's (the RPi) syslog to see that the eendorid/productid (vid/pid) of the teensy USB device matches bootloader VID/PID.
  3. Whether your application should provide a means for invoking the bootloader reboot is up to you, the application designer. If the stty baudrate mechanism satisfies your needs, then it's not necessary to implement an application-specific mechanism.
  4. The graphical loader very likely uses the same technique under the covers that the "stty" does. I am treating them as essentially equivalent.
  5. I think your hex file will work just fine. The Teensy 3.0 has a limit of near 128kB, the teensy 3.1 has nearly 256 kB code size. A hex file can be assumed to be about 2.1 times the size of the code (each byte of code is 2 hex digits, and there's a bit of overhead).

Unstated in all of these posts but should be explicit: VERIFY your work locally before trying it remotely. I've been at this remote software thing for a long time, and tend to forget that it may be necessary to emphasize this.

My teensy 3.1 has 16c0:0478 when running my application, and has 16c0:0483 when running the bootloader.
 
Well..

.. IT WORKS!!

My humble respect goes to Len Samuelson and Paul Stoffregen!.. everything worked as Len has suggested. Not a single error at all!

I've got 16c0:0487 while normal operation (Serial+Keyboard+Mouse+Joystick) and 16c0:0478 while in bootloader mode.

Finally, I could fully (remotely) manage all three Teensy boards connected to RPi.

Keep up the good work, guys! I'll stay around for more valuable knowledge.
 
Please accept my apology for getting the PIDs wrong, and thanks to Paul for monitoring the forum.

Glad to hear that the remote update worked for you.
 
Len, you were a (batteries) life saver! (and I have 8 of them)

I've posted those PIDs for reference only. Once again, BIG thanks to you!
 
I've uploaded an experimental build of Teensy Loader and Teensyduino's 4 utils.

http://www.pjrc.com/teensy/loader_linux.html

I did manage to reprogram a Teensy 2.0 and I confirmed teensy_reboot is able to find and reboot a Teensy. Of course, the udev rules must be installed to run as a non-root user. So far, not much other testing has been done, so it's labeled "experimental".

Please let me know if this works for you?
 
Hi Paul,

The raspberrypi experimental loader link appears to be broken. The link location is

http://www.pjrc.com/teensy/teensy_raspberrypi.tar.gz

Perhaps it makes sense to try tomorrow; it's getting late here, and I hope to be awake to see the SpaceX first-stage return to a floating platform. The launch is scheduled for 6:20AM (east coast).

Not Found

The requested URL /teensy/teensy_raspberrypi.tar.gz was not found on this server.
 
The files from that link should be placed in /hardware/tools folder (Arduino IDE). But what about the /hardware/teensy folder? Should be copied from a x86 linux (Teensyduino) installation?

Was your suggestion about manual running of Teensy loader (not from Arduino IDE)?
 
Yes, this is only the GUI loader and those 4 utilities. It's not a full package for the Arduino IDE.

I may yet make a full package with a Teensyduino installer, maybe. But a major problem is Arduino doesn't publish a download for Raspberry Pi. I do not support the distro packages of Arduino, partly because supporting modified copies with a different release schedule would tremendously increase my maintenance for Linux (which is already 2 of 4 release files, despite being a tiny fraction of the entire user base), but also partly because most of the distro packages are horribly old.

I just installed Debian's (Wheezy) arduino package. It's Arduino version 1.0.1, which released in April 2012. Teensyduino only supports 1.0.5 and 1.0.6.

Of course, there are plenty of other technical obstacles, which all boil down to compiling and testing stuff on Raspberry Pi far too slow and frustrating. But those are solvable with patience (admittedly, not one of my stronger points, especially patience for computers!)

The lack of an official Arduino release for Raspberry Pi is a huge obstacle for making a Teensyduino installer.
 
Last edited:
FWIW, since yesterday I put my Raspberry Pi in the closet, so it's not taking up space on my tiny workbench, and set it going on building the ARM Launchpad toolchain. Well, actually, on the preliminary step of building the native compiler.

It's hitting an error, several hours into the process, which appears to be related to Debian's filesystem structure being somewhat different than what ./configure for that version of gcc expects.

I'm on the 3rd try now. Reinstalling a bunch of stuff with apt-get was fruitless, with the same error after several hours. This time, I edited the build script a bit. It's probably still another hour or two until the part where it would hit that error, and the error seems to be somewhere in the first bootstrap stage for gcc, so there's a long way to go. If there are more errors, each try is likely to set things back at least a day. Hopefully there'll be no more errors, and this preliminary build might be done by the end of this week.

Then maybe I can build the actual toolchain. Without more errors (perhaps overly optimistic), maybe I'll end up with a Raspberry Pi compile of the toolchain for 1.21-test2 by the middle of this month?

But if more build troubles need to be resolved, this process could easily stretch into February or March or longer!


My desktop PC recompiled the whole thing in about 20 minutes (for the 64 bit Linux PC version). But I just don't have the engineering time to put into setting up a cross compiling setup that works for this particular toolchain.
 
Last edited:
I've asked myself that question and assumed a similar answer. But the Raspberry Pi questions keep coming up. This work is a step from "only supported by the command line loader" to "basic tools are provided".

The toolchain compile hit another error after about 6 hours, so it's not looking good for a compiled copy of the 1.21-test2 toolchain.
 
The discovery of the baudrate setting is plenty for me, and truth be told, I should have recognized it long ago. Between that and the low-overhead linux command line loader, it adds up to being a straightforward implementation that produces predictable results. The Arduino stuff tends to be visual, and therefore doesn't fit my remote access use-case.

I cannot speak for others.
 
You already did alot for this cross community (Arduino+RPi), Paul. You were right, there's no good reason to further spend your time and effort with those RPi issues.

Personally speaking, the ability to upload a sketch (the .hex file) using RPi is absolutely enough. This way, one could easily use (and debug) Teensy boards for true remotely applications.

The discovery of the baudrate setting is plenty for me, and truth be told, I should have recognized it long ago. Between that and the low-overhead linux command line loader, it adds up to being a straightforward implementation that produces predictable results. The Arduino stuff tends to be visual, and therefore doesn't fit my remote access use-case.

I completely agree with Len (I wasn't looking for "visual" but for a practical solution).
 
After a few false starts to fix various compile errors, I'm happy to report the toolchain build appears to be working.

This latest build attempt was started almost exactly 24 hours ago. It seems to have made it though the newlib build (a very good sign) and it's rebuilding the compiler again. Maybe tomorrow I'll have a copy of the same toolchain as 1.21-test2 for you to try....

Still, there's many more steps needed before a full Teensyduino installer can be made, including finding the self-contained copy of Arduino 1.0.6 for Raspberry Pi.
 
Ok, here's another (untested) piece of the huge puzzle, to someday have a complete Teensyduino package for Raspberry Pi.

http://www.pjrc.com/teensy/beta/arm_toolchain_raspberrypi.tar.bz2

This is a Raspberry Pi version of the same toolchain Teensyduino 1.21-test2 places in hardware/tools when installing on x86-based Linux, and Windows and Mac.

Compiling the toolchain took only about 1.5 days (after days of false starts and retries)... much faster than I'd anticipated.
 
FWIW, I happened to have my camera pi up and running, and the teensy, teensy-reboot programs do seem to work on a Pi. Teensy-restart doesn't seem to actually restart the Teensy.

At least for me, the way to do it, was start teensy, use File->Open to open a .hex file that was created on my laptop, and then do teensy-reboot. However, I would need X running on the Pi to use teensy (I happened to be logging into the pi from my laptop and I used -X to provide a virtual display). Just to see if it worked, I started X on the tiny PiTFT screen I use (320x240), and the Teensy X module fit into the screen. I was able to load the hex file and program it from the PiTFT screen.
 
Hi

new noob here so sorry if it has been answered above somewhere and i did not catch it

but yes arduino ide is still 1.0.1 when it comes to the prebuild packages which is what i use due to my lack of knowledge and fear of building stuff myself

but my real Q is:

are there a step by step and for dummies guide on how to add teensy to the ide? on windows is easy enough, but raspberry pi i only figured it as far as the ide...

my 3d printer has a teensy based controller and i only need this to uploaded a sketch once in a while when i tweak a setting... the board has a programming jumper i remove and then press a reset button. i can live with that when i need to program
 
Status
Not open for further replies.
Back
Top