MCU and Pin Assignments for the Power Minder

Rec 22-jan-2008 23:04

In previous posts, I sketched initial concepts for my power minder device. Now it is time to go deeper and start making some choices.

First, I have lots of different AVR MCUs here, but which one shall I use? That depends on what features we need and how many pins we are going to need. So let's try to enumerate those. First, the bare minimum:

I have a number of 8-pin AVR parts I could use, such as the ATtiny13, 45 and 85. I think the first is out of the game because it has only 1KiB of program memory and I intuitively guess the program will be larger than that. Those chips don't have UARTs, but the USI port can emulate UARTs just fine at low speeds -- and remember, our level converter limits us to 9,600 bps.

AVRs have internal RC oscillators for clock generation, but they are not very accurate: 2% at the very best. Using them would make the accuracy of the frequency measurements much too temperature-dependent. So we really need the crystal to be able to get accurate measurements. Using crystals with AVRs is trivial: just connect it (and their loading capacitors) to the appropriate pins in the AVR, for it has a built-in clock generation circuit.

However, if we want LCD and storage, we'll be needing more pins:

HD 44780-compatible LCDs can operate in two modes, using either an 8-bit or 4-bit parallel data bus. In addition, they also need three control pins: E, RS and RW. So, in 8-bit mode we'd need 11 pins and in 4-bit mode we need 7. On the Internet you'll find implementations that use only 6 pins, doing away with the RW signal and using delay loops instead.

We need the ability to turn off the LCD to save power when operating from batteries. I heard there are some LCDs that require a mere 1mA of current to operate. If you're using one of these, you might just as well leave it on all the time. But since I'm not sure exactly how much current my LCDs require, I'll leave that option on.

The I²C (also known as TWI) EEPROM needs only two pins. So our total so far is 18 pins, which takes it out of the reach of my 20-pin ATtiny861s. The ATtiny2313 is the only 20-pin AVR that can deliver 18 usable pins, but they lack an ADC.

So it's looking like it's gonna be the venerable ATmega8, which has the advantage of being reasonably easy to find even here in Brazil. It provides 23 usable pins (22 if you use In-System Programming). We can use the remaining 4 pins for other functions, such as control buttons (+1 pin) or battery voltage sense (+1 ADC pin) to warn us when the battery runs low. While we're at it, we could throw in a buzzer to make it beep when power is lost and see if it happens at the same times my UPS kicks in (it also beeps in these situations.)

An alternative would be to replace the EEPROM with a SD card. These cards have SPI interfaces that match perfectly with the SPI port in the ATmega8. That would increase our pin count to 20: SPI ports needs four signals: SCK (serial clock), MISO (Master-In, Slave-Out), MOSI (Master-Out, Slave in) and CS (chip select). This last can be omitted, but that might prevent us from using In-System Programming (ISP) -- the ISP system uses the SPI port and the SD Card's CS pin is used to tell it "hey, I'm talking to you". If we hardwire the card's CS pin, it will always think that activity in the SPI bus is directed to it, when it might be for the ISP subsystem instead.

SD cards also add other complications. We'd need a 512-byte (perhaps slightly larger) buffer because this is the size of the smallest addressable unit those cards support. The ATmega8 has 1KiB of memory, which is enough, but recall that we may need to read from the card (when the main computer asks us for measurements it may have missed due to an power outage) without interrupting the measurements currently going on. In contrast, I² EEPROMs are byte-addressable.

Furthermore, SD cards need 3.3V and may require up to 60mA of current when writing. Most of them are supposed to have "auto sleep modes" with current consumptions of less than 1mA. But I'm still not sure, though. The LM2931 low dropout regulator we used can narrowly provide this much current, If this sleep mode doesn't work reliably, it will ruin battery life. In contrast, I² EEPROMs require microamps when idle or reading and just a few milliamps for just a few milliseconds when writing.

The big advantage of SD cards is that they provide hundreds of mebibytes of storage at incredibly low prices, so we could record not only the power failure times, but the whole frequency/voltage measurements for maybe years.

I think I should resist the temptation of making this device a mains power datalogger. It is supposed to become a power glitch datalogger: what I'm really interested in is to record exact times and durations of power failures. The frequency and voltage measurements are just the raw materials to achieve that. So, for the time being, I'm going with the little 24C512 64KiB I²C EEPROM as it is the safest choice.

Now, if we use 16 bytes blocks to record an event (more than enough for a 7-byte "year-month-day hour:minute:second.tenths" timestamp plus event identifiers and other parameters), we could store 4096 events in 64KiB. Although we haven't exactly defined what a "power glitch event" is, I intuitively doubt we will need to record more than 10 events per day on average. So we'd have room for >400 days of events, which, being more than an year, seems pretty good to me.

Even if we decided to record average frequency and voltages every 5 minutes (say, for graphing with RRDtool or MRTG) and used the same 16-byte format for that (and we could use much less), we'd have 4096 events / 288 5-minute blocks per day = 14.2 days before the memory fills up. This seems good enough. Besides, we can expand that up to four 24C512s using just the same two pins.

Summing up: an ATmega8 it is, and the preliminary pin assignments will be:

The next step will be to consider how exactly we are going to perform the measuremnts. This will influence clock selection and MCU resource usage choices.

Follow-up posts:

• Calculations for the Power Minder
• Starting Assembly of the Power Glitch Monitor
• Advances with the Power Glitch Monitor