Computing stuff tied to the physical world

More about the Odroid/U2

In Hardware, Linux, ARM on Jun 23, 2013 at 00:01

As mentioned recently, there are many alternatives to the Raspberry Pi. I’m looking mostly at ARM-based systems these days, because Node.js support for MIPS is not really there (yet?), and you really want a JIT-type system to get the most out of a Node.js based setup.

Well, having received the Odroid/U2, first thing I had to do is get a micro-HDMI to HDMI adapter (always some new connector/cable type, yawn…). Also had to get a 16 GB µSD card, because the Debian image I wanted to try was for cards of 8 GB or more (yawn!).

But now that everything is in, I’m finally able to take that little black cube for a spin:


First impression: it’s fast, much snappier than a Raspberry Pi. Try launching aptitude, for example – which takes a long time on RPi’s and other low-end ARM & MIPS systems.

Both are running class-10 SD cards, as far as I can tell. The RPi is running at 700 MHz:

# cat /proc/cpuinfo 
Processor   : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS    : 697.95
Features    : swp half thumb fastmult vfp edsp java tls 
Hardware    : BCM2708

The OU2 has four cores running at 1.7 GHz:

# cat /proc/cpuinfo 
Processor   : ARMv7 Processor rev 0 (v7l)
processor   : 0
BogoMIPS    : 1992.29
processor   : 1
BogoMIPS    : 1992.29
processor   : 2
BogoMIPS    : 1992.29
processor   : 3
BogoMIPS    : 1992.29
Features    : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls 
Hardware    : ODROIDU2

Disk speeds are interesting, first RPi then OU2:

# hdparm -tT /dev/mmcblk0
 Timing cached reads:   340 MB in  2.00 seconds = 169.91 MB/sec
 Timing buffered disk reads:  62 MB in  3.00 seconds =  20.66 MB/sec

# hdparm -tT /dev/mmcblk0
 Timing cached reads:   1616 MB in  2.00 seconds = 808.23 MB/sec
 Timing buffered disk reads:  52 MB in  3.05 seconds =  17.03 MB/sec

I haven’t set up the eMMC card yet, which is said to be several times faster than µSD.

Power consumption of the OU2 is 2.9 W on the AC mains side of a little 5V adapter I’m using. Not bad. I’m tempted to try and set this up as my only always-on server here at JeeLabs, including all the web server stuff even. There’s 2 GB of RAM in this thing, should be enough to run some serious stuff. Perhaps even the (Java-based) CrashPlan backup system I’ve been using for almost a year now.

I don’t really care that much about file storage – a 64 GB eMMC disk would be plenty for everything that needs to be online here at all times, perhaps with an external 2.5″ USB hard disk for secondary / archival backup.

  1. Hello

    While this one is clearly coloured as a “development platform” (provided as a raw board with heat sink), there are a lot of Android-ARM based platforms available on eBay ranging from ~30€ (dual-core 1.6GHz RK3066) to >80€ (quad-core 1.8GHz RK3188). They generally include USB host, HDMI output, SD-card and optionally Bluetooth. Most have the form factor of a “HDMI-key” (like USB key but with HDMI) or a more standard box type.

    They don’t have specific I/O (understand for D.I.Y.) connectors but the ODroid neither seems to have so. They can probably be removed from their original casing to be integrated with our own tricks using USB (FTDI? ATmega?)

    It’s been 2 months I am looking at those without stepping to the “purchase now” button. I was wondering if any out there have tried such device for other purpose than just a Google TV Box.

    What do you think of such things ?

    To find such items at good price you need in your eBay to go to advanced search and allow the search to be performed world wide. Then I choose “immediate purchase only”, and order as “lowest to highest price + shipment”). Keyworks can be “MK802”, “android 4 tv box”, “android 4 pc”

    Below are some links for information. Do not hesitate to delete, I don’t mean any advertisement.

    Some units are found here, here and here.

    • Thanks. Indeed – the more I look, the more options and alternatives I seem to bump into. I think the only conclusion right now can be that the number and range of these options is still bound to increase a lot in the near future. It’s a bit frustrating not to be able to pick one and run with it, but still… choice is good. Hardware continues to become more and more irrelevant – as long as it’s all some fairly standard version of Linux – i.e. Debian, OpenWrt, or Android – I’m hoping that much of what we build on top will work with many of these boards, and well into the future.

  2. I’m not sure I’d be comfortable using an odroid product in an application you want to really last. They make good hardware at very good prices, I have one of the odroid-7 tablets. but will you be able to get a replacement if needed 5 years from now? or will you have to port your services to a new platform? Probably not a tremendous task to take on if you need to, but when you would rather just drop in a replacement hardware unit and transfer your sd card, it could be inconvenient. Just a thought. I like the fact that the rpi is so popular, though your mention of platform changes within a single model designation really does raise some concern.

    The APC boards have caught my attention, because that seems a little more “professional” than either. I haven’t bought one yet though.

    • I don’t think any hardware we pick today will be as convenient, fast, energy efficient, small, or easy to connect as what we’ll have 5..10 years from now – partly due to Moore’s law.

      And although I like the RPi, for some things it’s still bound to be either too large, too slow, too power hungry, too limited, or too expensive. That’s not a weakness of the RPi, that’s because problems vary in their requirements.

  3. How software-compatible is the Odroid with the RPi? What I’ve found in the past with systems such as ddWRT and others is that it’s really, really convenient when one can pick up newer versions of the OS and of applications year after year. Having to compile a system from scratch or having to install apps from scratch gets old quick, and usually is prefixed with a day or two of figuring out how to do it given the inevitable changes. (By “apps” I mean utility apps like owserver for one-wire peripherals or wifi goodies, etc., not GUI apps.) Given the popularity of the RPi I expect that there will be a significant stream of updates for a long time. Can I load an RPi version of Linux and RPi binaries onto an ODroid?

    • Can I load an RPi version of Linux and RPi binaries onto an ODroid?

      No. Kernels differ. But you could install Debian Wheezy, and end up with a system which is more or less identical to Raspbian. Since both are based on the armhf build, binaries should run as is on either.

      Update: Hmmm… that could make the Odroid/U2 a neat fast build setup for RPi apps.

    • Why not just cross-compile from x86 JC? That must be the fastest.

    • Sure, cross-compilation on a fast machine would be fine – but for development and speedy edit/debug cycles I still tend to prefer native compilation.

  4. WRT I/O: since everything has USB does it make sense to build I/O capability around it? For example, FTI has a FT220X USB-to-SPI chip and a FT240X USB-to-parallel chip (see I have not worked with these nor priced them out, but maybe that’s an avenue for adding digital and analog I/O? Maybe this has already been explored to death in the RPi community?

    • Mhh, this looks interesting, at least shows that there are a lot of options: UM232H-B Breakout Module. Claims support for a lot of buses. I also like “Device supplied pre-programmed with unique USB serial number.”

    • Evidently the FTDI FT232R can be used for I2C:

    • Using USB can be really slow in some senarios. I had a PIC progrmmer that used RS232 interface. When used in “direct connection” (to a P3-700!) it programmed the PIC in about 7 to 10 seconds. When connected via an USB adapter, it took more than 3 minutes! USB is optimized for “packets”, not bits or bytes. If you need speed and bit-level access, then better you use a dedicated device that speaks the needed protocol on a side and USB on the other, w/ some “intelligence” in the middle.

    • FWIW, I agree with NdK that USB is not always very real time. Hick-ups tend to occur – I probably wouldn’t want to go through USB for all types of Physical Computing hookups.

Comments are closed.