As the LED strips are going to be mobile, I needed to find a way of powering them. After some investigation, the 7.2 volt NiMH battery packs used by radio controlled cars seemed like a good choice - they are high capacity, relatively cheap and readily available. Although the Arduino Pro Mini has an on-board regulator, the HL1606 strips don't and according to the datasheet they need between 3V and 5.5V, with 5V being the preferred voltage. That meant dropping the 7.2V from the batteries down to 5V. The obvious first choice was the venerable (and cheap) 7805, specifically the 2A version - STElectronics L78S05CV. I'd need 2 regs for each LED set to give the required 4A. The regs are £0.62 from BitsBox, with heatsinks and the recommended caps the total cost was about £3.00 per LED set. There was only one problem though, the 7805 datasheet says the minimum input voltage is 8V, the batteries only output 7.2, so it seemed they wouldn't work.

The next option was a LDO regulator such as the LM2940 but although they have a dropout voltage of only 0.5V, they are only rated at 1A and are £1.44 each, which would mean that the parts for each LED set would be over £9.00 - ouch. Other options included a homebrew switching regulator such as this one - not ideal because of the increased build and testing time, or a off-the-shelf switching regulator such as the PTH08T231W - again, not ideal because of cost - £11.00 each, plus £12.00 delivery from Mouser.

Bearing in mind this project is cost-constrained, none of the alternatives to the 7805 really looked viable. I decided to buy a couple of 7805s and see if they would actually work, despite what the datasheet said. What I needed to do was to use a 7805 to power my 2-strip prototype with a range of different input voltages, and that required something I didn't have, a variable output bench power supply - and at about £100, it wasn't something I was going to rush out and buy. Bob from Hacman pointed me in the direction of FabLab, and an email confirmed that they had a suitable bench power supply. As an aside, FabLab is a wonderful (and free!) resource that has all sorts of toys such as a laser cutter, a milling machine, a 3D printer and a CNC router - highly recommended!

The first test measured max/min output voltage against input voltage, using my standard test pattern set. The graph is below:

Things of note:

• Vout never got above 4.85V. That's obviously less than 5V, but still within the spec for the 7805, which is 4.8V to 5.2V. I compared a couple of regs, they were all much the same.
• As Vin drops, Vout and quality of the regulation also drops. At Vin of 5.5V Vout swings by about 0.6V.
• Above Vin of 7V the load-induced Vout swing is around 0.1V.
• Below Vout of around 5.5V the operation of the strips became unstable. The datasheet says they will work down to 3V, but like much of the information in there, it's incorrect.
• There was little perceived change in LED brightness across the usable voltage range.

The second test measured input and output current against input voltage, with all 20 LEDs turned fully on (R+G+B on 100%), representing the maximum load the LED strips can generate. The graph is below:

Things of note:

• Maximum load was at 7.2V and above, with Ain of 1.7A and Aout of 1.67A.
• Below Vin of 7.2V Ain & Aout dropped fairly linearly with Vin.
• Below Vin of 6V the LED strips became unstable.
• The heatsink on the 7805 got very hot with voltages above 7V, increasing as the Vin increased. That's expected as the 7805 is a linear regulator and it dissipates the difference between Vin and Vout as heat, but a heatsink is absolutely necessary.

Much to my surprise, it appears that the 7805 will be OK for my application. The information I've found for NiMH battery performance suggests they have a flat output voltage of around 1.1V per cell until around 80% discharge, at which point the output voltage drops rapidly, That means I'll be getting about 6.6V from each pack, which whilst not ideal is certainly workable. The best solution would be a switched mode regulator, but as cost is a major constraint for this project, that isn't really an option.

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/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 the AVR versions of gcc, c++ and 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 argument to upload. By doing this, when you run the project with F6, NetBeans will run the upload Makefile target which will build the project and upload it to the board. If you want to build, upload and run the serial monitor, set the argument to upload_monitor instead,.

     

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!

Update

Martin Oldfield has done more-or less the same thing, with more of a Linux slant. His version can be found here.

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 :-)