Now's the time to roll up your sleeves and yank that AVR controller IC, design a custom board, and start developing directly with the avr-gcc toolchain. Wait... what?
This is a fundamental problem with the beginning hobbyist and rapid prototyping nature of Arduino. There are obvious transition paths when you simply need more hardware resources. The Mega 2560, with its abundant I/O, RAM, and flash is clearly more capable than an Uno. The Arduino Due is fast, but may not be worth the loss of compatibility and ubiquity. Once you start exploring the world of custom and specialized 'duinos it's easy to become overwhelmed by the choices. There's no obvious path from beginning experimenter to serious project builder.
As I've progressed with Arduino, I've learned which boards to buy by making wrong choices and wasting money. Maybe you won't have to. Here are some general recommendations:
- Avoid prototyping boards with custom I/O.
That 'duino with built in Bluetooth or Ethernet may be tempting, but adding I/O modules to standard boards is more flexible and provides useful experience.
- Choose modules over shields.
Using multiple shields will eventually lead to pin conflicts. Shields are also constrained by the Uno form factor. Modules can be more easily moved between different types and sizes of controller.
- Build out your own proto shields or boards.
Perma-proto shields can be useful to consolidate modules, connectors, and small circuits as you progress from prototyping toward deployment. At some point you'll need to get that tangled mess of prototyping wires, modules, and components into a more compact, organized, and ruggedized form factor. Perma-proto shields are a decent way to customize interfacing for your project.
- Plan your prototyping and deployment requirements.
Determine early your physical requirements and controller specifications for both prototyping and deployment. That Uno or Mega might be great for prototyping, but not quite cut it for deployment in tight spaces or harsh conditions.
- Select boards in pairs.
To progress from prototyping to deployment you're better off with two (or more) controller boards. I'm currently liking the compatibility of prototyping on the Uno and deploying on the Adafruit Pro Trinket. You can build your own little shields to stack on the Trinkets.
|A sampling of prototyping boards.|
The Arduino development app is great for beginners. For actual software development it's extremely limited. Yet again the intermediate developers are left to fend for themselves. All the thirdparty libraries and examples are written to be used from the standard IDE and runtime that are borderline unusable for production software.
I probably don't need to explain what's wrong with the Arduino IDE. It's simply extremely limited when compared to environments like Eclipse. That said, it's not unbearable to continue using the Arduino IDE for your .ino projects and use a better editor or complete IDE to organize most of your functionality into libraries.
The real problem with Arduino development is that the libraries and runtime are awful. The AVR microcontroller underlying most 'duinos doesn't typically run an operating system with processes and threads as you would find on a single board computer like the Raspberry Pi. Your Arduino project and supporting runtime library are your operating system!
The standard runtime works if you're only trying to do a very limited number of things and don't require fast real-time response. The fundamental problem is the linear nature of the standard runtime and libraries and the acceptance of millisecond level delays. It's simply unacceptable that library routines block the execution of other code for many thousands of instructions. What is needed is an asynchronous programming approach with asynchronous I/O, events/callbacks, and timers. This approach can prevent missed I/O events, allow events to happen at predictable times, and still allow the controller's processor to sleep when it's not needed.
The frustrating nature of standard Arduino development almost caused this experienced software developer to abandon Arduino entirely. Fortunately someone else who had experienced these same problems made the effort to do something about the situation. Enter Cosa, "An Object Oriented Platform for Arduino Programming."
Getting into Cosa takes a bit of time, but I strongly recommend taken the plunge as early as possible. Dive in there and start converting libraries to fit the framework of Cosa helper classes. Arduino was screaming out for asynchronous OO development and Cosa is what exists and works.
So where does the intermediate developer with a couple projects under the belt go next? I can only speak from my own experience. With the availability of tiny 'duino boards, I don't feel a strong impulse to design custom controller PCBs when I can stack or socket existing boards. With Cosa I don't currently feel the need to develop directly with the avr-gcc toolchain. I've found an environment where I can get things done.
Would I step up to the ARM-based Arduino Due for more demanding projects? Probably not as things currently sit. Either arduino.cc, arduino.org, or Adafruit would do well to negotiate with Mikael Patel to embrace and enhance the Cosa environment while extending it to the Due board. Without a solid software ecosystem that can work for beginning, intermediate, and advanced developers, Arduino seems destined to become yet another legacy embedded platform. Tick, tock, Arduino. The TI LaunchPad is looking really tempting right now...