Arduino barebones board upgraded with 32-bit ARM

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 …

[annodomini2]

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.

[NumptyScrub]

Re: The title is too long!

quote: "The PI can do basic electronic control, but it's not suited to realtime operation."

I'm sure you know more about this than I do, but I'm struggling to understand how an 89MHz ARM CPU is better suited to realtime operation than a 700MHz ARM CPU. I'm assuming that it's the connectivity (Arduino pin selection vs the Pi GPIO header) that makes the distinction?

[Dark Horse]

Re: The title is too long!

<quote>

I'm sure you know more about this than I do, but I'm struggling to understand how an 89MHz ARM CPU is better suited to realtime operation than a 700MHz ARM CPU. I'm assuming that it's the connectivity (Arduino pin selection vs the Pi GPIO header) that makes the distinction?

</quote>

There is a difference between embedded and real-time.

A real time system is a system that will guarantee a response within a set time to an event. You don't want commands to a nuke reactor cool down to be delayed a few milliseconds because the linux kernel decides to spend too much time sorting out its memory paging or something. :)

You can get customised versions of the Linux kernel that can be realtime.

But, the arduino would be coded for a specific task, and only that task. You don't expect to run bittorrent in the background. :) Plus, a 89MHz processor would be cheaper than a 700MHz, for a washing-machine control board.

[NumptyScrub]

Re: The title is too long!

quote: "You can get customised versions of the Linux kernel that can be realtime."

They are both ARM CPUs so I was assuming that the actual "OS" (whatever that is for realtime operation) would run on both with minimal cross-compiling. So, assuming you are running the same control s/w on both, the 700MHz chip offers a far better reaction time than the 89MHz chip. Hence my confusion, and the assumption that I am missing something important :)

quote: "Plus, a 89MHz processor would be cheaper than a 700MHz, for a washing-machine control board."

Given the Arduino in the article is quoted as $49, it's actually a little more expensive than a Pi. It's not more expensive than a Pi with the Gertboard though, which is why I was focussing on the analog options as a possible differentiator between "better for realtime", as I wasn't sure the Pi GPIO supported analog directly.

[Eddie Edwards]

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.

[heyrick]

Re: The title is too long!

"The main point is, Pi boots into Linux, and if you want to change that you're in a world of pain."

Really? A world of pain? http://www.riscosopen.org/

And, because RISC OS is much simpler than Linux, I don't see why you can't singletask, disable interrupts (SWI OS_IntOff) and then do your sampling and such. Not terribly friendly to a multitasking system, but certainly within the reach of a BASIC programmer that knows a little bit of assembler. Good solid '80s style fun.

This Arduino, on the other hand. Do you have to use an HLL or can you go the assembler route?

[Mage]

Re: The title is too long!

Assembler is discouraged by ARM. The lowest level official support for ANY ARM CPU is C.

It's a separate flamewar as to if C is a HLL or not :)

[annodomini2]

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.

http://www.keil.com/support/man/docs/armasm/armasm_cegfdged.htm

For example.

[Amonynous]

Re: The title is too long!

The typical use case of the Arduino series of boards is 'industrial control', for definitions of industrial control that range from home automation through building a better mousetrap and flashing-light fluffy bunny toy for baby through semi-autonomous death robot.

Projects are more about the hardware interface side of things than the software. You have a really simple programming language (subset) that non-coders can learn by hacking around in the most appalling manner (remember learning BASIC on your ZX81 ), with the crutch of a bunch of libraries that just appear when you need them to interface to the various I/O connectors. As you run in to problems, you dig a bit deeper and learn a bit more.

Add in a wide variety of cheap off-the shelf daughter-boards that provide PWM motor control, stepper motor control, multi-relay boards, wireless communications between Arduinos, sensors, flashing lights and (probably) death dealing lasers, plus a community of people who hack around with electronics in an even less structured way than their dreadful approach to coding.

Give that lot to anyone technically inclined but not experienced in industrial control and you'll find it is another really great example of the 'learning by doing' approach to things that the Pi people are trying to push for the coding side. The fact that they have brought out a faster board with more memory and more connectors is great news for those of us with ambitions to build the ultimate death machine.

[Eddie Edwards]

@ heyrick

RISC OS? Don't talk to me about RISC OS :) I used that OS from 1988 to 1995 and ported two iD Software games to it. I have absolutely no interest in playing with it now, and I stand by my "world of pain" comment :) Although I bet my DOOM port would run wonderfully on the Pi at 1080p.

The best way I found to use assembler on the Arduino was to hack up a makefile and just use .s files in your build, although inline assembler is probably an option if you can handle gcc's arcane =r nonsense. Fundamentally it's a standard make system under the covers, so you can do what you like. You can track down the boot.s file and start from there, then you don't even have to call main() at all ;) The boot.s helps you to get your head around gas's syntax, too. And the specific AVR documentation is invaluable to get the cycle counts right.

[Mage]

Re: assumption that I am missing something importan

Yes, the Pi uses a custom boot that has the binary blob for GPU and other chip specific features.

It's not simple at all to change to a different Linux distro without losing functionality, or indeed to have a completely diifferent OS (though work is happening on porting RiscOS as was on Archimedes, but it's a desktop OS too) .

The Broadcom chip specs are not public. The ARM Chip on the Ardunio is public, you can easily write your own bare metal software or simple OS with Timer tick and "round robin" scheduler.

There is a much similarity between some ARMs as 286, Pentium Pro, Xeon and Itanium have. Good luck on getting ANY OS on Arduino ARM to run on Raspberry Pi! Even with recompiling.

The chip on the Arduino ARM is designed specifically for Industrial / Embedded control. Likely has general purpose timers and and general purpose Analogue I/O.

The Raspberry Pi is a mobile phone chip on a breakout board. So not very suitable for embedded applications. There doesn't seem to even be analogue in (USB stick for Audio in certainly).

[James Hughes 1]

@Mage

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.

[Mage]

Real time on Pi

No, it's the OS.

Ordinary Linux or Windows or iOS or OSX can't even reliably do 2.4kHz sampling to read 1124 bps RDS data, or 38KHz OOK modulation without jumping through hoops in a Device Driver, directly in software with a GPIO pin. An 8bit Arduino or PIC can do it easily.

The official support for Pi is a customised Debian flavour of Linux. You need a keyboard, 4G SD card, HDMI screen (composite is too awkwardly low resolution) and USB2go plugged 5V PSU (the USB2go connector is just power, no data). It can't be bricked as the OS boots from SD card.

So to use the GPIO on Raspberry Pi you need to figure how to either boot a "Real Time" version of Linux (which isn't very real time), or better is some other non-Linux OS.

The Multitasking model in Linux can't assure that a user task is run when you want it, no matter how fast the CPU unless a new kernel patched in Device Driver is added.

[Arrrggghh-otron]

Re: Real time on Pi

Put simply there is no OS on an Arduino. The code you write for an Arduino and then upload is all that runs. You code much more closely to the hardware. If you want to know how long something will take on an Arduino, you can find out how many clock cycles it will take to execute that code, work out how long a single clock cycle lasts and multiply them together. It will always be the same (ignoring interrupts) as that is all you will be executing. Hence why you can do real time stuff really well on something so resource constrained.

I'm looking forward to seeing how the DUE is capitalized upon in the 3d Printing world where the Arduino Mega is currently running the majority of RepRaps.

[NumptyScrub]

Re: Real time on Pi

quote: "Put simply there is no OS on an Arduino. The code you write for an Arduino and then upload is all that runs."

Ah, so you are effectively writing the OS for the Arduino. So a suitable custom OS for the Pi could put it in the same bracket... assuming someone had the time and inclination to write it themselves.

Possibly something that won't happen for a while, as I'm assuming most people looking at that price point for a controller will just buy the Arduino for "realtime" implementations, and the Pi for general purpose stuff. It just seemed a massive gulf in relative power (7x slower) for something so similarly priced; they do seem to be aimed at completely different use cases though.

[Arrrggghh-otron]

Re: Real time on Pi

"Ah, so you are effectively writing the OS for the Arduino. So a suitable custom OS for the Pi could put it in the same bracket... assuming someone had the time and inclination to write it themselves."

Not so much an OS, that implies some ability of the OS to manage resources. You could probably write something simple to do that but on an Arduino you are likely going to use up the majority of your resources implementing resource management! (Maybe not so much of a problem on the DUE).

Think of it as a continuous loop (while true do{ My Arduino program}) within which you do stuff that you specify and only the stuff that you need to get the job done. You also specify the resources you use as a result of the code you write. You are responsible for knowing what resources are available to you before you start coding and ensure that you don't overstep those bounds. (Not usually an issue with simple projects)

[Charles Manning]

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.

[annodomini2]

Re: The title is too long!

The main 'real-time' differences are in how the processor operates.

1. Execution path.

2. Interrupt controller operation.

There are RTOS's that will run on a Cortex-M3, such as FreeRTOS.

The main issue is in how the timing operations are handled, for most modern real-time systems (AVR 8-Bit not included :P) they will typically use the Interrupt Controller tied to a timer to give different tasks, being either frequency based (real-time element) or Event based.

The Frequency tasks will typically run continuously with Event based tasks starting and stopping as required.

Priority will be assigned by the various interrupt levels in the interrupt controller, typically with the fastest tasks having the highest priority.

This is not the be all and end all of embedded system design and there are many other techniques out there.

Just a typical approach.

[David_H]

Nice

But is sold out on the Arduino web-store!

[Anonymous Coward]

There's plenty of Arduino style ARM boards. The Maple Mini for instance.

But the problem with ARM boards is availability, you can't really rely on supply of them as they change too fast for people to keep up.

ATMega chips can be bought easily and reliably.

[Eddie Edwards]

w00t

Want. Has anyone got any good project ideas for this so I can justify it to my SO? Maybe something involving keeping babies asleep at night or similar? ;)

[Poor Coco]

Re: w00t

I have been pondering building a robotic train layout that can either drive itself autonomously or be a regular manually-controlled set. I have been looking at Arduino in order to get a wide variety of chips — from the ATTiny85 up to, now, this beast the Due — with a single control language. Communication between dedicated subsystems (signal lighting, for example) and the central controller (probably a Due) can occur via I2C serial.

You could have the train wheels making nice white noise for the baby — just disconnect the lighting in the locomotive, and keep the track out of the reach of toddler hands…

[Androgynous Cupboard]

Re: w00t

I was going to hook one up to an xbee and a moisture sensor to check nappies at one point, until it dawned on me I'd need to extract and reuse the sensors. That quickly put an end to that project...

[druck]

Re: w00t

I've got a Raspberry Pi and like the look of these boards for the digital and analogue I/O, however how do you hook them up to a network so the Raspberry Pi can monitor them?

[Anonymous Coward]

CAN bus as well

This will be very nice in arsenal.

As the first commenter said, the API is not Java, only the IDE is. The API is both Wiring (a C++ related language) and C.

[Androgynous Cupboard]

I have to plug...

This. I've been using a few of Paul's earlier ATMEGA-based Teensy 2.0 boards and they are a joy to work with, and a much smaller form-factor than Arduino too - 3.5x1.8cm. I could never see the point in an embedded board that's bigger than it needs to be, particularly as smaller boards are cheaper.

That said, personally I don't want more power in my embedded systems - small, portable and less current draw for me please.

[Poor Coco]

Re: I have to plug...

That is really neat. I see your plug, and I raise you a plug. The Minuino is not as potent as the Teensy board you cite, but it’s a nice minimum-footprint-and-still-shield-compatible design... and only costs $15. The Sippinos are also cool, and around the same price point.

[Franklin]

Re: I have to plug...

I built a prototype smart sex toy around an Arduino Uno, moved it to a Teensy 2.0 to make it smaller, then went back to the Arduino (this time, and Arduino Nano). I found the Arduino easier to source, and had some weird problems with the output pins on my Teensy board not always responding to digitalWrite() correctly. (I was, to be fair, using the Teensyduino bootloader so as not to have to rewrite all my software, which may have been the problem.)

The Teensy's IDE isn't nearly as polished as the Arduino's, and with the Arduino Mini and Nano (the latter being, bizarrely, larger than the former), the form factor is pretty close to being the same.

[Bruce Hoult]

Wiring

The Arduino documentation is actually really opaque on just what Wiring is. They try to aim things at "artists" who are scared of programming.

What Wiring turns out to be is a source code compatible subset of both Java and C++, along with a library containing classes and functions for memory management, timing, serial I/O, digital and analogue I/O, and so forth.

You can write exactly the same code and run it in either a Java or a C++ environment. This is done with the aid of a preprocessor: in the case of Java the preprocessor wraps your code (variable and function definitions) with scaffolding for a class containing everything; in the case of C++ the preprocessor adds declarations for your functions at the top of the file. In both cases the Wiring library is automatically imported.

When you are using the Arduino IDE there is in fact nothing preventing you from using full C++ rather than merely the Wiring subset. The IDE (which is written in Java) uses a standard copy of gcc (targeting AVR or ARM as appropriate) for the code generation and what runs on the Arduino is machine code.

You can easily link in your own assembly language routines if you want.

[James 100]

Real time != fast

You can quite reasonably have a sub-MHz CPU doing even hard realtime tasks (flight control, process automation): if you're adjusting some parameter every 10ms, but it needs to be every 10ms because 9ms or 11ms causes/prevents the explosion you're intending, that's fine. Conversely, a multi-GHz general purpose computer can fail horribly at real time operation - maybe doing that same job, it could perform the calculation every 1ms ... up until the operating system decides to go and do some memory housekeeping taking 100ms, then your missile has overshot.

Of course, having more cycles to play with tends to give you more freedom - one reason you can get insanely fast Z80s now (100MHz?!): much easier to take your existing real-time Z80 process control code, adjust the delay loops and plug in whatever new feature you needed, rather than start from scratch on a fresh architecture.

Talking of time, I just wish the Pi had a clock! I was surprised to see just how much including one adds to the cost; even a simple battery and basic clock chip would have been noticeable chunks out of their budget. Of course, the real reason is to be faithful to the BBC A/B ... it was only the Master that added the battery, CMOS RAM and clock, after all...