Computing stuff tied to the physical world

Arduino and complexity

In Hardware, Software on Dec 28, 2009 at 00:01

This is – in a nutshell – the Arduino world:

Screen shot 2009-12-27 at 18.53.04.png

In prose: an ATmega board, some hardware peripherals, an environment for embedded software development, a front-end for visualization, and a website to bring all these facets together for a growing worldwide community.

For each of these, there are alternatives and variations. These add variety and increase the number of choices for everyone interested in this low-cost physical computing world. The “Arduino” name is conquering the world, and it sticks … even as “duino” suffix. Names are a great way to create a brand.

But what is Arduino, really? Is it an ATmega? Is it a board that fits in the palm of your hand? Is it a standard for connecting other boards? Is it a standard way of structuring software? Is it defined by a set of standard libraries? Is it the dual aspect of the IDE, i.e. Wiring vs. Processing? Is it the main web site or the discussion forum?

The answer depends no doubt on who you ask. And if this is a healthy ecosystem, then all of these will evolve and improve over time. In my opinion, the current state of an ecosystem is far less important than its ability to evolve.

That’s where complexity comes in.

It’s not hard to construct a great system, even an elaborate one. But what is extremely hard, is to come up with a system which supports evolution of all the pieces involved. Because with multiple pieces, you have to make decisions. You have to interconnect the pieces, and that requires making choices. And once you do, you reduce the number of future paths, including many you don’t even know about yet.

Making choices can be good. Hooking up an Arduino to a PC via a serial connection is a great low-cost solution for uploading, debugging, and interacting. The transition from an RS232 connection + a separate power supply to a USB connection with “built-in” 5V power is an excellent example of how evolution can lead to substantial progress.

Technological evolution can take years. And as in life, that’s where the really interesting stuff happens.

Unfortunately in the Arduino world, I’m hitting some nasty edges which tell me we need more generality or flexibility. I’ll describe a few, in terms of interfaces between the different pieces shown above:

Voltage levels – the most widely used Arduinos are based on 5V, meaning that all their I/O pins are also 5V-based. More and more sensors can only be used with a supply voltage up to 3.6V or so. Interfacing them to a standard Arduino requires the use of level converters. Often, resistors will do – but you can’t simply ignore the issue. This is an area where I2C can help.

Hardware modules – the Arduino “shield” concept doesn’t extend very far, because each shield determines which pins it needs. Pins are a scarce resource, and each pin location on the connector is fixed. It’s hard to design shields which will actually stack with others. Even more so now that there is a new Arduino Mega with slightly different pin allocations.

Software modules – libraries are a great concept: code which is there when you need it, but doesn’t get in the way (i.e. included) if you don’t. Right now, adding a library which depends on say the “Wire” library means that you have to include the Wire library in your sketch even if you don’t ever use it. This is almost a show-stopper.

C/C++ code – on the surface, programming for the Arduino board is like programming in C and C++, with a bunch of very common issues resolved and a wide variety of useful functions available, ready to use. Newbies can get going fast and old hands can find their way around in no time. Except… the IDE does some funky things with headers and declarations. And it breaks a couple of fairly basic C/C++ conventions.

Automation – the IDE works with a specific scenario in mind. As of the latest 0017 release, multiple sketches and consoles are supported. This solves some of the issues, but it’s hard to automate this further: after uploading, I still have to manually launch the serial console. If I have some other app talking to the hardware, there is no mechanism to upload a new sketch and then resume that app because the serial USB connection is dedicated.

Visualization – it’s interesting to see how the Arduino / Wiring / Processing approach is bridging a huge range of hardware in an integrated manner. But there are several choices involved which reduce flexibility towards entirely different approaches. Some visualizations (as well as other types of data processing) would benefit from using a more internet-/web-centric approach. Lower-end hardware cannot support the Java environment used by Processing, so that code can’t be leveraged. There are alternatives. Scripting language support would be useful.

Don’t get me wrong: all these issues are tough ones! It’s probably impossible to solve them all and to make everyone happy. These issues are definitely not things open source software is obliged to address from day one. But my point is that this is not about where we are today, but about having the mechanisms to evolve to where we want to be tomorrow.

If you’ve followed this weblog for a while then you can probably guess that I’ve got some ideas and suggestions on how to move forward on all this. I would really like to help take the existing Arduino platform further – but I’m not sure at this point that it can be done within the current constraints. I don’t even know whether anyone else considers the issues listed above to be important. All I know is that as I continue to add more software and design new hardware, the “push-back” from the current Arduino design choices is increasing… a lot.

Do I want to change the Arduino world (i.e. make a case, convince people, find compromises) – or do I want to sidestep some of its decisions by starting all the way from scratch? I haven’t decided.

  1. Wow you ask a big question? I am a beginner in electronics and coding C and a pair of Jeenodes was the second micro purchase I made after getting an Arduino 2009.

    What I like about the Jeenode is the ports model(wireless too) and your libs. The expanding catalogue of nodes and libs is reassuring. I don’t want to use C and using libs is like skipping all the stuff I find annoying :) You are right about shields – only buses should stack.

    Now I mention the weak point in the Jeenode design for me. I think the connectors implementation isn’t as elegant as other aspects of the Jeenode design. The POF pictures show how ugly it is (at least they are easy to plug together). And the Jeenode is still too large. Sensors need to be small to be in our homes.

    OK those were my thoughts of strengths and weakness of Jeenode. Now to answer your question. I think if you wanted to sidestep Arduino you could make a more focused software/hardware platform – of this I am sure. On the other hand I do not think the Jeenode on Arduino is without improvements to be made and you have a new CNC mill and extruder to play with too.

  2. Please try to convince the Arduino world! Your 3.3 variants still enable us to use other sketches from the Arduino world.

    IMHO the embedded software part is good (just fix the dependency hell). I would like to use the Arduino for low level control (KAKU/FS20, IR) but not for Wifi, Bluetooth or higher level protocols: off the shelve Linux routers (like FONERA) or NAS (NSLU2, Buffalo) can do that more economically. BUT I would like to control/monitor (and upload sketches) the Arduino, attached via USB to this Linux device from my browser. (And connect to your remote nodes via the same connection). First step would be to make a small HTTP server out of the serial console, that also allows you to upload (compiled sketch of firmware) to the Arduino. Next step would be to include URL to command line scripts to Verify/Compile from the browser (the arduino from the commandline parts, where my browser acts as network commandline 2.0).

    In this scenario the Arduino is only part of the total network, so USB/Serial Arduino input/output should be both human readable as easy processable on PC side this should be URL/JSON like but this may be to advanced on the Arduino side, so maybe some mapping is needed. For the Arduino part more appropriate may be the command like structure of the buspirate

    There is already a javascript processing variant (, so I think about experimenting with small server side javascript options like node.js, or

    Being a software guy, if a buspirate, busware CUL/CUN or even a EZ430-Chronos does the trick, I would include that. However Arduino seems to have the most interesting community, and is more software focused than say the Elektor/CC2 ATM18 projects…

    Just my ramblings, regards, Rinie

Comments are closed.