Kickstarter Android/Due combo

Saw this today:

http://www.kickstarter.com/projects...category&goback=.gde_1268377_member_232726542

Kinda cool. I don't think it's for me, but this is generally why I ordered a few teensy3's and a couple of Raspberry Pi's.

I'm actually much more interested in the new Beaglebone board. I have 3 on order. Planning to publish some projects using Teensy 3 (for advanced I/O) together with the Beaglebone.....

This project is gonna be funded at $517k currently. I don't know how someone would do that project for $27k, which was their initial goal, but they did say they were already 80% done.

Seeing it again this time, it looks a bit like a thin-pc motherboard. The T3 is the same dimension as the ultrasonic sensor w/o the height in that picture.

Normally I try to refrain from bashing other people's products. But lately I've been doing some benchmarking as part of my effort to improve Teensy 3.0 as much as possible, and Due is among the several boards I've been testing. My testing has left a pretty strong impression....

Arduino Due has really amazing hardware that in theory has tremendous potential. But for people looking to run actual Arduino sketches faster, the core library software for Due is deeply disappointing. To quote "westfw" from Adafruit's forum:

Due seems to have very little optimization. Even things like digtalWrite() are a depressing stack of Arduino on top of Atmel Software Framework on top of CMSIS, resulting in an end speed not-much-faster than an Uno.

Click to expand...

Of course the CPU is fast. But much of what people do with sketches on Arduino is I/O, and a lot of the value of the Arduino environment is a very easy interface to do I/O. One pretty stark example is the USB virtual serial receive test, where even Teensy 2.0 with an 8 bit AVR outperforms Due.

Another area in need of improvement is Due's HardwareSerial code. Due's code does not yet support transmit buffering (beyond the UART's 1-byte buffer and shift register), so Serial.print("something") blocks until the last 2 bytes. There are 4 serial ports, but unless you craft code that sends 1 or 2 bytes at a time, good luck achieving simultaneous data flow (Arduino lacks a transmit buffer available function, and Due's Serial.flush has bug, so you'd end guessing by elapsed time when you can transmit more without stalling the rest of your program). Of course, doing anything else concurrently is similarly difficult if using the hardware serial. Arduino Due's hardware could do so much, but if you write "normal" Arduino sketches, much of that incredible CPU power is wasted in busy loops.

The people behind this kickstarter are advertising this platform based on its raw performance. They're using the hardware serial as their primary interface, not even the less-than-optimal native USB. It really leads me to believe they've really only looked at the hardware specs and done very little benchmarking or application testing, or perhaps even thought much about real-world application performance. It's always possible the software might improve, but I'd guess the odds are they'll deliver incredibly capable hardware that actually performs poorly when used with the intended software.

We at CNMAT passed on the UDOO because of the IO problem Paul mentions.

The designers are in a bind. To deliver on the buzzword aura of
Android, Rasberry PI and Arduino they have to make it shield and IDE compatible which means thatthey can't use, for example, SPI
as the interprocessor communication.

They seem more concerned with making the I/O pins switchable between the processors
than making the shield interface 5V friendly as these folk have done successfully (http://www.digilentinc.com/Products/Detail.cfm?Prod=CHIPKIT-MAX32).

The fastest interconnect is likely to be the OTG USB mode:
http://www.kickstarter.com/projects...x-arduino-in-a-tiny-single-board/posts/456046
The problem Paul mentions with the serial side (too little buffering) has a big impact on the other side. UNIX inspired operating systems have to work on relatively large buffers of data to be efficient because of the cost of context switches. Stalls from the Arduino side will really impact application performance significantly. A few operating systems have addressed this, notably SGI's defunct IRIX. It would appear that OS/X Lion
may be using similar techniques to SGI IRIX (user space buffering and lock-free access to driver) as Paul has shown good performance for small write's in his benchmarking.

As Paul notes there is a long way to go before the Due software delivers the performance potential of the processors. It is possible they have raised enough money to work on this and improve the Due as a result. It is also possible the Due itself may fail. It is in many ways an "odd bird" in the Arduino effort.

Several things about the Due work against the Arduino philosophy of an easy entry point for newbies. It has two USB ports and it is not obvious even for experts which one to use. It has another shield interface incompatible with most existing shields. It has a fancy feature to help shield builders manage the 3.3v/5v issue but I can't find many shield designers who do a second or updated shield design - they usually move onto something else. The software for the Due is forked awkwardly which makes it quite a hurdle to port libraries too (or in my case write a new library for). All these are soluble problems but what will happen probably depends whether users and developers will run toward the $60-150 price point or gravitate around $20. Since I have to equip teaching labs. and spend taxpayers money to do it, it really makes a difference whether it is 60x $20 or 60x $50.