Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 31 of 31

Thread: Raspberry Pi Hardware

  1. #26
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,547
    Runs (or more appropriately crawls) on Arduino Zero wireless. Again tested uploading blink to Teensy LC

    Side notes: Hard to click upload when the Teensy LC was previously programmed with USB Mouse TrangleMove Example

    Wish list: I wish there was headless support (not just for ARM) - I normally run my linux arm boards headless... I also run my X86(64 bit) UP boards (Ubuntu) headless.

    That is I wish I could type in something like: ./TeensyduinoInstall.linuxarm -libraries:all ~/Desktop/arduino-1.8.4

    I have not double checked, but guessing still can not use the command line running of Arduino to run headless to Teensy... Could program an UNO this way, but last time I tried I was able to get the Teensy to run through the compiler and then it would fail to launch the Teensy app...

  2. #27
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Last time i used the commandline to compile, it worked. But thats months ago.

  3. #28
    Senior Member Epyon's Avatar
    Join Date
    Apr 2013
    Location
    Belgium
    Posts
    443
    Quote Originally Posted by KurtE View Post
    Wish list: I wish there was headless support (not just for ARM) - I normally run my linux arm boards headless... I also run my X86(64 bit) UP boards (Ubuntu) headless.

    That is I wish I could type in something like: ./TeensyduinoInstall.linuxarm -libraries:all ~/Desktop/arduino-1.8.4
    I feel you. Right now I compile on my primary PC and then SSH into the remote Teensy host system and flash it through the commandline. Probably could be automated by a Perl script though .

  4. #29
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,547
    Looking through my Odroid box...

    Decided to reflash C1 and C2 to latest Ubunut releases, plus do all of the updates: (sudo apt-get update ... upgrade ... dist-upgrade (install new kernel...)
    I may have screwed up the C1's emmc so flashing a MicroSD card as I am typing this.

    C2 - (64 bit linux) - Arduino Fails to run like I expected.
    Run from terminal window ./arduino

    Error sort of like;
    Code:
    ./arduno:  Line 35 /home/odroid/odroid/Desktop/arduino-1.8.4/java/bin/java: no such file or directory
    Could look up old thread to probably fix... But probably outside the scope of this

    C1 just finished flashing so now need to go through all steps again... expect it to work without problem.

    C1 runs the code - I think my board has been semi screwed up... I remember that from before... If I want to use one again should probably get new one, but
    than more likely to get higher end.
    Last edited by KurtE; 09-02-2017 at 01:00 AM.

  5. #30
    Senior Member
    Join Date
    Jun 2014
    Posts
    245
    It is now possible to boot directly from USB flash or USB SSD without a uSD card, but the process is non-reversable, iirc.

    Here's a good video on the topic https://youtu.be/ubnwvxF3Klc

  6. #31
    Senior Member
    Join Date
    Dec 2014
    Posts
    262
    Stop supporting Linux ARM / Raspberry Pi. This would be the easiest, but it seems at least some people do use it, right?
    I'm one of those! Running on a RPi 3 right now.

    Also, I have even run the Raspberry Pi binaries on an NVIDIA Jetson. With some wishful thinking and multi-arch mumbo-jumbo, it mainly works.

    If compiling on the RPi 3 is too slow, then the faster option is to cross-compile on an x64 machine. Assuming you can get the armhf toolchain to find the appropriate libraries (that you can copy from the raspbian installation) then that should work fine.
    At one point, I had this working, and the final step of the makefile was "scp stuff my-raspberrylace" and building natively + copying over ssh was faster than local building.

    If you want to be more compatible with older software, try linking everything with "--static" because the kernel / X windows ABIs change much slower than the support libraries.
    libc will complain that certain internationalization of libc will require a dynamic libc on the target system; I have not run into that actually being a problem (but I have not pushed this mode of building particularly hard.)

Posting Permissions

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