On Sunday we played in the Manchester Day parade. Seemingly about 75,000 people watched, so it's probably our biggest audience yet. There are loads of pictures of us on flickr, and the costumes looked fab so all the work was worthwhile. My only gripe is it wasn't really a traditional Manchester parade as it didn't rain :-)

As I've said in an earlier post, I very quickly found the Arduino IDE to be way too primitive for serious use, so I decided to switch to using NetBeans as an alternative. First step was to create a Makefile, once I had that done I needed to configure NetBeans to use the avg-gcc toolchain, which was pretty straightforward. Ideally I'd just be able export the relevant settings from NetBeans and provide a file you could download and install, but unfortunately NetBeans doesn't provide a way to do this for individual compilers, just all of them at once :-(

First step is to set up a new compiler configuration, Tools -> Options -> C/C++ -> Add. Set the base directory to wherever you have avr-gcc installed, in my case this is under /opt/arduino/hardware/tools/gcc-avr/bin. Set the compiler family to GNU and save.

Then in the Build Tools tab, set the paths for the C compiler, the C++ compiler and for the assembler, i.e. the full paths to avr-gcc, avr-c++ and avr-as. Also set the path for gmake. Clicking on the Versions button should display the versions of the tools.

Switch to the Code Assistance tab, and for both the C and C++ compilers, click the Reset Settings button. This should fill in the default values, the include directories should be set to locations under your avr-gcc install tree. You also need to manually add the directory containing the source of the Arduino libraries to each compiler configuration, in my case this is /opt/arduino/hardware/cores/arduino, and them move it to the top of the include lists.

Finally, switch to the Other tab, and add pde to the list of C++ file extensions, and save. That's the tools set up.

The next steps apply when you are creating a new project and defining its properties. Obviously you need to choose the avr-gcc toolchain to compile the project, and provide a Makefile to build it with - don't use the standard NetBeans one, it won't work.

The Code Assistance sections for both the C and C++ compilers need setting up to refer to any additional library directories you are using, and if you want code completion to work properly you also need to define the requisite preprocessor macros. Do this by setting up a new Configuration for each board type you use, and within that define the macros. I have duemilanove and mega boards, so my settings are:

duemilanove

__AVR_ATmega328P__
F_CPU=16000000L

mega

__AVR_ATmega1280__
F_CPU=16000000L

If you have different boards you'll have to figure out the correct __AVR_ATXXX__ and F_CPU #defines. First find boards.txt in your Arduino install tree and find the section for your board. The f_cpu value is what you need for F_CPU, the other setting is a little more fiddly to find. Get the mcu value, then look that up in the second table on this page to find the corresponding macro that needs to be defined.

As the generated code needs to be run on the Arduino, the normal Run settings don't actually make much sense, but we can re-purpose them for our needs. In the Make section, set the Build Result value to the path of your gmake executable, then in the Run section, set the command-line arguments to upload_monitor. By doing this, when you run the project with F6, NetBeans will run the upload_monitor Makefile target which will build the project, upload it to the board and run the serial monitor.

With all that in place you should be able to use NetBeans as your IDE for developing for the Arduino, including all the nice features such as cross-referencing and code completion. The setup of projects is a little fiddly, so my suggestion is to set up an empty template project that you can copy and then change all the project name references in - I use TEMPLATE as the project name so I can use a little script to clone the project then rename and batch-edit the files with the correct project name.

I've had all sorts of problems getting a SPI radio device to work for the last few days - I wasn't using the default /SS pin to select the slave as I was reusing some code from another program that already used the default /SS pin for a different device. For the life of me I couldn't figure out why I couldn't get it work reliably unless I used the standard /SS pin - if I used a different pin it sometimes worked, but most of the time didn't, or it just worked very slowly, or only if I waggled wires - most baffling. It's perfectly possible to drive multiple SPI devices using a different /SS pin for each, so I was completely stumped as to what was causing the problem. Eventually I noticed this in the documentation:

If /SS is configured as an output, the pin is a general output pin which does not affect the SPI system. Typically, the pin will be driving the /SS pin of the SPI Slave. If /SS is configured as an input, it must be held high to ensure Master SPI operation. If the /SS pin is driven low by peripheral circuitry when the SPI is configured as a Master with the /SS pin defined as an input, the SPI system interprets this as another master selecting the SPI as a slave and starting to send data to it.

And then the penny finally dropped - because I wasn't using the default /SS pin it wasn't being explicitly configured, which meant it was in the default post-reset state. The default post-reset state for pins is to be configured for input. That meant that any noise on the pin would trigger the logic that switched the AVR from SPI master to SPI slave mode, and things would apparently lock up, or generally start behaving oddly. It was easy enough to confirm this, I simply configured the default /SS pin to be an output pin, even thought I wasn't using it, and the problem went away.

Moral of the story: When using multiple SPI devices, always use the default /SS pin to control one of them.

Meta-moral of the story: Always re-read the documentation thoroughly when you have unexplained problems :-)

When I started tinkering with Arduinos I started out with the standard Arduino IDE. It's great for getting started quickly but for more complex work, such as those involving libraries shared between Sketches, it quickly becomes limiting. What I wanted was to continue using the standard Arduino libraries but to switch to a more capable IDE. I already use NetBeans so I wanted to try to use that if possible. The first step was to come up with a way of building Arduino Sketches from outside the Arduino IDE. The Arduino distribution includes a number of old, deprecated Makefiles, but nothing that was really usable. I therefore set to and wrote my own. I've followed the standard layout we use at work, with a 'master' Makefile that contains most of the logic, which is then included into a per-project Makefile that sets up the required configuration for the rules in the master Makefile. It is available here. An example project Makefile looks like this:

BOARD = atmega328
PORT = /dev/term/0
LIB_DIRS = ../Common/Task ../Common/VirtualWire
include ../Makefile.master

Some notes about how to use the Makefile:

• At the moment the Makefile is pretty Solaris-specific, because I haven't had the time to get it all going under a Linux VM, although the required changes are simple. Patches are welcome :-)


• You'll need the standard Arduino environment installed first, either version 0018 or 0019.


• You must use gmake as your make implementation - not usually a problem as it comes included in the Arduino environment.


• The valid values for BOARD are those found in the standard boards.txt file, that file is parsed to extract the relevant values for the Makefile. PORT is the path of the USB port that the Arduino is attached to. LIB_DIRS is a list of directories containing any libraries that you want to use.


• The following targets are provided in the Makefile:
  
  
  • all - build everything (default).
  • clean - remove all generated files.
  • upload - build everything and upload to the board.
  • monitor - run the serial monitor.
  • upload_monitor - build everything, upload to the board and run the serial monitor.


• You don't need to explicitly list the various .c, .cpp and .pde files that make up your application, the makefile assumes that any such files it finds in the various source directories are all to be compiled.


• The processing of the Sketch (.pde) files is very simplistic, much more so than the processing done by the Arduino IDE. There's talk on the Arduino development list of splitting the Sketch-to-C++ processing out into a separate library so it can be reused, but it hasn't happened yet. I've actually stopped using .pde files and now just write my own main.cpp, it's simple enough not to be any sort of an inconvenience to do so.


• The output is all created in the build subdirectory of the Sketch's directory. That means it doesn't interfere with anything if you still want to be able to use the standard Arduino environment.


• Unlike the Arduino IDE which rebuilds everything every time, the Makefile only builds files that have changed. One caveat: if you change the board type in the Makefile, be sure to run make clean; make afterwards to rebuild everything correctly.


• The Makefile builds three archive libraries in the build directory:
  
  
  • libarduino.a - this contains the object code of the standard Arduino run-time libraries.
  • liblibrary.a - this contains the object code of any libraries you specified in the LIB_DIRS Makefile variable.
  • libsketch.a - this contains the object code of the files that comprise your Sketch.
  
  The use of archive libraries allows the linker to only include object files that provide referenced symbols, which will result in smaller executables if you use libraries that contain code that you don't actually use in your Sketch.

I tried offering the Makefile to the Arduino developers but they seem a little, ummm... reluctant to take contributions in areas outside of their immediate goals. I understand they want to concentrate their efforts on their priorities, but if they want to grow the pool of people developing the Arduino platform (as opposed to growing the community developing on the platform) they are going to have to change their approach. It's not just me that has had this experience, the changes for the Solaris Arduino port also haven't made their way back in.

I'll write a followup post on how I've used the Makefile to enable me to use NetBeans as my Arduino development environment, including all the nice features such as code completion, pre-compilation error checking and syntax highlighting, so please check back for more!

I've migrated and merged my old blogs.sun.com and bleaklow.com blogs into this new one, using Pebble. As a result, there are a number of links out there on the interwebs to bleaklow.com that are now broken, as everything has moved around - google's webmaster tools gives me a comprehensive list. If I was hosting this blog using Apache, the standard solution would be to use the most excellent mod-rewrite Apache module to redirect the broken links to somewhere appropriate. However Pebble is a J2EE application and uses Tomcat instead of Apache. I've been looking for an equivalent to mod-rewrite for a while and never managed to find anything. Whilst looking for something else entirely (always the way) I found Url Rewrite Filter. This is functional equivalent to mod-rewrite for J2EE servers, and offers most of the same features as mod-rewrite. I'm using it and it seems to do the job just fine, and the beta even has a mod-rewrite style configuration option, if you need a security blanket :-)