...sine propero notiones

You are here: Kiko > PostsInEnglish > EnBlogEntry2008Jan21A Printable | topic end

Start of topic | Skip to actions
Versão em Português

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:

Qty What for Where connects
2 VCC and GND Power supply
1 Frequency measurement Signal conditioning unit
1 ADC pin for voltage measurement Signal conditioning unit
2 for serial TXD and RXD Isolated RS-232 level converter
2 Clock generator Crystal
8 Subtotal

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:

Qty What for Where connects
7 Display HD 47780-compatible LCD
1 Turn LCD on and off LCD power supply driver
2 I2C EEPROM 24C512 (64KiB)
10 Subtotal

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 I2C (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, I2 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, I2 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 I2C 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:

AVR Pin  
# Name Connected to
1 /RESET ISP connector /RESET line
2 RXD/PD0 RS232 level converter RXD line
3 TXD/PD1 RS223 level converter TXD line
4 INT0/PD2 LCD line E
5 INT1/PD3 LCD line RS
6 XCK/T0/PD4 LCD line D4
7 VCC Voltage Regulator Output
8 GND Ground
9 XTAL1/TOSC1/PB6 Crystal
10 XTAL2/TOSC2/PB7 Crystal
11 T1/PD5 LCD line D5
12 AIN0/PD6 LCD line D6
13 AIN1/PD7 LCD line D7
14 ICP1/PB0 AC waveform input from signal conditioning unit
15 OC1A/PB1 Buzzer
16 /SS/OC1B/PB2 LCD line RW (maybe not needed)
17 MOSI/OC2/PB3 ISP connector MOSI line
18 MISO/PB4 ISP connector MISO line
19 SCK/PB5 ISP connector SCK line
20 AVCC Decoupling
22 GND Ground
23 ADC0/PC0 AC waveform input from signal conditioning unit
24 ADC1/PC1 Battery voltage (after voltage divider)
25 ADC2/PC2 Buttons
26 ADC3/PC3 LCD power

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:


You are here: Kiko > PostsInEnglish > EnBlogEntry2008Jan21A


Creative Commons License   The content of this site is made available under the terms of a Creative Commons License, except where otherwise noted.
  O conteúdo deste site está disponibilizado nos termos de uma Licença Creative Commons, exceto onde dito em contrário.