Arduino barebones board upgraded with 32-bit ARM
Eying the Pi in the sky?
Arduino, the microcontroller-based board for DIY electronics fans, has become dipped its finger into the ARM Pi.
The group behind the board has announced the Arduino Due - pronounced ‘doo-ay’, the Italian for ‘two’ - which has an Atmel 32-bit ARM-based CPU in place of the original board’s ATmega microcontroller, also from Atmel. The new chip runs at 84MHz.
The Due also incorporates 512KB of on-board Flash storage, and the CPU has 96KB of on-die Ram. The board has 54 digital input/output pins, 12 analog inputs, four UART serial ports, a USB OTG capable connection, two DACs, an SPI header and a JTAG header.
The Arduino team originally promised an ARM-based version of the board back in 2011.
Unlike the Raspberry Pi, the Arduino is less a general purpose computer designed as a programming tutorial foundation, more a controller unit for electronics projects, though the Pi can be used in such a role too. Arduino is operated using a Java API.
The Due will sell for $49 or equivalent. ®
The title is too long!
"Unlike the Raspberry Pi, the Arduino is less a general purpose computer designed as a programming tutorial foundation, more a controller unit for electronics projects, though the Pi can be used in such a role too. Arduino is operated using a Java API."
The Arduino and PI are aimed at the same market yes, but different purposes.
The PI is a basic PC, provided to allow easier access to programming environments without the risk of breaking an expensive PC.
The Arduino is aimed at real-time control and embedded electronics.
The Arduino is not accessed using a Java API, it's programmed in C/C++ (although other languages can be used with an appropriate tool chain), the Processing based IDE is written in Java.
The PI can do basic electronic control, but it's not suited to realtime operation.
Whilst not trivial, there have been people who have successfully got 'baremetal' code running on the Raspi (i.e. no Linux or other OS). Its certainly not as difficult as you are making out. Also, the specs for the Arm part of the Broadcom SoC are available. It's only the GPU that is closed.
Search for DexOS.
Re: The title is too long!
@Mage, if lowest level official support is limited to C, why does Keil (Owned by ARM) come with an Assembler?
Or why would ARM release they instruction set?
If you wish to code in Assembler on an ARM you can, stop spouting rubbish.
Re: The title is too long!
Well, I hear that it's actually quite difficult to re-target ARM linux for different SoCs.
The main point is, Pi boots into Linux, and if you want to change that you're in a world of pain. The Arduino runs a tiny bootloader then runs your program, effectively in kernel mode from the get-go. You can now write cycle-accurate code that twiddles an I/O pin with interrupts disabled, etc.
Also, cycle-accurate code may actually be *harder* to write on the Pi. Suppose the Pi's ARM has speculative execution, out-of-order execution, branch prediction etc. so it may be impossible to write cycle-accurate code, while *if* the Arduino Due's ARM runs a simple in-order model you can predict the exact cycles at which operations occur. A 700MHz part almost certainly will have some out-of-order and branch prediction; 84MHz may well be the limit at which an ARM can operate without such things.
For instance, on the old 16MHz Arduino, you could write code to "bit-bang" a composite video signal, by writing tightly coded loops and in some cases good-old straight line code with NOPs to make the timing precise. It takes some grappling with the instruction set manual but it's do-able. Presumably (?) on this guy you can do the same kinds of things but at 84MHz. Trying to do that sort of thing with Linux in the way is more than a weekend project.
Also, the new Arduino has 10 or 12 channels of 12-bit ADC at 1Msps which is pretty sweet - you could decode the national timecode transmissions in pure SDR, for instance.
Yes he does know more about it than you do!
"Real time" does not come from faster CPUs. Nor does it come from the connectivity. It comes from writing predictable software.
In real time systems, issues such as boot speed and interrupt latency (ie. event processing) tend to be very critical.
The Pi, running Linux, takes undetermined time to do many things. It has file systems and other bodies of code which inject variable latencies.
The Arduino, OTOH, is designed to run "bare metal". No fat-ass OS. When you twiddle a pin it is by directly writing to registers - not through a hugely abstracted gpio framework.
On some smaller ARM devices I have managed to process almost half a million events per second (interrupts doing just about everything) and have the device boot in far less than a second. You won't get anywhere near that with an ARM embedded system.
Like much of engineering, the trick is in picking the best tools for the job.