Teensy loader for Raspberry Pi?

Status
Not open for further replies.
A

arnieelkins

New member
I am the proud owner of a new Teensy++ 2.0, and I happen to have a Raspberry Pi I would like to connect to it. I would like to be able to develop software on the Pi and upload it to the Teensy. I may not do things that way all the time, as my Windoze box is probably a much better place to develop, but I would like the option. The Teensy loader for linux does not work on the Pi, no doubt because it is an ARM device. Is it possible to port the loader to the Pi? I am running Raspian 'wheezy' on the Pi.

Thanks!
Arnie
 
I have the Teensy++2.0 compiling and loading on my Raspberry Pi. The steps are outlined on the pjrc.com webpage starting at http://www.pjrc.com/teensy/loader_cli.html for the Teensy Loader, Command Line, source code. You'll need these packages to compile for avr and libusb for the Teensy Loader.
`apt-get install libusb-dev gcc-avr binutils-avr avr-libc`
Then you should be all set for C/C++ projects. It isn't the fastest computer, but the programs can't get all that big either.
 
It'd be great if it could integrate into the Arduino IDE on the Pi like it does on x86 platforms. I've done some Arduino programming on the Pi. The compile time is a bit absurd, but it sure is nice programming on the big ol TV, especially when tutoring someone/multiple people. Not terribly important to have, but it'd be nice if it's possible.
 
This is a cool idea: using Teensy as (realtime) I/O processors connected to a PI, and being able to remotely update the Teensy code.
Bruce
 
The Raspberry Pi started actually shipping (in low volume, and hugely inflated ebay resale) right around the time I started working daily on Teensy 3.0.

Someone from the local Dorkbot group loaned me one of the first Pi boards. I spent a few days setting up a build environment (and dealing with lots of Linux issues....) and porting code. I eventually got the Teensy Loader to run, but it did not work. After devoting nearly a week to it, I just couldn't keep taking time away from developing Teensy 3.0, so I put it all aside.

Maybe in a few weeks I ought to look into it again? One of the troubles I ran into was a known bug in the Raspberry Pi bootloader where it wouldn't work with certain SD cards. Of course, the only really fast card I have was one of those. The other cards were horribly slow, especially since much of what I was trying to do needed more than the available RAM - so swapping to a high latency SD card (4K random write speed under 20 kbytes/sec) was just not practical. It took many hours just to compile the wxwidgets library. Compiling my own code, which takes maybe a couple seconds on my desktop machine took minutes on the Raspberry Pi. After days of dealing with such terrible speed (often I would start a compile job and set a kitchen timer to remind me to come back and look at in an hour), I finally did get it to build and run, but it didn't work.

Can anyone point me to a place where I can buy the new Raspberry Pi with 512 megs of RAM? I just checked Newark, but they're out of stock. Does anyone have it in stock at $35 with reasonable shipping?

Also, if anyone can point me to a 32 gig SD card that is absolutely for sure compatible with the Raspberry Pi and has at least 1 Mbyte/sec random 4K write speed (the "class 2, 4, 6, 10" spec is completely unrelated... many class 10 cards have 10 kbytes/sec random 4k write), that would be a huge help. Until I find such a card, I just don't think it's practical to develop on the Raspberry Pi.

I do want to support development and projects on the Raspberry Pi. I think with 512 megs of RAM, a fast SD card, and after I've ported more of the major Arduino libraries, working with the Raspberry Pi might be more practical?
 
Ok, I ordered a 512 meg Raspberry Pi from MCM.

I still need to find a fast 32 meg card. When I tried this before, I benchmarked all my cards using a card reader and a windows benchmark program (not sure which one... EDIT: CrystalDiskMark... it was free and prints 8 numbers, where the last 2 are the random 4K read and write speed). Every card I own benchmarked under 20 kbytes/sec on the 4K random write, except on Sandisk Ultra (which claims to be class 4, but for random writes it's much faster than the class 6 and class 10 cards). Sadly, that particular Sandisk Ultra card would not boot. Apparently it's a well known bootloader bug on the Raspberry Pi. Maybe the new version fixes that bug?

Can anyone point to good performance (random 4K write, not class 2,4,6,10,etc) SD card that is known to be compatible with Raspberry Pi?

My prior attempt with Raspberry Pi was so painful that I'm not going to even start again until I have a fast SD card that boots reliably.
 
Last edited:
The SD card situation for Raspberry seems to be a mess. there is so much (mis)information about what is working and not and what is fastest. I am using an old Sandisk, which is very reliable, but painfully slow.

http://elinux.org/RPi_Performance#SD_card has a list, but if you start checking some of these cards out, there are people having problems with some of them.

Maybe the OP can chime in?
 
I've start the same project using Android, basicly a smaller version of IOIO which only requires USB host mode. Also, have updated firmware so Android can now talk to the teensy 3.0. The main issues are:
- Basic loader for Android (Since IOIO is really just an I/O level operation, once the firmware is done, then, no need to really update)
- Common I/O protocol, there are several, IOIO, is one of many, but it is a basic protocol to communicate to get serial, I2C, PWM etc. So, the board is basicly a I/O interface via USB.
I've also been thinking of using i2c/USB , there is a spec now for this...
 
I've yet to find an SD Card that doesn't work reliably on any of my six Pi. When I got my first Pi, my best card was a Class 4, and only 4gb. So I went to Fry's and bought a 32gb Class 10, Patriot brand, "LX Pro". That card made a noticeable improvement in performance. I have a 8gb Class 10 Sony branded card in one of my other Pi. It works, but doesn't seem nearly as fast.
One of the problems you may have encountered with your last venture on the Pi was the original Linux distro for it wasn't using the FPU. On such an underpowered processor, it really needs every last bit of help it can get. Enabling the FPU really helped it out a lot.
 
PaulStoffregen said:
Someone from the local Dorkbot group loaned me one of the first Pi boards. I spent a few days setting up a build environment (and dealing with lots of Linux issues....) and porting code. I eventually got the Teensy Loader to run, but it did not work.
Click to expand...

See my earlier comment. With the addition of libusb-dev the loader compiled and ran out of the box, same with my existing teensy++ 2.0 program. My desktop took 1.26 seconds to compile the teensy program and 22.8 seconds on the Raspberry Pi, and I have the 256 MB early board version. It is a recent Debian wheezy/sid version and I did drop the allocated video memory down to the lowest 16MB since it is in the closet and I don't have any video on it anyway. `raspi-config`

I don't remember what SD card is in there, but the write performance seems dismal. I would only trust benchmarking an SD card on the device you try to use it from, my laptop has some really horrible performance, but it is doing PIO, so I expect it's mostly the laptop card hardware.

If you think the SD card is holding you back, only use it for booting. Do nfs over the network, or a USB harddrive (on a powered USB port).
 
UnaClocker said:
I've yet to find an SD Card that doesn't work reliably on any of my six Pi. When I got my first Pi, my best card was a Class 4, and only 4gb. So I went to Fry's and bought a 32gb Class 10, Patriot brand, "LX Pro". That card made a noticeable improvement in performance. I have a 8gb Class 10 Sony branded card in one of my other Pi. It works, but doesn't seem nearly as fast.
One of the problems you may have encountered with your last venture on the Pi was the original Linux distro for it wasn't using the FPU. On such an underpowered processor, it really needs every last bit of help it can get. Enabling the FPU really helped it out a lot.
Click to expand...

it is mind-boggling that after 1/2mill PI boards have been sold there is still vastly different opinions about best classes, brands, sizes etc. you would think by now there would be at least a pattern if not consensus.
 
Does the teensy_loader_cli source on the pjrc web site work with teensy 3.0? It does not list the freescale chip as an option. It compiles fine on the raspberry and the teensy3 shows up in lsusb:

Bus 001 Device 006: ID 16c0:0478 VOTI Teensy Halfkay Bootloader
Click to expand...

but I've tried specifying each of the mcu options and none of them seem to do anything.

I think I remember Paul saying he used a different protocol for teensy 3. Is there updated loader source available anywhere?

Thanks,

-c
 
Also, my new 512 meg Raspberry Pi arrived last Friday. It's still in the box, since I haven't found any info about a reliable and fast SD card.

Well, I'm also working on wrapping up Teensy 3.0 beta 10.... but hope to play with the Pi once beta 10 is released.
 
Patriot 32gb Class 10 card, they're selling for $20 at Fry's right now. I've been using one with my Pi since May, it's reliable, and generally considered to be one of the fastest that you can get, especially at that price.
 
Don't forget that the RPi can now be officially overclocked. If using the standard distribution, the option is in the configuration menu.

I took my 256K unit up to the medium level, and the performance is now pretty respectable. There are still two higher levels, but the core voltage increase increases by 6V which I considered wasn't worth the extra performance/risk.

I'm due to order a 512K RPi soon, not expecting too much of a rise in performance over the 256K unit.
 
Legb said:
I'm due to order a 512K RPi soon, not expecting too much of a rise in performance over the 256K unit.
Click to expand...

Firstly a big thanks to Paul for all his hard work. :cool:

I would recommend the 512M version for dev work especially if you are going to run some graphics.

I WAS going to use the 256M Pi as my dev "box" but I ended up swapping it out with the new 512M Pi. The 256M Pi now serves media files for the household to the XBMC Pi.

If you like to compile all day long I would go a full blown Linux box though and spend more time with the family. For occasional casual use I predict it would be fine. Time will tell.

In the meantime this could be useful..
http://darmawan-salihun.blogspot.com.au/2012/12/moving-raspberry-pi-root-filesystem-out.html

My philosophy on the Pi, or similar is to let them do the jobs that they can do and leave the power sucking stuff to do only what they have to do.

1 more thing. The Pi is not that great sitting in a box in 40C heat. Let it air it's bits in the breeze if you have it running in a hot environment. No need for forced cooling just good ventilation.
 
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.

sc1.pngsc2.pngsc3.pngsc4.pngsc5.pngsc6.png
 
Last edited:
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.

I spent a bunch of time trying to get qemu to work on my mac (there's lots of people on the net doing cross compilation via qemu), but I just couldn't make it work.

I'm running into this:

In file included from ../../../../.././libgcc/libgcc2.c:29:0:
../../../../.././libgcc/../gcc/tsystem.h:88:19: fatal error: stdio.h: No such file or directory

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

-c
 
cmason said:
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.

I spent a bunch of time trying to get qemu to work on my mac (there's lots of people on the net doing cross compilation via qemu), but I just couldn't make it work.

I'm running into this:

In file included from ../../../../.././libgcc/libgcc2.c:29:0:
../../../../.././libgcc/../gcc/tsystem.h:88:19: fatal error: stdio.h: No such file or directory

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

-c
Click to expand...
Lets see, there are scripts out there for building straight cross compile (where build and host are the same system and target is the remote system you are compiling for) and the more exotic Canadian cross compile (where you build on build system A so that the resulting compiler will run on host system B which generates code for target system C). You might want to look them up, as it is non-trivial. Your error message means that the compiler is trying to find stdio.h for the target system, and it is not finding it. I would suspect that you are building for a Linux target. For Teensy 3.0 you want to configure it for arm-none-eabi, instead of something like arm-gnu-linux.

Lets see, Paul used the following configuration line:
Code: 
/home/paul/teensy/arm_compile/workdir/gcc-4.7-2012.09/configure \
    --prefix=/usr/local \
    --target=arm-none-eabi \
    --enable-threads \
    --disable-libmudflap \
    --disable-libssp \
    --disable-libstdcxx-pch \
    --enable-extra-sgxxlite-multilibs \
    --with-gnu-as \
    --with-gnu-ld \
    --with-specs='%{save-temps: -fverbose-asm} %{O2:%{!fno-remove-local-statics: -fremove-local-statics}} %{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}' \
    --enable-languages=c,c++ \
    --disable-shared \
    --enable-lto \
    --with-newlib \
    --with-pkgversion='PJRC Build of GNU Toolchain from CodeSourcery' \
    --with-bugurl=http://forum.pjrc.com/ \
    --disable-nls \
    --with-headers=yes \
    --with-sysroot=/usr/local/arm-none-eabi \
    --with-build-sysroot=/home/paul/teensy/arm_compile/arm-none-eabi/arm-none-eabi \
    --with-gmp=/home/paul/teensy/arm_compile/staticlib \
    --with-mpfr=/home/paul/teensy/arm_compile/staticlib \
    --with-mpc=/home/paul/teensy/arm_compile/staticlib \
    --with-ppl=/home/paul/teensy/arm_compile/staticlib \
    --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' \
    --with-cloog=/home/paul/teensy/arm_compile/staticlib \
    --with-libelf=/home/paul/teensy/arm_compile/staticlib \
    --disable-libgomp \
    --disable-libitm \
    --enable-poison-system-directories \
    --with-build-time-tools=/home/paul/teensy/arm_compile/arm-none-eabi/arm-none-eabi/bin

Now, --with-newlib and --with-sysroot are the important ones for configuring a cross compiler (--with-newlib says the target is using newlib instead of glibc, --with-sysroot gives a path that contains the root file system to find all of the include files, etc.).

The way I have done it in the past includes:

  • Build and install an initial binutils without the --with-sysroot;
  • Build the compiler and install the libgcc library;
  • Install the header and system libraries into your --with-sysroot directory;
  • Rebuild binutils from scratch, this time with --with-sysroot;
  • Rebuild the compiler with the --with-sysroot.
 
Status
Not open for further replies.
Back
Top