This appendix is about how to think about a problem.
When you decide you need to design an instrument or device to perform a specific task, the first thing you need to know is exactly what you want the device to do. This is not as simple as it seems at first glance. Let’s take a close look at a fairly straightforward example.
We have a small lead cell battery that provides about 6 amps hours at about 12 volts. We need to monitor the condition of this battery at all times for a relatively critical application. The simple answer to this is that we need to “monitor the voltage of the battery” to see if everything is OK. That is, of course, true, but there is a lot more to it than that. Let’s let our imagination run wild for a moment and think about what might be possible with the skills we are acquiring.
We could say: all we need to see is a green LED for “All is OK” and that is it!
But we can do a lot more than that when we become expert MCU programmers. Let’s take look at what else might be possible.
If the situation is intermediate, we can turn on a yellow LED.
If things are getting near needing attention, we can turn on an orange LED.
If things are bad, we can turn on a blinking red LED.
We can use a test button to put a small load on the battery for one second and then report the voltage on one line of an LCD.
We could reset a timer that tells us when the battery was last tested and display the time elapsed on the LCD.
We could use a real-time clock function that tells how long it has been in days, hours, minutes, and seconds since the last full charge. We want this to reset automatically when the battery is charged. We can display this on the second line of an LCD.
We might want to display how many volts the charge got the battery up to, to gauge the condition of the battery as it ages. We might want to wait 15 minutes before taking the reading to let the cell settle down first so as to make sure our reading was more accurate.
We could monitor the voltage of the battery once a day and then turn on the charger for a specific time to recharge the battery so we do not overcharge the battery and dry it out.
We could monitor each cell in the battery separately and report on its condition constantly if we were in a space capsule.
We could transmit the condition of the battery to a central maintenance location once a day for maintenance follow-up.
We could add a sleep cycle to our program to minimize our instrument’s current draw from the battery.
In order to affect most of the preceding points, we will need a certain amount of hardware. Let’s take a closer look at what we need:
An LCD display with two lines of 16 characters each
Four LEDs: green, yellow, orange, and red for our indicators
One MCU with the following minimum properties:
Seven lines for the LCD
Four lines for the LEDs
One output line for the charge connection switch
One input line to measure the voltage
One input line to reset and/or start measurements
Two lines for a communications port, RS232 protocol
All this is well within the capabilities of the PIC 16F877A we have been experimenting with, but there are a number of less expensive MCUs that can do the job.
How could we improve on this design?
Since you may well be using a small lead acid battery in your shop (it is often the best of all possible choices for a rechargeable shop battery), you may want to implement a controller for your own personal use based on the previous discussion.