The so-far-unnamed-project is moving forward. See here and here and here for the rest of the story. The time of day clock now prints onto a serial-input Vaccum Flourescent Display. The clock has up to 60 alarms. All of the alarms fire off a function called runTask(). In the previous version of the code, each alarm task could be tied to a uinque function call. It turns out that the  so-far-unnamed-project only needs one task. The alarm setpoints are held in a header file, also called an include file, which will probably be generated by a Processing app when the arduino stuff is done. The runTask() function requires an array containing about 2000 pwm values. These values live in a header file called performanceData.h. I was very surprised to learn that a user's .h files could not be included at the top of the arduino sketch. It's a long saga, but in short, it's an IDE bug. I wound up making an arduino library to get around the problem. In a library, the .h with the same name as the library, can referece other .h files included by the user. There seem to be programming issues with what you can put in the files (why?), but constant variables will work. The constant arrays are stored in program memory using the PROGMEM macro. This avoids chewing up all the RAM and crashing the AVR chip.


Arduino at 5volts and 5.3mA, and a Surprise

Submitted by Ed_B on Fri, 02/04/2011 - 04:18

An ATmega168 Lilypad Arduino is the basis for a set of design experiments for a larger project. The larger project is not described here. Power consumption is an issue, so I set about trying strategies to reduce Arduino power consumption. As  basis of comparison, measurements were made based on settings that could be changed in a running program, not fuses or circuit adjustments. I set out to get three or four baseline numbers relating to clock speed and internal peripherals. There was a big surprise hiding under a rock: The Arduino-like circuit being tested had by default, active, open input lines that drastically increased the mcu power consumption. The open lines also caused the chip power consumption to fluctuate sporadically on its own, and the fluctuations became more extreme as I moved my hand around the board. It took me a while to notice the correlation between my hand position and the current draw on the mcu, but then the mystery was gone. This is a classic case of the old caveat about not leaving cmos input pins floating -- tie 'em high, or tie 'em low, but don't leave 'em open. In the MCU, two things will fix this in software: set the pin to output, or leave it as input and turn on its internal pullup resistor. 


My current project (not described here) requires adjusting the clock system fuse settings in some arduino '168 and '328 chips. It turns out that there are a couple of things that can go wrong if you burn the wrong clock or SPI (serial) fuses. My pile of "bricked" MCU's was begining to look silly, so I did two things. First I figured out how to un-brick most of the bad ones. Second, I made a thorough study of the fuse settings in the ATmega48/88/168/328 datasheets and the Arduino documentation, particularly the boards.txt file. This text is pasted in from my project's working notes.


Erase bricked chip and reprogram.

Use an Evil board with no xtal or caps, 10K pullup on RST, and a
1MHz external clock oscillator module connected to pin 9.

I'd been trying lots of potential fixes that looked something like this, but
this is the one that finally worked. The differences are the "B"  [bitrate?]
switch set to 3 for a high speed spi clock, and no "-v" switches on the command
line. Avrdude may have  a bug relating to the -v switch.

commandline fu from

varmint@Ktootoo:~$ avrdude -B 3 -c avrispmkii -p m168 -P usb -e

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9406

avrdude: erasing chip

avrdude: safemode: Fuses OK

avrdude done.  Thank you.



Syndicate content