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 1
KiB 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
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, I
2 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
2 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
2C 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 |
| 21 | AREF | AVCC |
| 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 |
| 27 | ADC4/SDA/PC4 | I2C EEPROM SDA line |
| 28 | ADC5/SCL/PC5 | I2C EEPROM SCL line |
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:
The content of this site is made available under the terms of a Creative Commons License, except where otherwise noted.