R60 A Home Heating & Lighting Controller, Part 3 The Computer Hardware Jay Sage In the two previous installments on the embedded¨ controller that runs the electrical and heating systems in¨ my house, I described first the history behind its¨ development and the control strategy it applies to managing¨ the heating system and then the electrical interface between¨ the controller and the 120 V electrical system. Since TCJ¨ is, after all, a magazine about computers, it seems high¨ time that I talk about the controller itself, and that is¨ what I will do now. There is no sense going into the full schematics of the¨ circuit. This controller was designed and built ten years¨ ago, and integrated circuit technology has advanced¨ tremendously since that time. Besides, to be completely¨ honest, I cannot find a full set of up-to-date schematics.¨ Quite a few changes were introduced along the way, and their¨ documentation is embarrassingly sketchy. In addition, after¨ all these years, I no longer remember in detail how each¨ part of the circuit was intended to function. The above notwithstanding, my main reason for not going¨ into all the details is that, were I going to implement the¨ functionality of this controller today, I would not use the¨ same circuit design. Nevertheless, there are some useful¨ things I can say about the design that, I think, still apply¨ today. It is also interesting perhaps from an historical¨ perspective to see how such a controller was implemented ten¨ years ago. Overall Description of the Hardware ----------------------------------- Most of the controller is housed in a small wooden box (a¨ previous hobby was woodworking) mounted on the wall of our¨ hallway. Figure 1 is a drawing that I made for a talk¨ presented to the Lincoln Laboratory computer club just after¨ I joined the lab in 1982. The box is about 9 inches high and¨ 7.5 inches wide. It is open on the bottom, where a reset¨ button and a power switch can be accessed by reaching under¨ the box. The top is also open, but a metal grill is¨ installed to prevent objects from falling in. This¨ arrangement provides excellent cooling! The operator provides input to the controller via a¨ hexadecimal keypad. Numbers are entered directly, while¨ functions are invoked by holding down a small pushbutton¨ switch in the lower right corner while a number key is¨ pressed. That pushbutton switch acts, if you will, as a¨ shift key. Information from the controller to the operator is¨ provided by a 16-digit 7-segment LED display. This unit was¨ intended to display numbers in calculator applications, but¨ with some ingenuity I was able to generate reasonable¨ approximations to many letters as well. In Fig. 1, for¨ example, the word "ALL" is displayed. Since some letters¨ cannot be formed (e.g., G, J, K, M, and T), a lot of thought¨ had to go into devising appropriate display messages! Inside the box are two boards with the main computer¨ circuitry. The first board was to contain the actual¨ computer, while the second board would take care of analog¨ signal conditioning and analog-to-digital conversion. Later,¨ some additions to the main computer overflowed onto the¨ second board as well. Wirewrap sockets installed in prototyping "perf" boards¨ were used for mounting all components, both integrated¨ circuits and passive devices (mounted in carriers). A Vector¨ Slit-n-Wrap tool was used to wirewrap the circuits. This¨ tool really expedites such work because it slits the special¨ wire as it wraps it onto the wirewrapping posts. The wire is¨ cut after it is wrapped, and one can diasy-chain the¨ connections when lots of pins are bussed together, as¨ happens often in computer circuits. Some additional hardware is mounted near the ceiling in¨ the basement below the control panel. The power supply,¨ which we will describe in more detail later, is there. So is¨ the board with the relay drivers that we described last¨ time. All the high-frequency circuitry is on the boards in¨ the control panel, but the low-frequency and interface¨ circuitry was kept out of the control panel to minimize its¨ size and the number of wires that would have to go to and¨ from it. The General Design Philosophy ----------------------------- Before delving into the specifics of the circuits, I¨ would like to say something about the general approach I¨ took with the design. When cost is an issue -- as when one¨ anticipates high volume production -- one tries to avoid¨ costly parts, even at the expense of more complicated¨ designs and, especially, more complicated software. Since I¨ anticipated building only one of these controllers and since¨ I wanted to spend my programming time on the functional¨ software and not on low-level interface issues, whenever¨ possible I chose high-level chips that performed low-level¨ tasks in the hardware. Spending $20 on a fancy new IC was¨ better than spending two weeks writing and debugging¨ software. There will be several examples of this discussed¨ below. Some Circuit Details -------------------- The CPU A highly abstracted schematic of the main bus of the¨ controller is shown in Fig. 2. The controller was designed¨ around the state of the art CPU at the time, the Intel 8085.¨ By multiplexing its data and address signals onto the same¨ pins, the 8085 freed up enough pins to implement additional¨ I/O functions on the chip. Among these are a single-bit¨ input port and a single-bit output port. These can be used¨ to implement a bidirectional serial interface. I made no use¨ of them, however. More importantly, the 8085 contains an integral¨ prioritized interrupt controller and four vectored interrupt¨ inputs ('vectored' because they force execution of specific¨ code addresses and do not require an external controller to¨ jam instructions onto the bus as with the standard interrupt¨ input, also present on the chip). These I used to great¨ advantage. One interrupt line is called TRAP and is non-maskable¨ (always active). Three maskable interrupt pins -- named¨ RST5.5, RST6.5, and RST7.5 -- are controlled by a special¨ CPU register via 8085-specific opcodes: SIM (Set Interrupt¨ Mask) and RIM (Read Interrupt Mask). These interrupts¨ generate calls to locations in the base page of memory, just¨ like the standard RST (Restart) opcodes. The addresses¨ called are midway between those called by the RST¨ instructions -- hence the names. To facilitate the design of very small controllers, Intel¨ provided a whole family of chips designed to interface¨ easily to the 8085. These chips include on-chip circuitry to¨ demux the data and address buses. I used several chips from¨ this family, but I also used conventional microprocessor bus¨ ICs. Thus I had to provide external bus demuxing circuitry. Memory First, the computer obviously needed memory. This took¨ two forms in the controller: RAM and ROM. The RAM was¨ provided by the 8155 multifunction companion chip to the¨ 8085. Within its 40-pin package, the 8155 provides 256 bytes¨ of RAM along with three parallel I/O ports (a total of 22¨ bits), and a counter/timer. Two of these chips were used.¨ One counter counts the output from a 60 Hz timekeeper¨ circuit and produces a pulse each second. This signal is¨ routed to the RST7.5 interrupt, where it initiates the main¨ computation cycle performed by the controller. The output of the one-second timer drives the counter in¨ the second 8155. I can't remember what I intended to use¨ that counter for. In my original schematic, it is shown¨ connected to the RST6.5 interrupt, but there is no code for¨ that interrupt (and presumably the line is not connected). Only a few of the parallel port lines are used, and one¨ 8155 chip would have been enough. The second one was¨ included mainly for the additional RAM. The principal use of¨ the parallel port lines is to control the relay drivers. As¨ discussed last time, this requires six lines. One other line¨ seems to have been used as a direct inhibit (blanking) on¨ the display (I don't remember why). In a way I am amazed that I thought that a mere 512 bytes¨ of RAM would be enough for the entire controller (and, just¨ think, today they say that 4,000,000 bytes will barely get¨ you by under Windows!). Later I decided that I really¨ wanted more RAM so that the controller could log¨ environmental data (it was that data that revealed to me how¨ incredibly accurately the controller was following the¨ programmed temperature profiles -- much better than my¨ theory had predicted). I added four 8185 1 kB static RAM chips. These chips were¨ developed as part of the 8085 family and included the bus¨ interface. When I first built the controller they cost¨ something like $50 each, and that was more than I was¨ willing to pay. Had I included even one of them from the¨ beginning, I would have used only a single 8155. In the early 1980s, EPROMs were still very expensive. The¨ 8755, an EPROM dual to the 8155 RAM, was unthinkably¨ expensive at the time. Even the state-of-the-art 2716 2k­ by-8 EPROMs cost more than $50 (today they are, I believe,¨ well under $5), so I selected the smaller 2758. These were,¨ it was said, 2716s in which one of the two 1k banks was¨ defective, leaving a 1k-by-8 memory. Ironically, as IC¨ production technology improved, the yield on 2716s became so¨ high that there were few defective chips from which to make¨ 2758s, and the latter actually became more expensive than¨ full 2716s! Just in case my program code eventually grew to¨ more then 1 kB, I included a second ROM socket. Today the¨ controller has both sockets filled with 2732 4k-by-8 EPROMS!¨ The general rule seems to be that one NEVER has enough¨ memory. Keyboard and Display Designing the logic to handle the hex keypad and LED¨ display would have been a considerable task were it not for¨ the Intel 8279 keyboard/display controller chip. This chip¨ had everything I needed. The keypad presented no challenge to the 8279, which was¨ designed to scan a full alphanumeric keyboard. Three output¨ scan lines (decoded to eight) and eight input return lines¨ allow the chip to handle an 8-by-8 matrix of keys. The hex¨ keypad was only 4-by-4. The 8279 also has inputs for shift¨ and control keys. My pushbutton 'function' key was wired to¨ the shift input. When the 8279 detects and verifies a¨ pressed key, it asserts an interrupt signal, which I wired¨ to RST5.5 input on the 8085. There were actually two other input keys that I have not¨ mentioned before. A GE low-voltage switch is mounted by each¨ of the two main entrance doors of our house. One position on¨ the switch is marked 'home', the other, 'away'. The¨ controller is capable of modifying its schedule based on¨ whether we are at home or away, and these two switches are¨ used to convey that information to the controller. They¨ drive optical isolators, whose outputs are read by two¨ additional return lines on the 8279. The LED display is handled with equal facility. While¨ only three scan lines are used for the keyboard, a fourth is¨ present for use with the display. When these lines are¨ decoded, 16 digits can be addressed, a perfect match to the¨ display I chose. Eight driver lines control the seven¨ segments of the digit display plus the decimal point. Analog-to-Digital Conversion The last major functional block of the controller is the¨ analog signal processing unit. For the A/D converter, I¨ again opted for a sophisticated IC that would handle as much¨ of the work as possible. The National Semiconductor ADC0816¨ was the state-of-the-art chip at the time. It supports 16¨ analog channels and performs successive-approximation¨ ratiometric conversions in 100 microseconds. ('Ratiometric'¨ means that values are scaled to a reference signal, for¨ which I used the power supply that biases the temperature­ sensing thermistors. This makes the results independent of¨ that supply voltage.) The ADC0816 also includes a full microprocessor¨ interface, so that it could be accessed essentially like a¨ RAM chip. By writing to the chip, the channel could be¨ selected and a conversion initiated. The result is obtained¨ by reading from the chip. When a conversion is complete, the¨ ADC0816 asserts a signal on a control line. This could be¨ used to initiate an interrupt, but, since the controller had¨ nothing else to do in the meantime, it was easier to execute¨ a software delay loop after starting a conversion. The Real-Time Clock The above discussion covers all of the circuitry on the¨ main boards in the control panel. I would now like to¨ describe two of the additional circuits mounted remotely:¨ the real-time clock and the uninterruptible power supply. As I mentioned earlier, the time is derived by applying a¨ 60 Hz signal to the counter in one of the 8155 ICs. This 60¨ Hz signal can come from one of two sources. The main source is the 60 Hz line. The electric company¨ controls this frequency very carefully. It appears, in¨ fact, that when the frequency is low for some period of¨ time, it is later raised slighter until to total number of¨ cycles is correct. This is why electric clocks keep such¨ accurate time, unless there is a power failure. I took the AC from the secondary of a bell transformer¨ and applied it to the input of an optical isolator. The LED¨ in the isolator serves as a rectifier, so that the output on¨ the other side of the isolator is a 60 Hz pulse train. Two¨ steps are then taken to make sure that this signal is clean¨ (does not contain many spikes at the transition threshold).¨ First, the signal is passed through a Schmitt trigger, and¨ then it drives a nonretriggerable monostable set to produce¨ a 5 ms pulse. This signal serves as one input to a two-input¨ multiplexer. The other clock signal, which is applied to the other¨ input of the mux, comes from a crystal-stabilized clock¨ chip. Using a crystal at the color subcarrier frequency of a¨ television signal, this chip produces a 60 Hz pulse train.¨ This signal, however, is far less accurate than the one¨ derived from the AC line. How do we determine which signal to use? Well, the signal¨ derived from the AC line also goes to a retriggerable¨ monostable which is adjusted to a 20 to 25 ms pulse. So long¨ as the AC power is present, pulses come at intervals of 16.7¨ ms, and this monostable is constantly triggered. As soon as¨ a single cycle of the 60 Hz AC line is missed, however, this¨ output drops. This does two things. First, it causes the¨ multiplexer to send the crystal timebase signal to the 8155¨ counter. It also serves as a power-fail signal and is¨ connected to the TRAP interrupt. When we discuss the¨ controller's software next time, we will describe how the¨ controller uses the knowledge that the power has failed. The UPS I don't think I really have to say that maintaining power¨ to the controller is of the utmost necessity. Thus, an¨ uninterruptible power supply was essential. Basically, the controller runs off a 5 amp-hour,¨ nominally 8 V Gates sealed lead-acid battery. This uses¨ similar technology to that in a car battery, but the¨ dangerous gases are not allowed to escape from the cell. The¨ second computer board contains a regulator IC that drops the¨ voltage to an accurate 5 V. The battery was designed to keep¨ the controller running for at least 8 hours. Meanwhile, so long as the AC power is available, the¨ battery is charged by a power supply. A small transformer, a¨ bridge rectifier chip, and an adjustable voltage regulator¨ IC generate a roughly 10.2 V signal. This signal passes¨ through a diode on its way to the battery so that there is¨ no chance that the battery could discharge through the power¨ supply during a power failure. The variable regulator is¨ adjusted to produce a voltage of 9.2 V on the battery side¨ of the diode, the level that Gates recommends for continuous¨ charging. That covers what I intend to say about the controller¨ circuitry and hardware. Next time we will take a look at the¨ software. ------------------------------------------------------------ CPU ....EPROM.... ..RAM-I/O... ADD'L RAM 8085 27xxA 27xxB 8155A 8155B 4 x 8185 | | | | | | | | | +--------+---+---+-------+------+----+---+---+---+---+ | | 8279 ADC0816 KEYBOARD/DISPLAY 16-CHANNEL A/D CONTROLLER CONVERTER Figure 2. Schematic of the main bus of the controller. ------------------------------------------------------------