Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 26 to 50 of 83

Thread: Teensy loader for Raspberry Pi?

  1. #26
    Junior Member
    Join Date
    Dec 2012
    Posts
    6
    Quote Originally Posted by cmason View Post
    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.

  2. #27
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,857
    Not all ARM compilers are created (or configured) equal. Has anyone actually used Raspberry Pi's compiler for Teensy 3.0?

  3. #28
    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 by cmason; 01-10-2013 at 05:14 PM.

  4. #29
    Quote Originally Posted by PaulStoffregen View Post
    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.

    Attachment 128Attachment 129Attachment 130Attachment 131Attachment 132Attachment 133
    Paul, which SD card did you end up using?

  5. #30
    Quote Originally Posted by PaulStoffregen View Post
    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

  6. #31
    Junior Member
    Join Date
    Jul 2013
    Posts
    10
    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; ?

  7. #32
    Junior Member
    Join Date
    Jun 2014
    Posts
    6
    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

  8. #33
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    Quote Originally Posted by ishbplaya View Post
    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!

  9. #34
    Junior Member
    Join Date
    Jun 2014
    Posts
    6
    Quote Originally Posted by stevech View Post
    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?

  10. #35
    Senior Member
    Join Date
    Jun 2013
    Location
    Montréal
    Posts
    467
    stevech: define slow ? I've done a lot of dev in the past on the pi with Arduino and it's not that slow...

  11. #36
    Junior Member
    Join Date
    Jun 2014
    Posts
    6
    BUMP

    -anything guys?
    Any help or guidance would be awesome!

  12. #37
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,857
    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.

  13. #38
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    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.

  14. #39
    Member
    Join Date
    Aug 2013
    Location
    Ohio
    Posts
    91
    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...urvey-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.

  15. #40
    Junior Member
    Join Date
    Jun 2014
    Posts
    6
    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)

  16. #41
    Quote Originally Posted by ishbplaya View Post
    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.

  17. #42
    Junior Member
    Join Date
    Jun 2014
    Posts
    6
    Quote Originally Posted by Dave X View Post
    Thanks Dave! I have already looked at that link.
    My question is "teensy_loader_cli -mmcu=atmega32u4 -w blink_fast.hex" this command that actually flashes the hex file onto the teensy board requires a teensy_loader_cli which is an exe.

    How do I do this under Debian/Linux environment?

  18. #43
    Junior Member
    Join Date
    Jun 2014
    Posts
    6
    Still stuck on this problem guys, anything?

    Thanks in advance!

  19. #44
    Member
    Join Date
    Aug 2013
    Location
    Ohio
    Posts
    91
    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.

  20. #45
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,857
    Try installing libusb-0.1-4 and libusb-dev

  21. #46
    Member
    Join Date
    Aug 2013
    Location
    Ohio
    Posts
    91
    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").

  22. #47
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,857
    Quote Originally Posted by LenSamuelson View Post
    That led to asking (and subsequently answering) how difficult would a port to libusb-1.0 would be.
    I don't know, and I have no intention of working on this in the foreseeable future.

    But if you do it, please submit a pull request here.

    https://github.com/PaulStoffregen/teensy_loader_cli

  23. #48
    Senior Member
    Join Date
    Jan 2015
    Posts
    176
    Quote Originally Posted by PaulStoffregen View Post
    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!

  24. #49
    Member
    Join Date
    Aug 2013
    Location
    Ohio
    Posts
    91
    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).

  25. #50
    Senior Member
    Join Date
    Jan 2015
    Posts
    176
    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 by someteen; 01-05-2015 at 08:58 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •