Compile GCC for teensy 3?

Status
Not open for further replies.

cmason

Well-known member
If I wanted to compile a more recent gcc for the teensy 3 what configure options should I use? I'd like to otherwise get as close as possible to what's in Paul's distribution.

Thanks,

-c
 
Last edited:
GCC will tell you how it was configured (plus some other info) if you run gcc -v. From the ARM gcc in arduino-1.0.2:
Code:
dhm@vanadium-crossdev:/usr/local/packages/arduino-1.0.2$ hardware/tools/arm-none-eabi/bin/arm-none-eabi-gcc -v
Using built-in specs.
Target: arm-none-eabi
Configured with: /scratch/julian/2010q1-release-eabi-lite/src/gcc-4.4-2010q1/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --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='%{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 --disable-lto --with-newlib --with-pkgversion='Sourcery G++ Lite 2010q1-188' --with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls --prefix=/opt/codesourcery --with-headers=yes --with-sysroot=/opt/codesourcery/arm-none-eabi --with-build-sysroot=/scratch/julian/2010q1-release-eabi-lite/install/arm-none-eabi --with-gmp=/scratch/julian/2010q1-release-eabi-lite/obj/host-libs-2010q1-188-arm-none-eabi-i686-pc-linux-gnu/usr --with-mpfr=/scratch/julian/2010q1-release-eabi-lite/obj/host-libs-2010q1-188-arm-none-eabi-i686-pc-linux-gnu/usr --with-ppl=/scratch/julian/2010q1-release-eabi-lite/obj/host-libs-2010q1-188-arm-none-eabi-i686-pc-linux-gnu/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-cloog=/scratch/julian/2010q1-release-eabi-lite/obj/host-libs-2010q1-188-arm-none-eabi-i686-pc-linux-gnu/usr --disable-libgomp --enable-poison-system-directories --with-build-time-tools=/scratch/julian/2010q1-release-eabi-lite/install/arm-none-eabi/bin --with-build-time-tools=/scratch/julian/2010q1-release-eabi-lite/install/arm-none-eabi/bin
Thread model: single
gcc version 4.4.1 (Sourcery G++ Lite 2010q1-188) 
dhm@vanadium-crossdev:/usr/local/packages/arduino-1.0.2$

In my long, generally unsatisfactory career of trying to build bleeding-edge GCCs that support the many many many different ARM options, the hardest part has always been getting multilibs to work right. There are an enormous number of combinations of ARM, Thumb, Thumb-1, Thumb-2, Interwork (or not), and at least 3 floating-point options. It's easy to build a GCC toolchain that supports one or two of those, but having the whole menu of choices available to one driver program is tough.

I'm currently using gcc-4.6.2 from https://launchpad.net/gcc-arm-embedded which seems to have everything (possibly not ARM instructions, but not as important any more, now that everything has gone Cortex). Here's its --print-multi-lib output:

Code:
arm-none-eabi-gcc --print-multi-lib -O3 -Wall -mcpu=cortex-m4 -mfloat-abi=soft -mthumb -DF_CPU=24000000 -DTIME_T=1354463440 -I.  -c -o mk20dx128.o mk20dx128.c
.;
thumb;@mthumb
fpu;@mfloat-abi=hard
armv6-m;@mthumb@march=armv6s-m
armv7-m;@mthumb@march=armv7-m
armv7e-m;@mthumb@march=armv7e-m
armv7-r/thumb;@mthumb@march=armv7-r
armv7-r/thumb/fpu;@mthumb@mfloat-abi=hard@march=armv7-r@mfpu=vfpv3-d16
armv7e-m/fpu;@mthumb@mfloat-abi=hard@march=armv7e-m@mfpu=fpv4-sp-d16
armv7-r/thumb/softfp;@mthumb@mfloat-abi=softfp@march=armv7-r@mfpu=vfpv3-d16
armv7e-m/softfp;@mthumb@mfloat-abi=softfp@march=armv7e-m@mfpu=fpv4-sp-d16
dhm@vanadium-crossdev:~/ARM/blink-teensy$

Paul's --print-multi-lib is:

Code:
dhm@vanadium-crossdev:/usr/local/packages/arduino-1.0.2$ hardware/tools/arm-none-eabi/bin/arm-none-eabi-gcc --print-multi-lib
.;
thumb;@mthumb
armv6-m;@mthumb@march=armv6-m
thumb2;@mthumb@march=armv7@mfix-cortex-m3-ldrd
dhm@vanadium-crossdev:/usr/local/packages/arduino-1.0.2$

So, fewer architectures supported, and no floating point. (BTW, I wanted FP because I have a TI/Luminary Stellaris LaunchPad kit with the LM4F120 processor, which has a single-precision FPU.)

[edit: Uh oh, oops, the gcc-arm-embedded compiler doesn't have thumb2! I guess I'll have to keep poking around, trying to build my own version!]
 
Last edited:
If you really get stuck about building GCC, shoot me a note. I'm an experienced GCC developer (currently working on the powerpc), though I've been trying not to get involved in AVR and ARM the backends for this hobby project.

[edit]
A quick glance at the current 4.8 sources appears to indicate that there is no pre-made target that builds thumb2 multilibs as one of the defaults. You would need to edit gcc/config/arm/t-arm-elf to add additional multilib options. Unfortunately, multilibs can be a multiplier and quickly balloon out of control.
 
Last edited:
You would need to edit gcc/config/arm/t-arm-elf to add additional multilib options.
Yeah, I found t-arm-elf in my adventures, and got it working with +/- thumb-interwork, IIRC. The problem I've always had is building the multilibs for +/-FPU, which makes 3 options: soft-FP, hard-FP with soft-FP calling conventions, and hard-FP with FPU register calling conventions. And what always kills me is that the linker driver gets confused about which support files it's supposed to use with my objects. The error, from memory, is "xxx.o uses VFP instructions, whereas executable-name does not."

It really shouldn't be that hard: if I have an FPU on a chip, I generally want to use all-FP-all-the-time; and if not, then not. I don't even use FP for most programs, but if I've got FPU, and use FP, then ...
 
Yeah, I found t-arm-elf in my adventures, and got it working with +/- thumb-interwork, IIRC. The problem I've always had is building the multilibs for +/-FPU, which makes 3 options: soft-FP, hard-FP with soft-FP calling conventions, and hard-FP with FPU register calling conventions. And what always kills me is that the linker driver gets confused about which support files it's supposed to use with my objects. The error, from memory, is "xxx.o uses VFP instructions, whereas executable-name does not."

It really shouldn't be that hard: if I have an FPU on a chip, I generally want to use all-FP-all-the-time; and if not, then not. I don't even use FP for most programs, but if I've got FPU, and use FP, then ...
The key after building the compiler, you need to go back and build the support libraries (those that aren't part of the compiler). The libraries have to use --print-multi-lib to determine which sets to build. In general, if you are building a cross compiler for a new target, or having new sets of multilibs, you need 3 iterations:

  • Build the cross compiler with the multi-libs that you want;
  • Rebuild binutils now that you have the compiler with the --sysroot option, pointing to where you are going to install things, and the rebuild the compiler with the same --sysroot as binutils;
  • Now build the support libraries (newlib, etc.) that aren't part of the compiler to pick up the new multlibs.

Its been about 4-5 years since I last was modifying the machine independent multilib support. Now that I work on hosted compilers and not embedded, I haven't had the need to go in tweak things in that area.
 
I'm trying to basically follow (manually) the build script in the launchpad tree (common file; prereqs file). I configured gcc trunk with:

Code:
../gcc-trunk/configure --build=i686-apple-darwin10 --host=i686-apple-darwin10 --target=arm-none-eabi --prefix=/usr/local/teensy --enable-languages=c --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-lto --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --without-headers --with-sysroot=/usr/local/teensy/arm-none-eabi --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --with-ppl=/usr/local --with-cloog=/usr/local --with-libelf=/usr/local --with-extra-multilibs=armv6-m,armv7-m,armv7e-m,armv7-r --enable-extra-sgxxlite-multilibs

armv6-m,armv7-m,armv7e-m,armv7-r comes from the launchpad script and enable-extra-sgxxlite-multilibs from the codesourcery (teensy) tree.

However, once built, I only get this from -print-multi-lib:

Code:
thumb;@mthumb
fpu;@mfloat-abi=hard

I see a lot of stuff commented out in t-arm-elf. Do I need to comment some of that back in? I'm trying to compare the trunk version to the one in the launchpad tree but it's pretty different.

I'm trying to target:
  • cortex-m0, -m0plus for the freedom board
  • cortex-m3 for maple mini, bacon, etc.
  • cortex-m4 for teensy 3 (with DSP extensions?)
  • cortex-m4-fpu for a possible custom board with fpu on it. (eg this part)

I assume that I want, as spacewrench suggests, both hard and soft float in one driver. Alternatively I could just install to two different prefixes.

Any advice here on how to configure gcc for this scenario would be most helpful. Even just help enumerating which "multilibs" I want for the above parts would be really helpful.

Thanks,

-c
 
I suspect you didn't take the whole tree from the launchpad (linaro) site, as the standard GCC does not support the --with-extra-multilibs configuration option. Either that or you have multiple compilers on your path, and the compiler you did --print-multi-lib on was built from the standard source directory.

The one Paul ships has:
  • .;
  • thumb;@mthumb
  • armv6-m;@mthumb@march=armv6-m
  • thumb2;@mthumb@march=armv7@mfix-cortex-m3-ldrd

[edit]
This is in the documentation, but the t-* files define 3 make variables:
  • MULTILIB_OPTIONS -- this is a list of separate multilibs, with space meaning independent options, and slash meaning exclusive options, so if you had mcpu1/mcpu2/mcpu3 mfp it would create 8 multilibs, 4 multilibs for the different cpu options (none, -mcpu1, -mcpu2, and -mcpu3) but no explicit floating point, and 4 multilibs with the different cpu options and -mfp. As you can see, it quickly becomes expodential. One of the ports I looked at, had the possbility of 10 independent options, or 1,024 multilibs.
  • MULTILIB_DIRNAMES -- these are the subdirectories for each option. In the example above, you would have 'cpu1 cpu2 cpu3 fp' to create 8 directories;
  • MULTILIB_EXCEPTIONS -- these are multilibs that are not possible, for example if neither cpu1 nor cpu2 could have floating point, you would use '*mcpu1*/*mfp* *mcpu2*/*mfp*, and it would not build the cpu1/fp and cpu2/fp multilibs.
  • MULTILIB_MATCHES -- this allows for synonyms, for example whether '-march=armv7' is the same in terms of multilibs as '-mcpu=cortex-m3'.
 
Last edited:
Success!

After putting this aside for a while I finally came back to it and I have GCC 4.8.0 compiled on my mac and the resulting binaries working on the teensy3. The resulting GCC supports the following mutlilibs:

Code:
> arm-none-eabi-gcc -print-multi-lib
.;
thumb/arm7tdmi-s;@mthumb@mcpu=arm7tdmi-s
thumb/cortex-m0;@mthumb@mcpu=cortex-m0
thumb/cortex-m3;@mthumb@mcpu=cortex-m3
thumb/cortex-m4;@mthumb@mcpu=cortex-m4
thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16;@mthumb@mcpu=cortex-m4@mfloat-abi=hard@mfpu=fpv4-sp-d16

I basically followed the instructions here and here, but I'll summarize the steps below.

The absolute key was finding the right contents of the gcc/config/arm/t-arm-elf file. Taken from here, they are:

Code:
# We have to build 'arm' and 'thumb' libraries, it seems.
 MULTILIB_OPTIONS     = marm/mthumb
 MULTILIB_DIRNAMES    = arm thumb
# Only we don't actually want any ARM libraries.  Or
# vanilla thumb libraries.
MULTILIB_EXCEPTIONS  = marm* mthumb

# Build with any one of arm7tdmi, M0, M3 or M4 support.
MULTILIB_OPTIONS    += mcpu=arm7tdmi-s/mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
MULTILIB_DIRNAMES   += arm7tdmi-s cortex-m0 cortex-m3 cortex-m4

# These don't make any sense without thumb, because GCC likes to
# tell you that you have to supply another commandline argument
# rather than just setting it itself.
MULTILIB_EXCEPTIONS += mcpu=arm7tdmi-s* mcpu=cortex-m0* mcpu=cortex-m3* mcpu=cortex-m4*

# All this just to get mfloat-abi=hard mfpu=fpv4-sp-d16 only specified for the M4
MULTILIB_OPTIONS    += mfloat-abi=hard mfpu=fpv4-sp-d16
MULTILIB_DIRNAMES   += float-abi-hard fpuv4-sp-d16
MULTILIB_EXCEPTIONS += mfloat* mthumb/mfloat*
MULTILIB_EXCEPTIONS += mfpu* mthumb/mfpu*
MULTILIB_EXCEPTIONS += mthumb/mcpu=cortex-m4/mfloat-abi=hard
MULTILIB_EXCEPTIONS += mthumb/mcpu=cortex-m4/mfpu=fpv4-sp-d16
MULTILIB_EXCEPTIONS += *arm7tdmi-s*mfloat-abi* *arm7tdmi-s*mfpu*
MULTILIB_EXCEPTIONS += *cortex-m3*mfloat-abi* *cortex-m3*mfpu*
MULTILIB_EXCEPTIONS += *cortex-m0*mfloat-abi* *cortex-m0*mfpu*

A couple things I learned:

arm-eabi seems to require you include both arm and thumb libraries even if you only care about thumb. This is really annoying. Also, the multilib config is atrocious, mostly because the combinatorial expansion produces lots of invalid configurations that you have to exclude, and you have to wait a until a fair amount of the build has happened before you can see your error. Why can't I just list the multlibs I care about?

I'll briefly summarize the steps because I've yet to see one single source that identifies all the bits needed:

Prereqs:
Install latest versions of:


All of these get compiled for the "host" architecture (where you're actually running the compiler), so PC, Mac, raspberry, etc. These all were a pretty simple
Code:
./configure --prefix=/usr/local/teensy && make install
so I won't go into detail.

Binutils:

Install latest version of binutils (2.23.1) for the target architecture of arm-none-eabi:

Code:
./configure --target=arm-none-eabi --prefix=/usr/local/teensy --with-sysroot=/usr/local/teensy/arm-none-eabi
sudo make install

Make sure you use sysroot.

GCC:

I'm using the trunk GCC because I wanted to test out some C++11 features like alignas(). You may want to use a less recent release version like 4.7.2. My experience with bleeding edge GCCs has usually ended up making me regret it. 4.8 release seems relatively close on the horizon though. So, YMMV.

Download gcc or use the trunk:
Code:
svn co svn://gcc.gnu.org/svn/gcc/trunk gcc-trunk

Edit the file gcc-trunk/gcc/config/arm/t-arm-elf to match the contents above.

Bootstrap gcc with:
Code:
mkdir arm-none-eabi
cd arm-non-eabi
../gcc-trunk/configure
 --build=i686-apple-darwin10 \
 --host=i686-apple-darwin10 \
 --target=arm-none-eabi \
 --prefix=/usr/local/teensy \
 --enable-languages=c,c++ \
 --disable-decimal-float \
 --disable-libffi \
 --disable-libgomp \
 --disable-libmudflap \
 --disable-libquadmath \
 --disable-libssp \
 --disable-libstdcxx-pch \
 --disable-lto \
 --disable-nls \
 --disable-shared \
 --disable-threads \
 --disable-tls \
 --with-float=soft \
 --with-gnu-as \
 --with-gnu-ld \
 --with-newlib \
 --with-headers=../newlib-1.20.0/newlib/libc/include/ \
 --with-sysroot=/usr/local/teensy/arm-none-eabi \
 --with-gmp=/usr/local/teensy \
 --with-mpfr=/usr/local/teensy \
 --with-mpc=/usr/local/teensy \
 --with-ppl=/usr/local/teensy \
 --with-cloog=/usr/local/teensy
make all-gcc

Grab a coffee. This will take at least a half hour.

After it finishes, you can test to make sure the multilib setup worked with:

Code:
gcc/xgcc -print-multi-lib

The output should match that above. Install:

Code:
sudo make install-gcc

Newlib:

Download latest newlib (I'm using 1.20.0). I had a number of problems with newlib failing to compile for some variations of the architectures. Use this patch: View attachment newlib.diff.txt (taken mostly from here).

Code:
./configure --target=arm-none-eabi --prefix=/usr/local/teensy --enable-multilib --disable-libssp --disable-nls
sudo make install

Then back in gcc:

make all
sudo make install

I had some trouble with the default linker script producing errors about missing __bss_start__. Use this patch: View attachment gcc-8-mk20dx128.ld.diff.txt.

Can anyone suggest a reasonable way to test this compiler for correctness?

-c
 
I'm necromancer-ing this thread! Because I want to build for Teensy3.1 from a Raspberry Pi. However, that's all I want to do. Do I really need multilib for that?

I'm using crosstool-ng. So far, I've managed to build a cross-compiler from x64 to RPi, that seems to work on a very simple test program (using floating point.)
I also tried to configure a "Canadian" build; build on x64, host on RPi, target Teensy. Initially, this failed, because CT tried to invoke the host-compiler to generate a spec, and the host-compiler surprisingly isn't runnable on the builder machine.
But, I'm not giving up. I'm building a cross compiler from x64 to Teensy, with the same "tuple" name as the Canadian compiler I'm trying to build. Presumably, this will be invokable, and I can then go on to build the real Canadian binaries.

In no part of these steps do I turn on multilib or multiarch. I really want as simple as possible a tool chain. I've also turned off newlib, generating "no" clib.
However, that brings up the question: What clib is Teensy based on? uclibc? eglibc? Something else? And where should I get the sources and bootstrap needed for this?
Also, the PRJC code itself is something I'd like to re-use. Is there a better "source" for these than copying them out of the Arduino install? And how do I go about mering it with whatever libc is supposed to be used?

I can sort-of squint and get the shape of some of these answers from the above thread, but the details are hazy.
 
I want to build for Teensy3.1 from a Raspberry Pi.
As an owner of T3s and an RPi connected to my NAS for disk storage...
Doing a build on an RPi for the T3/Teensyduino libraries would give you lots of time to catch up on books you've long planned to read.
 
It's been about 18 years or so since I built Canadian crosses, and I didn't do it that often. I suspect some of the technology has decayed over the years as fewer people in the core GCC community actively do full Canadian crosses (it was a lot easier to configure when GCC, binutils, GDB, etc. were all in the same source tree). After Cygwin was developed, a lot of the main reason we did Canadian crosses at Cygnus Solutions went away. Instead of doing a Canadian cross with a Sparc as the build machine, Windows as the host machine, and whatever random embedded target we were building for as the target, you would just go on to the Windows machine and make a normal cross compiler.

In case people are wondering what a Canadian cross compiler is, a normal hosted compiler runs on a system, and generates binaries for the same system (--target=, --build=, and --host= are all the same tuple). In a standard cross compiler that is used in the Arduino/Teensy environment, the --build= and --host= tuples are the same, while --target= specifies the target system. In a Canadian cross system, you are building a cross compiler on a build system, generating the compiler binaries that will run on a different host system, and the compiler that runs on the host system then generates binaries for a target system. A fundamental step in the process is you first have to make and install a normal cross compiler that runs on the build system, and generates executables that run on the host system, and that compiler has to be in your PATH. It is called a Canadian cross system because at the time the name was created, Canada had 3 political parties that were somewhat equal in size (and the fact that the boss at Cygnus Solutions happened to be Canadian played into the naming).

<edit>
I suspect the main problem with building on the Pi is the lack of memory, and the compiler is just paging itself to death. If you are running on a model A/A+ or the original version of the model B with 256 megabytes of memory, upgrade to the current B or B+ models to get 512 megabytes of memory. Reduce the amount of memory needed for the GPU to the bare minimum to give as much memory to the processor as possible. Also, get the faster SD cards, so that when you do start paging, it will be quick. I don't have much experience with modern NAS's, but I would see if moving everything to the local SD card would be faster than using a network file system.
 
Last edited:
I'm using a B+, which has microSD, not SD, now. Even "fast" ones top out at around 20 MB/s or so. Which, back in the day, was respectable for a hard disk, especially given that there is no seek time. But, these days...
(SanDisk Extreme Pro claims 95 MB/s -- I don't believe I'll see anything like that in reality.)
I do have an NFS4 server on the network, that I could mount on the RPi, but the Ethernet on the Pi is over USB, so it also tops out at 40 MB/s or so.
I'm now running into a bug that's apparently known on the internet -- failure to detect EOF, caused by the libstdc++ build when not building a C library. The recommended fix was to "always copy headers," which I patched my crosstool-ng to do, but that still wasn't enough.
I'm now re-running by actually building a libc (disabling syscalls, 'cause... no operating system!)

The next question then is still: What main/CRT startup files and other goop do I need to take from where to build a working Teensy3.1 runtime library?
 
Last edited:
Some encouraging news: I have managed to make crosstool-ng build cross-tool for RPi, cross-tool for teensy, and canadian-tool to run on rpi and build for teensy3.
These tools run without crashing. However, I have not tested running the generated code on a Teensy3 -- it's unlikely it will actually work, because I'm using the default newlib C library and no interrupt/other start-up code.

The question then becomes: Where do I get the proper start-up glue files, and how do I add the PRJC support functions, to generate a library that can build actual Teensy3 projects as found in the Arduino library?
 
Presuming one has a desktop or laptop for developing, why would one want to compile/build on an RPi (or equiv.) ?
 
I am not the OP, but I could imagine cases where it might be useful. It may be like building ships inside of a bottle, where it isn't that practical in general, but it presents an engineering challenge. I have a Pi that I picked up a few years ago, and with the recent small screens (I have a 2.8" PiTFT and 5" HDMI screen) and they are small enough to use in a limited fashion. I could see using it to tweak the programming of a Teensy. Would I write whole programs from scratch on it? Perhaps not, but I could see tweaking existing code. If I went with a larger 10" tablet or pi+HDMI screen, then I could certainly imagine doing it in some cases.

For example, there is this article on programming Arduinos on tablets over at Adafruit: https://learn.adafruit.com/programming-arduino-with-android-and-windows-tablets/overview
 
Presuming one has a desktop or laptop for developing, why would one want to compile/build on an RPi (or equiv.) ?

I have a robot where a Raspberry Pi (doing vision and planning stuff) talks to a Teensy3 (doing sensor and control stuff) over USB.
When I need to develop the Teensy3 code, when using my desktop/laptop, I have to unplug the Teensy from the RPi, then plug it into the laptop, upload the code, and then re-plug it.
This wears down the USB connector pretty quickly (they are not rated for tens of thousands of insertions...) and it takes significant time that deploying straight from the RPi does not.

Separately, I may not have the desktop with me when the robot is out in the world, but I may still be able to get a remote connection to the RPi.
"Out in the world" may be as simple as 20 meters away in the yard, or may be as complex as "at a competition and I suddenly find a flaw I need to fix in the next 30 minutes."

Here's the config files for the cross/canadian build process that works. The question is now: How do I build proper libraries for Teensy3?
https://github.com/jwatte/teensy-canadian

Python works well on the RPi.

Been there, done that, got the T-shirt, has nothing to do with developing code for the Teensy.
 
Last edited:
Python works well on the RPi.

Sure, but the Teensy IDE doesn't use Python. The IDE does use Java, but you don't need no stinkin' IDE.

Now, a lot of time in these projects you don't need the most performance, but sometimes you do. Since a lot of Pi projects are programmed in Python, and you have to go to the OS to deal with GPIO pins, for something that accesses the real world (servos, neopixels, etc.) and has a bit of integer calculation involved, it may be faster to do code in bare metal C++ on the Teensy, then doing it the normal way on the Pi, even though the Pi has a clock speed about 8-10 times the Teensy.

Of course it works the other way too. Having much more memory, and an OS to deal with thread abstractions and networking, means you can write more high level code on the Pi.

Everything in life is a compromise.
 
I appologise for duplicating a post from another thread ( Building for the Teensy on the Raspberry Pi ) but I desperately need help. Here's my post from the other thread:

Congratulations for your effort, jwatte!

I really have some troubles: I have a PV (solar) system and I'm using a Teensy 3.1 to read the battery voltage/charging current and to disconnect the PV panels if the batteries are fully charged.

I'm using a RPi (B+) to read those parameters from Teensy (using the USB serial connection) and to access all those informations from remote locations.

It happens that right now I'm (far) away from home and I have some problems with the charging protocol (Teensy keeps reconnecting the PV panels even the batteries are full charged) due to some erroneus voltage thresholds in the Teensy sketch.

So I have no choice but to modify Teensy sketch to correct those errors. Otherway, the batteries will be drastically overcharged (the overcast is a disaster - three sunny days).

I really need your help, please. Could you explain me how to upload a .hex file using Raspberry Pi? I have full access (VNC) to RPi so I could install/run anything. I could compile the sketch using my laptop (linux/arduino/teensyduino) and copy the .hex file to RPi.

How to properly load that hex file to Teensy??

I'm so sad that Paul S. doesn't care about Teensyduino for ARM processors, as I already have many projects using Teensy 3.1 (great board) and many of them are direct connected to RPi boards. It's a real nightmare to keep disconnecting them to upload some sketches (as RPi has a single UART interface so I have to use the USB connections).

Any help are highly appreciated!
 
Hi jwatte,

It will be interesting to see how well you can get this to work. Also if your builds work for some other but similar setups. As you probably know, I am currently playing with Intel Edison and using USB2AX for servos, but would like to swap out the USB2AX for one of my Teensy 3.1s. Would be great if I could at times do build and download from Edison. Especially if where I choose to mount Teensy may not be very easy to swap USB plugs. (have not tried 32 bit x86 arduino on it yet as setup is headless).

For the fun of it, I may also try the stuff out with Odroid C1 (1.5ghz quad core) with 8gb emmc, instead of Edison just to see how well it does. So again would be great to have a Arm Cortex version that runs on this...

Sounds like you are making progress.
Kurt
 
Status
Not open for further replies.
Back
Top