Pervasive Tangibility - arduino en Time of Day Clock with 60 Alarms and PWM Sequence Output <p><a href="/userfiles/image/Clock.png"><img width="300" vspace="5" hspace="5" height="502" border="5" align="left" src="/userfiles/image/Clock.png" alt="" /></a>The so-far-unnamed-project is moving forward. See <a href="sleep">here</a> and <a href="floating_pins">here</a> and <a href="fuses">here</a> 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&nbsp; so-far-unnamed-project only needs one task. The alarm setpoints are held in a header file, also called an <em>include file</em>, 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.</p> <p>CLICK READ MORE TO SEE THE REST OF THE POST</p> <p><a href="" target="_blank">read more</a></p> 32KHz arduino clock include files PROGMEM Mon, 14 Feb 2011 18:50:54 +0000 Ed_B 155 at Arduino at 5volts and 5.3mA, and a Surprise <p>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&nbsp; 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.&nbsp; </p> <p>CLICK READ MORE TO SEE THE REST OF THE POST</p> <p><a href="" target="_blank">read more</a></p> arduino milliamps power PRR Fri, 04 Feb 2011 09:18:30 +0000 Ed_B 152 at Playing with AVR Fuses, Bricked Chips, and Testing for Low Power: Some Notes <p>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 &quot;bricked&quot; 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.</p> <p>------------------------</p> <p>Erase bricked chip and reprogram. </p> <p>Use an Evil board with no xtal or caps, 10K pullup on RST, and a <br /> 1MHz external clock oscillator module connected to pin 9.</p> <p>I'd been trying lots of potential fixes that looked something like this, but<br /> this is the one that finally worked. The differences are the &quot;B&quot;&nbsp; [bitrate?]<br /> switch set to 3 for a high speed spi clock, and no &quot;-v&quot; switches on the command<br /> line. Avrdude may have&nbsp; a bug relating to the -v switch.</p> <p>commandline fu from <a href="" title=""></a></p> <p>&lt;burn&gt;<br /> varmint@Ktootoo:~$ avrdude -B 3 -c avrispmkii -p m168 -P usb -e</p> <p>avrdude: AVR device initialized and ready to accept instructions</p> <p>Reading | ################################################## | 100% 0.01s</p> <p>avrdude: Device signature = 0x1e9406</p> <p>avrdude: erasing chip</p> <p>avrdude: safemode: Fuses OK</p> <p>avrdude done.&nbsp; Thank you.</p> <p>varmint@Ktootoo:~$ <br /> &lt;/burn&gt;</p> <p> CLICK&nbsp;READ&nbsp;MORE&nbsp;TO&nbsp;SEE&nbsp;THE&nbsp;REST&nbsp;OF&nbsp;THE&nbsp;POST</p> <p><a href="" target="_blank">read more</a></p> arduino AVR avrdude bricked fuses Tue, 01 Feb 2011 00:06:04 +0000 Ed_B 151 at