The core of this project's software is a kernel of my own design comprising a co-operative multitasking scheduler with semaphores for task synchronization, a single timer and message box for each task, shared memory for additional communication and a single level of interrupts. Tasks are dynamically created by the applications rather than fixed at compile time. Also, Motorola's BUFFALO monitor is present for experimenting with the hardware and debugging.
The software development system I used is a free 68HC11 C compiler and assembler, available from the Internet, running on my 50 MHz 68060 powered Amiga. The package as it exists currently there is quite useless and the author has long since stopped supporting it. But he sent me the source code for the 68HC11 libraries. I repaired some bugs: one in the C initialization of memory was using the branch on carry instructions after increment or decrement instructions. Clearly, a target system had never been developed with it. I wrote a lot of missing functions bringing the cross compiler to a very useful condition.
In the first image following, the unit is running its sidereal clock
application. The bottom line of the display is the time given in UTC and
the top line is the local sidereal time. The applications are selected
from a menu. The up and down buttons on the right hand side of the watch
scroll through menu items, the large dark button runs whichever is displayed
on the top line and the red button has two functions: from an application,
it exits back to the main menu, and from the main menu it switches the
unit off. Currently, it is switched on using a magnet to activate a reed
switch connected to XIRQ enabling recovery from the "stop" mode. I plan
to remove this though and replace it with a mercury tilt switch, one requiring
a large angular tilt so that it's not activated by vibrations in transit.
This will obviate the need to carry a magnet around.
This is, to me, a triumph of hardware, software and mechanical engineering. I wanted to make a small battery powered unit so I began by choosing a case. I decided to use an infra red controller as the interface because I couldn't incorporate a decent keypad in so small a space. I had an infra red receiver which I removed from a broken television set. But I didn't know anything about infra red protocols and I didn't have a data sheet for the receiver. Nevertheless, I built it into the project with the purpose of experimenting.
The micro controller I used is an MC68HC11F1. This is a processor with no programme ROM so it mainly runs in expanded mode. There is a special bootstrap mode which allows loading its internal RAM with a programme via the serial interface but I decided to put a 32k EPROM on board along with 128k of RAM mapped into four 32k banks. The MC68HC11F1 does not multiplex its address and data busses. This is valuable in a project with limited board space because a latch is not required between the processor and the external memory. I decided that the features should include a 16 x 2 line LCD display, a real time clock, midi input, output and through sockets and it should have a powered down state keeping the 128k RAM battery backed for at least six months.
Implementing the battery backed requirement taught me a lot about power saving techniques as a result of finding current leaks. I put a ten ohm resistor in series with the power source and noted the millivolts across it as I tried to minimize the current. The first lesson was to believe what I'd read that unused inputs had to be tied up or down and not left floating. Then I discovered that the real time clock and LCD display had opposite tying requirements, the display low and the RTC high, and both being controlled by port G, there was a conflict. I routed the display lines through 4066 analogue switches isolating the RTC from the LCD. The "stop" current went from an unacceptable 600 microamps originally to a respectful 20 microamps. Then I tackled the running current drain. The port G chip select feature was one culprit I discoved with a logic probe: the default condition is chip selects enabled. The constant switching while connected to one of the the display data lines used significant current. Thereafter the system was running at 24 milliamps which seemed good enough. But some months later, staring at the RAM protection logic, I realized that by controlling the chip select rather than R/W, the RAM would not be switched on every half cycle. This reduced the current drain to 15 mA.
Investigating the infra red protocol of the ITT television, I connected the infra red receiver output to two input capture pins, one set for rising and the other falling edges. They generated interrupts and the times of the edges were recorded. Since I did not have an oscilloscope at the time, I transferred the capture times to the Amiga on which I had written a programme to plot the wave form to a printer. With this visual representation, it was easy to see a pattern. It turned out that a message comprised a fixed number of pulses over about 8 milliseconds with the message repeating every 288 mS when a key was held down. Binary 0 and 1 were represented by short and long intervals between pulses and only edges in one direction needed to be captured. The television remote control was not a convenient size to carry around so I bought a Casio watch which has an infra red transmitter and many manufacturer's protocols. Outputting the input capture events to an LED on an output pin, I discovered that the Telefunken protocol is similarly simple. So now the controller is very convenient to carry and gives the equipment a 'Dick Tracy' feel.