Issue 112 November 1999
Tuning into the HA Channel

---

If Only It Was That Easy

With all the BOB-II can do, it might seem like adding it to the HCS-II would be a snap. Well, not quite.

I wanted the HCS-II TV interface to understand the same commands used for LCDs connected to LCD-Links or Answer MAN Jrs. This arrangement would make it easy to convert over to a TV display. It also means that people familiar with the LCD commands could use the TV interface without learning different commands.

Besides the command set, the TV interface had to handle RS-485 packet checksums, the HCS-II network protocol, ANSI cursor control, responding to HCS-II queries, and so on. It soon became clear that I would have to use an embedded processor to interface the BOB-II with the HCS-II.

The code I wrote for the PIC-DIO already handled the HCS-II networking, so it made sense to build the BOB-II interface on this platform. I could even use the ’16C63A, which provides plenty of RAM for serial buffering, has a UART for serial interfacing, and enough ROM to handle the numerous commands I planned to recognize. The HCS-II TV interface was now the PIC-TV.

Figure 1 shows the PIC-TV circuit. Most of the work is done in software. All the PIC-TV needed was an RS-485 interface, the main PIC controller, and a way to set the network address.

(Click here to enlarge)

Figure 1—The PIC-TV hardware is fairly routine because most of the work is done in software. Note the lack of a voltage regulator—the BOB-II has one built-in

The network status LEDs do more than satisfy my love of blinky lights. You can tell instantly if you’re getting HCS-II network data when you install it. And if you have network problems, you’ll see network errors indicated by the flashing red LED.

Note that there is no voltage regulator in the circuit. The BOB-II uses a 78M05 regulator, which provides more than enough power for itself.

The BOB-II brings the +5-V supply out to a SIMM pin for use by external circuitry, which is ideal for the PIC-TV’s minimal power requirements.

The total current draw of the parts adds up to ~150 mA, but most of the devices aren’t on at the same time. Only one LED (15–20 mA) will ever be on at any given time.

The RS-485 chip draws ~40 mA during transmits, but that’s not a problem because the LEDs are off during transmissions. The beeper draws 30 mA, but it’s rarely on.

The 78M05 can supply up to 0.5 A, but the surface-mount device doesn’t dissipate heat well. So, the BOB-II specification states external current should be limited to 65 mA.

The PIC-TV exceeds this on a rare occasion, but in short bursts for LED blinks and packet transmits when the beeper is on. Testing revealed that the 78M05 gets warm at worst, so it allows me to drop voltage regulation from the circuit. Even in the case of an RS-485 network failure or a short on the +5-V supply, the 78M05 has an internal thermal shutdown.

One of the tricky parts of this interface is dealing with two asynchronous serial ports at the same time. The PIC-TV has to handle packets from the HCS-II whenever they’re sent, yet be able to send data to the BOB-II at the same time.

I was having nightmares of a multitasking OS to handle both asynchronous ports, but then I cheated. The ’16C63A has one hardware UART, which I planned to use for the HCS-II network. I really needed two so I can send characters to the UART buffer for the PIC-TV and let it worry about the timing and bit-banging while the receive buffer grabs HCS packets.

But since the HCS-II network is half-duplex, whenever the PIC-TV has to return data to the HCS-II, there’s no incoming data to worry about. The BOB-II doesn’t send any data we care about, so we can easily bit-bang the HCS responses without missing any incoming data or screwing up the bit timing with an interrupt. So, I split the UART in half.

The receive side receives HCS-II data and the transmit side sends data to the PIC-TV. This way, the PIC-TV can send data to the BOB-II without causing timing problems when it receives data from the HCS-II.

The HCS-II data is received via interrupt, while the PIC-TV sends data to the BOB-II in a loop. The ’16C63A UART has a small buffer, allowing three characters to be received before it overflows. So, the PIC-TV could even preempt the interrupt for a little while if it needed to.

Although the PIC-TV doesn’t return any usable data to the HCS-II, it appears to the HCS-II as an LCD-Link and must respond when queried to indicate that it’s online. The PIC-TV has no keypad, so it just returns 00 to let the HCS-II know that the module is online. This status is indicated by an asterisk on the HCS-II host screen.