Raspberry Pi Hardware

Status
Not open for further replies.

PaulStoffregen

Well-known member
The Raspberry Pi (model B version 1) I use to build Teensyduino for Linux ARM seems to be dying. Well, most likely its SD card may be dying. After several hard lockups while compiling, I managed to finally get a complete build after deleting lots of stuff to free up about 7 GB of space. The build uses under 0.5 GB.

So I'm trying to decide what I'm going to do...

1: Stop supporting Linux ARM / Raspberry Pi. This would be the easiest, but it seems at least some people do use it, right?

2: Just replace the SD card, reinstall and copy or rebuild stuff. Worried some of my current SD card may be corrupted. If I have to redo the setup, I'd like to step up to something faster than this painfully slow version 1 Pi.

3: Replace it with a Raspberry Pi 3 and a (hopefully) faster & more reliable USB disk, and then redo the setup... Here's the hardware I'm considering. Is this hardware a good idea? Do programs compiled on a Raspberry Pi 3 always work when run on Pi Zero or earlier model Pi?

https://www.amazon.com/StarTech-com-Raspberry-Pi-Board-Converter/dp/B01NH2W8NL
https://www.amazon.com/Samsung-850-EVO-Internal-MZ-N5E250BW/dp/B00TGIVZTW
https://www.amazon.com/Raspberry-Model-1-2GHz-64-bit-quad-core/dp/B01CD5VC92

4: Set up cross compiling from my fast desktop. This seems like a great option for building a command line program. But a pair of GUIs which link against custom compiled wxWidgets and FLTK libraries, which in turn have tons of library dependencies on the Raspbian system libs seems like quite a nightmare. Or maybe it's not so hard?

My main goal is to minimize the amount of time I end up pouring into redoing my Raspberry Pi build setup, so I can focus on other stuff that matters for everyone. I've found numerous mentions online that SD card tend to fail on Raspberry Pi after heavy usage, so I'm *really* hoping to get onto more durable hardware to avoid having to redo this all over again in another year.
 
Or is there some other Linux ARM board that runs Raspbian and compiles binaries that will work on all Raspberry Pi boards?

I've seem *many* other Linux ARM boards that claim to be a *lot* faster. But compatibility seems like an issue. Maybe? If anyone knows of a good alternative that isn't going to turn into a huge time-sink of compatibility problems, please let me know?
 
Hi Paul,

My guess is I would go with an RPI3... My first Linux board was an RPI and I had a few times where the SD card failed... Which caused me issues... So I started playing with other things... So I looked for boards that did not necessarily use an SD card.

If you were looking for another ARM board that should build a lot faster, you might look at an Odroid board like their XU4 which has 8 cores, but I have mainly used them with Ubuntu, there are images for it that run Debian Jessie, but not sure if that would work for you or not.
https://ameridroid.com/products/odroid-xu4

You can run them with SDCards or they have emmc modules you connect to run a lot faster...

They have also released another version of it, where they striped off emmc, and several other things and it made a rack mount version setup to use an SSD disk:
https://ameridroid.com/products/odroid-hc1-0003a

And they sell the Teensy: https://ameridroid.com/products/teensy-32-usb-board :D
 
Hi all,

I am with KurtE, both with respect to the RPI3 and Odroid(s). My co-workers and I have had excellent results with both.

My current work involves both (semi-substantial) compilation and containerization to support a large legacy codebase, and I've been surprised by the capabilities of these machines.

I have not tried UDOO, WandBoard, Beaglebone or any of the many OrangePi/BananaPi boards and derivatives for these tasks.
 
Just a thought, but if you had a RPi3 with WiFi, and you had a NFS disk (from other Linux machine, or NAS server) you could build on the remote disk and prevent burning out the SD card.
 
Hello All,

Why not circumvent the SD card altogether and boot/run from USB SSD? this is possible on Rpi3.

regards, Otto
 
I have a substantial number of RPi 2 and 3 units. With heavy file I/O (or uncontrolled shutdowns/ power supply issues), SD card wearout and/or corruption can and does happen. I did have one board that had a soldering flaw on a camera connector, but the hardware itself is generally good. If you simply replace the SD card, it's likely to continue working OK. I haven't done it myself but for longer-term use, running the system from an external USB hard drive seems like it should work OK. Depending on the operations it might even work faster.

I use Teensy together with RPi in deployed systems frequently, but I am not personally interested in trying to develop (compile) for Teensy on the RPi itself.
 
you might look at an Odroid board like their XU4 which has 8 cores,

Before I pour time & money into Odroid, can anyone confirm whether programs (ideally GUI programs) compiled with gcc on Odroid actually work properly when run on a Raspberry Pi Zero or version 1 model B?

Why not circumvent the SD card altogether and boot/run from USB SSD? this is possible on Rpi3.

Yes, that was option #3... if this is the best route, my question is which specific hardware is best for performance and long-term reliability?
 
You might want to consider booting an RPi3 from Western Digital's PiDrive. This setup doesn't stress the SD card very much, as I understand it, since only the initial boot process needs the SD and then it's all HDD. This PiDrive includes a very handy but hard to find cable that supplies power to both the HD and Pi separately so you're not powering the HDD from the Pi's USB.

http://wdlabs.wd.com/category/wd-pidrive/
 
Before I pour time & money into Odroid, can anyone confirm whether programs (ideally GUI programs) compiled with gcc on Odroid actually work properly when run on a Raspberry Pi Zero or version 1 model B?

I would be hesitant to use some non-Raspbian distro. Standard Debian armhf is ARMv7 with hard float, armel is ARMv4 with soft float. Raspbian is ARMv6 with hard float (Pi 1 is ARMv6).

I would also be hesitant to use cross-compilation. If you are very lucky and all your libraries are regularly tested with cross-compilation, things can work quite well. If not, you can drown in obscure problems...

\\

I'm not aware of any micro SD card that has a good SSD-like controller and works well for random writes (they all suffer from massive write amplification).

The Samsung 850 EVO M.2 maximum power consumption is probably more than USB2 allows (may still work with the Pi 3).
 
Yup, looked at Odroid again today. All info I can find says ARMv7, seems unlikely to work for building Raspberry Pi compatible binaries.

I looked again at cross compiling. Found this guide. This part near the end gives me pause:

However, not everything is yet as sweet as the raspberry pictured above. Just because it was the benchmark in a Raspberry forum thread, I also tried to compile Pidgin. After some desperate attempts to get all build dependencies installed, I threw in the towel.

That's a good point about the power consumption. Seems they knew it's likely to be a problem, as the add-on board has an aux power input jack and jumper to configure power source. Of all the possible problems, extra 5V power seems the simplest to solve!

I did find good into about setting an OTP config to boot directly from the USB disk. Hopefully that can work with this model?
 
Hi Paul, I could probably try or...

I know that the binaries that you build run on the Odroid Xu4/Xu3 lite I have. Also likewise on Odroid C1... As for C2 much more problematic as the Linux running on it is 64 bits and I have had some luck awhile ago getting stuff to work, but needed to download compatible 32 bit versions of libraries.

Could maybe loan you one to try. Like maybe an XU3-lite... Need to figure out what state it is in... Probably if I did so, would maybe download a recent version of Ubuntu and flash...
May take me a day or so.. and probably a day or two by mail...
 
https://www.raspberrypi.org/blog/pi-3-booting-part-i-usb-mass-storage-boot/


TBH I didn't know there were any spinning disks that DO power up within 2 seconds. Or, I guess they mean the controller responds, not that the disk finished spinup and is ready to use (?)

I've been booting my Pi3 per this method for about a week and it works great so far, using a WD 'My Passport' (cheapest external I could find at BestBuy). No SD card anymore. Using Raspbian Stretch. I did initially have to retry booting a couple of times after the first boot, no data corruption though. No idea why, but it's now booted without fail a few dozen times. I've ordered the special USB cable that's used with the Western Digital PiDrive that provides potentially more reliable power to the HDD, just in case that's an issue.
 
Hi Paul,
Simple answer, use a RPI3 and backup your sd card. I haven't used anything else to program MCU's except RPI3. Having a problem currently with my new ESP32 Development board "xtensa-ESP-elf-gcc" not available for your operating system. Looks like I'll have to connect my ESP8266 to my Teensy3.6 and wait for the Arduino IDE to catch up with the ESP32 board.
 
I want to get away from using SD card media that's likely to fail after heavy usage. Backups are good, and I do make file-level (but not disk image) backups. But the goal is to get away from media that is going to wear out so quickly from heavy disk I/O.

As far as unclean shutdowns go, they're pretty much a non-issue. This (and other gear) runs from a large uninterruptable power supply that has hot-swappable batteries. I replace the batteries on a 3 year schedule. I'd really like the Raspberry Pi to last much longer than a set of batteries. This SD card has been in service since only January 2015.
 
Yup, looked at Odroid again today. All info I can find says ARMv7, seems unlikely to work for building Raspberry Pi compatible binaries.
Ran a quick test of taking one of my Raspberry pi test programs (try to talk to Dynamixel servos through other hardware like USB2AX or Teensy). I built it on an Odroid XU4, uploaded the binary to my Dev machine using WinSCP. I then used WinSCP to download it to RPI zero W, marked it as executable and tried to run... Segment fault.

Downloaded it back to XU4 different directory, marked executable and it runs...

So unless there are options to restrict the compiler/linker to the minimal Arm??? may not work.
 
The new Raspberry Pi and SSD arrived. I'm setting it up now....

DSC_0712_web.jpg

First quick test, copying the entire Teensyduino build folder (slightly over 500 megabytes) over now takes only 1 minute & 22 seconds. On the old Pi this took 5 minutes & 16 seconds.
 
After getting everything set up, I noticed the compiled code links against much newer libraries.

Previously I was building Linux ARM on Raspbian 2014-12-24-wheezy. I build both the x86 binaries on Ubuntu 10.04.4. Except for some minor cases like libpng, usually building on older systems give the best library compatibility for most Linux users. I've found building on the latest usually means people who haven't updated recently can't run the programs.

So I reinstalled to use Raspbian 2017-07-05-jessie. That's not nearly as old as I was using, but it seems to have libs quite a ways farther back than 2017-08-16-stretch.

Going to need some help testing whether things actually work on other Linux ARM boards....
 
I should be able to try out on a few different platforms...
Like RP (but you already have that ;) I do have RPI3 so 2s sitting around some place and an zero w.

Can try on Odroids: Xu4, C1... Could try C2(64 bit), normally default fails, threads on how to make some/all of it work.
 

I downloaded Arduino 1.8.4 and this test build to Odroid XU4 and they installed properly. I already had the udev rule in place.

I plugged in a Teensy LC to the board and used example Blink which worked.

I then configured USB for Serial, Mouse, Keyboard, Joystick and used the TrangleMove example and it built and the mouse cursor is moving in a triangle

Tomorrow will try C1...

I assume you tried it on RPI 3.
 
Yes, I tested on RPi3.

I'd expect any problems to show up as the installer or Teensy Loader not being able to run with missing or incompatible system libs.
 
Status
Not open for further replies.
Back
Top