Teensy loader for Raspberry Pi?

Status
Not open for further replies.
Btw, I have binutils, and am working on building gcc as debs for raspbian. It's not all that slow: maybe 3-4 hours for the gcc build. I'm using a Sandisk Ultra Class6 card.

Not sure if folks would have any interest in this stuff packaged as debs...

-c

Definitely. That's what I liked about the Teensy++2, apt-get avr tools, download and compile the loader, and I'm ready to go. While I'm waiting on my Teensy3 order to come in, why are you needing to compile gcc? The gcc on raspbian already is an ARM compiler, and from the Makefile arguments, gcc accepted and compiled with the -mcpu=cortex-m4 so I was assuming that's what was required for the compiler. I didn't know what else was required to get a program that would load, filling in that blank would be appreciated.
 
Not all ARM compilers are created (or configured) equal. Has anyone actually used Raspberry Pi's compiler for Teensy 3.0?
 
Recent raspbian distributions are set up to use hardware floating point. Some cortex m4 chips have an FPU, but not the one in the teensy. There are some (older?) raspberry distributions that have softfp but the performance is so much better on the raspberry with hardfp that I have to assume most are going that direction.

Also, it's set up to use libc, not newlib. When using (a somewhat modified) Makefile from teensy 3 directory with raspberry pi, I get the following errors:

Code:
gcc -Os -mcpu=cortex-m4 -mthumb -Tmk20dx128.ld  -L../ustl-1.6/.o -o main_vfd.elf main_vfd.o analog.o eeprom.o flash.o glcdfont.o keylayouts.o mk20dx128.o nonstd.o pins_teensy.o serial1.o serial2.o serial3.o syscalls.o touch.o usb_desc.o usb_dev.o usb_keyboard.o usb_mem.o usb_seremu.o usb_serial.o yield.o HardwareSerial1.o HardwareSerial2.o HardwareSerial3.o IPAddress.o LiquidCrystal.o mac_addr.o Print.o sampler.o Stream.o usb_debug_hid.o usb_inst.o usb_midi.o WMath.o WString.o -lsupc++
/usr/bin/ld: errno: TLS definition in /lib/arm-linux-gnueabihf/libc.so.6 section .tbss mismatches non-TLS reference in syscalls.o
/lib/arm-linux-gnueabihf/libc.so.6: could not read symbols: Bad value

It might be possible to just compile newlib?

In any event I think hardfp is going to be built into the compiler and its support libraries and the presence of FPU instructions might cause faults?

-c
 
Last edited:
That LX Series card *finally* arrived. I ordered from Amazon and used their free shipping.....

In preparation for my next adventure into Raspberry Pi development, I tried benchmarking the 5 cards I own, and my laptop's SSD. The LX Series card is indeed fast, relatively speaking. Sadly, "fast" means 0.6 Mbytes/sec on the 4K random write test. My laptop's SSD gets 71 Mbyte/sec on that test!

Maybe I ought to get a USB-based SSD and use that as my root partition? Can anyone recommend a good one?

Here's the benchmarks on my laptop's SSD (for reference of what a good hard drive should do), and the 5 cards. Yes, I know a proper approach would be to actually benchmark them on the Raspberry Pi. But the point of this benckmarking is to NOT use terribly slow cards on the Raspberry Pi. The idea is to get a rough idea of each card's relative 4K random write speed.

My previous ill-fated Raspberry Pi adventure used the Transcend card, with it's horribly slow 17 kbyte/sec random write speed (the Sandisk Ultra would not boot), and of course there was lots of swapping to that Transcend card as I tried to compile large libraries and my own code.

View attachment 128View attachment 129View attachment 130View attachment 131View attachment 132View attachment 133
Paul, which SD card did you end up using?
 
So far it's only been ported for Linux. Here's the unreleased code.

http://www.pjrc.com/teensy/beta/load_linux_only.c

This should work fine on any Linux that has libusb-dev installed. It will not work on Windows, Mac or FreeBSD.

On a slightly different track (combining the best of both worlds, and making two steps one . . .):

I use socat to locally access the remote ttyACM0 of my Teensy 3.0 connected to an RPi (socat -d -d PTY,raw,echo=0 EXEC:'"ssh pi@10.0.1.3 socat - /dev/ttyAMA0,b115200,nonblock,raw,echo=0"') from the Mac I develop on. Is it possible to setup Teensyduino/Arduino to recognize the virtual local port as a valid serial port selection in the "tools" menu? If so, do I need to modify the socat parameters in any way? In this case, the pty is mapped to /dev/ttys002 on the Mac.

Alistair
 
I'm a proud owner of a teensy 3.0 and a teensy 3.1 (my teensy 2.0 i destroyed accidentl) as well as a raspberry B.
So I installed the Crosscompiler and tried to compile Pauls Commandline teensyloader, I run allways into the problem, that -lusb was'n recognized by the compiler Ialso tried linusb-1.0, but the two libraries ar not compatible).
Finally I pusched the load_linux_only.c code to the raspi and compiled there with:
gcc -DUSE_LIBUSB -lusb loads_linux_only.c successfully.

then I tried to download a hex file (comiled for teensy 3.0, because there is no switch for teensy 3.1) pluged in my teensy 3.0, but no device where found.
I commented out some printf lines (Paul already prepared) during search and found that the vendor-id is wrong.

When I plugin the teensy at my raspi I see:
/dev/ttyACM0 is present.
I also found that only with plugged in teensy I see a Product-id 0x0483 instead of 0x0478 which is expected.
And even when I chaet the Code, by expecting 0x0483 it can connect but not download:
pi@raspberrypi ~ $ ./a.out -v -mmcu=mk20dx128 SOS.cpp.hex
Teensy Loader, Command Line, Version 2.0
Read "SOS.cpp.hex": 15724 bytes, 12.0% usage

Searching for USB device:vid=16C0 pid=0483
bus "001", device "013" vid=16C0, pid=0483
Found HalfKay Bootloader
Programming.error writing to Teensy

Has someone an idea whats wrong.

An other question to Paul:
Is it correct, that the only change for teensy 3.1 (versus 3.0) is the code_size (code_size = 131072;) which I would habe to change to code_size = 262144; ?
 
Hi guys,

I am new to teensy 3.1. I have recently been trying to install teensyduino on raspberry pi. Has there been any update to this so far?
Also, I noticed the command line compiling only works for Windows. Has anyone discovered this ability on raspberry pi?

Thanks,
Ish
 
Hi guys,

I am new to teensy 3.1. I have recently been trying to install teensyduino on raspberry pi. Has there been any update to this so far?
Also, I noticed the command line compiling only works for Windows. Has anyone discovered this ability on raspberry pi?

Thanks,
Ish
RPi would be a v-e-r-y slow development computer!
 
RPi would be a v-e-r-y slow development computer!

Completely understand that, but I need that functionality in case I am not near the teensy board. I am trying to place the teensy board at home, while I would be at work. Just wondering if it is possible or not?
After quite vivid research, I have noticed that people have gotten teensy board (mostly 2.0) to be able to flash with RaspberryPi (Debian) while trying to mimic the teensy board as a USB keyboard + Disk <http://astr0baby.wordpress.com/2011/01/30/teensy2-0-and-metasploit/>

What do you guys think about this?
 
stevech: define slow ? I've done a lot of dev in the past on the pi with Arduino and it's not that slow...
 
I have no plans to support Teensyduino on Raspberry Pi.

Several people have managed to make the command line loader work on RPi. At least you can get the RPi to load new .hex files onto your Teensy.

Developing the .hex file on RPi isn't supported, and probably never will be. I have an incredibly long to-do list, which involves porting all known Arduino libraries, developing unique libraries like Audio, PulsePosition, OctoWS2811, and maybe even creating some more new products eventually. There's only so many hours in the day, so I must prioritize. Supporting development on the terribly slow Raspberry Pi is one of the few things I've decided simply not to do, at least with the current versions of Arduino that require a bloated Java JRE, and current RPi's limited memory and sluggish performance.
 
I'd think that anyone owning an RPi has a decent MAC or PC to use for software development. I see my RPi as a platform to run certain apps. Most of which I do in Python then copy verbatim to the RPi to run unattended. I have developed Python on the RPi and it's not too bad (using VNC to access from PC). That's OK. But I wouldn't want to do that with C/C++. My RPi uses SMB and a hard disk share on my NAS for storage, rather than the SD card on the RPi.

Truth be known, a little mini-ITX board running Linux or Windows is not much more expensive and is much faster.
 
I've had good success with compiling and running load_linux_only on various workstations, and on the BeagleBone Black (which appears to be permanently on backorder worldwide...).

With that said that, I use several other platforms. I have an odroid-U2 which is a wonderful little CPU (quad Cortex-A9, 2G RAM, USB host for disk). They've just released an Ubuntu 14.04 image.

UDOO quad (quad 1GHz Cortex-A9, 1G RAM, SATA disk) which has an Atmel SAM3X8E on board, $139 U.S., also has a reasonably current Ubuntu.

Odroid U3 ($65.00US + extras + shipping from South Korea), and odroid-XU ($139): http://www.hardkernel.com/

The Nvidia Jetson is serious overkill, but it's very tempting at $192.00. Quad A15 equivalent (I think) plus 192-core GPU.

The Minnowboard Max is coming soon with Intel Atom, $99.00 plus accessories.

There are other systems out there, too many to mention. LinuxGizmos has a list:

http://linuxgizmos.com/top-10-hacker-sbcs-survey-results/

I've added support for recent usblib 1.0 to load_linux_only in case anyone's interested. I would like to add at least one additional feature to it, to allow the command-line user to specify a particular Teensy3.x for upload, either using serial# or other filter criteria. Much yardwork, little time... I't on the way Real Soon Now... The usblib 1.0 port appears to be complete now, so anyone wishing for source should express their interest and I'll either start a github account or submit it here.
 
Thanks everyone for the response!
The reason I am using an RPi is solely to allow me to download a new hex code to the Teensy remotely. I understand the board is very sluggish and I could use another PC.
Now, I do know some people were able to use the compiler commands from Paul's site to flash the new hex code to the Teensy boards.

I have not been able to follow flash the hex code to the Teensy boards at all. The instructions on the website for command line compiling states that I must use the teensy_loader_cli to be able to flash the hex code. However, the teensy_loader_cli is an exe file. I am not sure how I can use that in linux.

p.s. I am still learning day by day about this (NOOB status)
 
Thanks everyone for the response!
The reason I am using an RPi is solely to allow me to download a new hex code to the Teensy remotely. I understand the board is very sluggish and I could use another PC.
Now, I do know some people were able to use the compiler commands from Paul's site to flash the new hex code to the Teensy boards.

I have not been able to follow flash the hex code to the Teensy boards at all. The instructions on the website for command line compiling states that I must use the teensy_loader_cli to be able to flash the hex code. However, the teensy_loader_cli is an exe file. I am not sure how I can use that in linux.

p.s. I am still learning day by day about this (NOOB status)


https://www.pjrc.com/teensy/loader_cli.html has the sources files.
 
The link provided by Paul allows downloading the teensy_loader_cli.zip file, which it appears that you've done, but using it depnds on an additional step of compiling its source code into an executable file:

Code:
$ pwd
/home/lcs/projects/teensy/teensy_loader_cli
$ make
cc -O2 -Wall -s -DUSE_LIBUSB -o teensy_loader_cli teensy_loader_cli.c -lusb
$

On my Ubuntu 13.10 system, the default usb library on which teensy_loader_cli depends is libuab-1.0 which has a different API from the original version. The rsult is that as delivered, it doesn't compile on my system. If you try compiling with the "make" command and it fails to compile, there are several things to try that should produce an executable result that you can used to load your Teensy. I do not have a Raspberry Pi so I don't know what to expect there.
 
I did, then symlinked "libusb.so" to the pre-1.0 library, which got it going.

That led to asking (and subsequently answering) how difficult would a port to libusb-1.0 would be. The answer is that it's not too tough, and that's the way I use it now. What I have not yet done is encode detection of which of the two choices (pre-1.0 vs 1.0+) should be used by the Makefile. At present, it depends on setting a variable in the Makefile or using a command-line setting ("USE_USBLIB_1XX").
 
I have no plans to support Teensyduino on Raspberry Pi.

Several people have managed to make the command line loader work on RPi. At least you can get the RPi to load new .hex files onto your Teensy.

Developing the .hex file on RPi isn't supported, and probably never will be. I have an incredibly long to-do list, which involves porting all known Arduino libraries, developing unique libraries like Audio, PulsePosition, OctoWS2811, and maybe even creating some more new products eventually. There's only so many hours in the day, so I must prioritize. Supporting development on the terribly slow Raspberry Pi is one of the few things I've decided simply not to do, at least with the current versions of Arduino that require a bloated Java JRE, and current RPi's limited memory and sluggish performance.

Hi, Paul

Could you point me to some resources about command line loader that works on RPi? I've searched the internet but I didn't find any feasible solution to actually use the RPi to upload .hex files onto a Teensy board.

I have a RPi (B+) connected to a Teensy 3.1 (actually, two of them) and I badly need to upload a modified sketch to one of those Teensy boards. I have no possibility to use a regular PC or something (Windows/Linux) as I don't have physical access to the Teensy boards (it's a remote location).

Thanks in advance for any help!
 
I'm guessing that by "command line loader" you are asking for a tool that will load the hex file into the Teensy. Two capabilities are required, but only one of those capabilities is implemented in the command line loader right now.

  • Send hex image to a Teensy running its bootloader -- Working
  • Request that the Teensy start the bootloader -- Not implemented

Several owners of Teensys have been successful in using the command line loader in situations where we have local desktop access: Pressing Teensy's reboot button forces the the Teensy into bootloader mode. (This is where the mini54 chip comes in, which is the basis of the unbrickable nature of the Teensy 3.x.).

As currently provided by Paul, the command line loader depends on libusb-0.1-x and should compile on any Linux machine with a compatible libusb, including the RPi. The command line loader requires minimal system resources, and should run very comfortably on the RPi.

That leaves the question of how to persuade the Teensy to start the bootloader. The obvious way, either press the button or temporarily ground the reboot signal (equivalent to pressing the button), requires access to the Teensy, either physically or electrically.

Another way is programatically. Paul's graphical loader sends USB control packets that the Teensy interprets as a request to reboot, which starts the bootloader, and subsequently loads the image. The function used to start the bootloader can be executed by the sketch on command. The following code snippet does an equivalent operation on request. In this code, upon seeing a substring "reboot" anywhere in a commandBuffer character array, the unit waits 10 seconds (to allow the user to disconnect a serial monitor or whatever), then calls _reboot_Teensyduino_() which starts the bootloader.

Code:
	else if( strstr(commandBuffer, "reboot") )
	{
	    Serial.write("  Rebooting\r\n");
	    delay(10000);
	    _reboot_Teensyduino_();
	    break;
	}

One final note: If the RPi has moved on to libusb-1.0 (as I learned is the default for my various Ubuntu systems), it is necessary either to find libusb-0.1-x or use an updated version of the bootloader. I have been sneaking a few hours of maintenance time into the bootloader to support libusb-1.0. That code is up on github:

https://github.com/len-samuelson/teensy_loader_cli

The Makefile allows selecting the version of libusb to use, defaulting to the original libusb-0.1. If you clone the git repository and have difficulty compiling or using it, I will try to answer any questions you may have. I have not asked Paul to pull it yet, as I have not had time to verify it beyond some basic sanity checks; consider it to be experimental. It is known to compile and run on Ubuntu-14.04 workstation and an Odroid-U2 (ARMv7 architecture dev board).
 
Thank you very much, Len!

I managed to make it (no errors) on RPi (thanks Paul too, I had to install libusb-deb first). So now I have an executable teensy_loader_cli on RPi.

I suppose I have to try to load the .hex now but I only have one bullet (if I encounter some errors I might loose Teensy/RPi control for good).

I'm not quite sure I understood the bootloader restart procedure. Do I have to include in my sketch (the .hex file) the _reboot_Teensyduino_() function call?.. In the setup{} section or something? (noob question)

(I have explained it in another thread: I'm far away from this RPi+Teensy setup and I have to modify the Teensy sketch as soon as i could. The Teensy board is used to control a PV (solar) array connected to a battery bank. Due to one foolish mistake, I forgot to uncomment some lines (for testing purpose) inside the sketch and now the Teensy board doesn't manage to properly control (disconnect) the PV panels. There is a huge risk of overcharging the batteries and I really don't have any other option to avoid that but to remotely modify the Teensy sketch. Btw, I'm remotely controlling RPi through a VNC connection.)
 
Last edited:
Status
Not open for further replies.
Back
Top