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 :-)
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
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.
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:
If you have different boards you'll have to figure out the correct
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
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.
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 :-)
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
BOARDare those found in the standard boards.txt file, that file is parsed to extract the relevant values for the Makefile.
PORTis the path of the USB port that the Arduino is attached to.
LIB_DIRSis 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
.pdefiles 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
buildsubdirectory 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; makeafterwards to rebuild everything correctly.
The Makefile builds three archive libraries in the
- 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
- 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!
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 :-)