Alan's Ramblings - atmel tag

Why I'm ditching the Arduino software platform

Wed, 29 Feb 2012 20:50:00 GMT

I'm getting set up for my next project and decided to update my development environment. I've finally decided to entirely ditch the Arduino software environment and just use the boards. I stopped using the Arduino IDE some time ago, but now I'm going whole hog and ditching the Arduino library as well. Why? Well, it's simple:

Significant parts of it are pile of junk.

I know that's a pretty strong statement, so I better back it up with evidence. OK, let's start with the hardware serial IO code. Before version 1.0 of the Arduino platform, although reading from the serial ports was interrupt-driven, writing wasn't. Rather, the code went into a spin loop, polling the transmit status bit until the USART was idle before sending the next character. Why was that a problem? Well if you wrote a 80-character string at 9600 baud it would take (8 bits + 1 start bit + 1 stop bit) * 80 / 9600 = 0.083, i.e. 83 milliseconds. That's a huge amount of time for the CPU to be spending just to do some output. I found a number of posts where people were complaining that doing reasonable amounts of IO screwed up all the other bits of their sketches, and no wonder. Admittedly the Arduino 1.0 release notes say that's been changed so that output now uses interrupts as well, but that's not the end of the problems.

Let's take a peek at the HardwareSerial.cpp class. First thing to note is that two 64-byte buffers are allocated for each USART, even if it isn't used. That's 128 bytes on a Duemilanove and 512 bytes on a Mega, or 6% and 12% of the available SRAM respectively. On the Duemilanove that's reasonable as there's only 1 UART, but on the Mega it represents a significant waste of precious memory when only 1 USART is normally going to be in use.

OK, let's look at the new write() function that does interrupt-driven output:

size_t HardwareSerial::write(uint8_t c)
{
  int i = (_tx_buffer->head + 1) % SERIAL_BUFFER_SIZE;

  // If the output buffer is full, there's nothing for it other than to
  // wait for the interrupt handler to empty it a bit
  // ???: return 0 here instead?
  while (i == _tx_buffer->tail)
    ;

  _tx_buffer->buffer[_tx_buffer->head] = c;
  _tx_buffer->head = i;

  sbi(*_ucsrb, _udrie);
  
  return 1;
}

Is there a problem? Let's look at the definition of _tx_buffer:

struct ring_buffer
{
  unsigned char buffer[SERIAL_BUFFER_SIZE];
  volatile unsigned int head;
  volatile unsigned int tail;
};

Oh dear. head and tail are declared as int, i.e. 16 bits, 2 bytes. They are accessed by both the write routine and the interrupt service routine that actually transmits the data yet there's no locking in the write routine so the accesses aren't atomic. Why is that an issue? Well, the avr-libc documentation makes it clear:

A typical example that requires atomic access is a 16 (or more) bit variable that is shared between the main execution path and an ISR. While declaring such a variable as volatile ensures that the compiler will not optimize accesses to it away, it does not guarantee atomic access to it.

The documentation goes on to explain the sorts of symptoms you'll see if you ignore this, follow the link above if you want the full details. This is inexcusably shoddy code - the constraints on accessing variables that are shared between ISR and non-ISR code are well-known. What really concerns me is that people will use the Arduino code as an example of 'good' AVR code and it isn't, in many places it's frankly awful.

"So what?" you say, "That's only one chunk of code that's a bit naff." Unfortunately it's not an isolated instance. Let's move on now to look at one of the newer features that has been added to the Arduino platform, the re-implemented String class. Ok, let's build a minimal program that uses it:

#include "WString.h"
int main(void) {
    String bloat = "hello world";
    return 0;
}

And let's build it:

WString.cpp: In member function ‘int String::lastIndexOf(char, unsigned int) const’:
WString.cpp:503:38: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
WString.cpp: In member function ‘int String::lastIndexOf(const String&, unsigned int) const’:
WString.cpp:519:63: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]

Sigh. One would think that the Arduino developers would at least turn on warnings when they are compiling their code, but they don't. And in this case, the consequence is a bug. So, temporarily comment out the offending lines so we get a successful build, and:

/opt/avr-gcc/bin/avr-size build/test.elf
   text    data     bss     dec     hex filename
  10194      20       5   10219    27eb build/test.elf

Can that really be right? 10K for a one-line program? Unfortunately it is. Any mention of String pulls in the entirety of the class, as well as all the other avr-libc routines it references. So on a Duemilanove that only has 32k to start with, a third of the available memory is gone before you start. At the time the class was being rewritten I expressed my opinion that it was probably a bad idea and that the Arduino developers really needed to target the platform they actually had and not the one they wished they had. And that's not the end of the issues with the String class - on a constrained-memory platform such as the AVR, providing a class like String that relies on malloc, creates lots of temporaries, fragments the (tiny) heap and has no real ability to deal with out-of-memory conditions is a recipe for problems, problems that will manifest themselves as random, mysterious and un-diagnosable run-time errors. And sure enough, a quick google shows that's exactly what tends to happen - just about the worst possible outcome for a platform that's targeted at neophytes.

That's just two examples - there are others as well, such as the well-known performance problems with pin access, which may be up to 50x slower that direct pin access. In fact the only two remaining parts of the Arduino libraries that I still use are the millisecond clock and the serial IO, and they are easy enough to replace, so that's what I'm doing.

While I applaud the aims of the Arduino project, the realities of the restricted hardware platform have to be taken into consideration. In addition, one of the aims of the project is to:

provide a well-designed, maintainable, and stable platform for the future

and despite its unquestionable success on many other fronts, on that one I feel the Arduino platform is less than entirely successful. I for one won't be using any of the software any more, it's just not what I consider to be acceptable quality.

A mention on the Pragmatic Programmer

Sun, 08 May 2011 14:01:41 GMT

I was looking at my Google Analytics and noticed I was getting referrals from the Pragmatic Programmer site, specifically from an article in the April magazine issue entitled Advanced Arduino Hacking. Turns out they were using my Makefile.master as the basis of their article, which describes how to use the Arduino platform without having to use the not-very-good Arduino IDE. OK, I suppose that's a little unfair - the IDE is clearly meant for beginners but if you are an experienced developer or are working on more complex projects it becomes very limiting very quickly, as noted in the article.

There are a number of copies of my Makefile.master floating around, but I'm updating it fairly regularly, so I recommend you grab the original version. Compared to the version on the PragProg site, the current version (at time of writing) has the following improvements:

The only really platform-specific parts of the Makefile are those that deal with running the serial monitor used to connect to the Arduino. On Solaris I use tip whereas on Linux you'd probably want to use something such as screen. I've therefore added platform-specific sections to configure the serial monitor commands to the Makefile.master. I don't currently have settings for MacOS, if someone wants to provide some suggestions, I'll add them in.

I hit a linker bug when using the avr-libc floating-point library, the workaround being to specify -lm both first and last in the linker command-line arguments.

An optional EXTRA_FLAGS macro that can be used to specify any additional flags that you want passed to gcc/g++. I use this for enabling/disabling debugging, e.g. EXTRA_FLAGS=-DDEBUG in my project Makefile.

The automatic tracking of #include dependencies was being done via a separate invocation of the compiler, this has been collapsed into the main compilation step, thus halving the number of times the compiler is invoked. If you don't know what automatic dependency checking is, there's a good explanation here and also in the GNU make documentation.

The generated dependency files are stored in the build subdirectory of the project, but they do tend to clutter things up. I've therefore moved them all into hidden (dot) files.

One final note, the PragProg Makefile.master uses stty -f $(PORT) hupcl to trigger a reset on the arduino before uploading the hex image to it. Not only is that platform-specific, it's also unnecessary if you are using a recent-ish version of avrdude which will do the reset for you if you specify a programmer type of arduino rather than stk500.

ATMega registers and memory ranges

Sun, 10 Apr 2011 16:28:50 GMT

The AVR family has a reasonably complex register and memory architecture, with:

Multiple address spaces
Registers that can be accessed directly and via the memory address space
Register pairs that are used as memory indexes
Restrictions on which registers can be loaded directly with constant values
Some IO ports that appear in both the memory and IO address spaces, but with different addresses in each
Some IO ports that are only accessible via the memory address space

In addition, the gcc compiler has conventions governing which registers it uses for what purpose, for example:

Which registers it uses for purposes such as storing temporary values and zero
Which registers it uses for passing and returning arguments
Which registers it uses as a stack frame pointer
Which registers are saved by the caller on entry to a subroutine and which ones have to be saved by the callee

When I'm reading the assembler output of gcc I find it helpful to have a table to remind me which registers are being used for what, and why. The information is not exactly well-explained in the AVR documentation and I've not been able to find all the information in once place on the Internet, so I've drawn up the following quick-reference table to remind me of what goes where:

Click on the image for a PDF copy of the table. I hope you find this useful, corrections and suggestions welcome - please leave a comment below!

References

EletroAxé with Carlinhos Brown

Fri, 01 Apr 2011 17:17:00 GMT

Carlinhos Brown is a colossus in Brazilian music, known not only for his solo musical career but also for the founding of Timbalada and for reviving the use of the Timbau, one of the instruments I (try to!) play. As part of this year's carnival in Salvador, Kyle McDonald and Lucas Werthein built him a drum suit, with a series of drum triggers linked up to an Arduino and then via wireless to a PC to allow Carlinhos to trigger drum samples by tapping on the pads on the suits. It's a cool project, see the video below and the project page on Lucas's site for the full details.

The very first version of my wireless-controlled LED system was intended to be used on drums, so the EletroAxé project is based on a similar concept. In my case I built a prototype using a vibration sensor mounted on one of the Alfaias that we play in Juba do Leão, the Maracatu group I'm a member of. It worked fine, but then the folks from the Travelling Light Circus came along with their proposal, and the idea of mounting the strips on drums got shelved. However it would be pretty cool to link up something like that suit to the LED system. and as both are arduino-based, it wouldn't be particularly hard either. I have mad visions of this bunch playing at night, all lit up with radio-synchronised LED strips :-)

As it says, "Beautiful light performance"

Fri, 11 Mar 2011 23:01:00 GMT

Well, we did our first performance with the LED strips on Wednesday at Islington Mill in Manchester,and I'm relieved to say they worked flawlessly, even after one of the wheels was dropped just before the performance started! The lighting in the venue was a bit too bright to make a good video, so Andy made a video of the strips in action at Thursday's Travelling Light Circus rehearsal which he's put up on YouTube. Even though I say it myself, I think it's rather good :-)

Seeing the strips in use by the talented TLC performers just gives them an entirely different dimension, and I think the video is really well done as well. For me, one of the best bits of the project has been the opportunity to work with people who have an artistic clue :-)