Sample Project 3

Small PBX

The Problem:

The client had spent a year with another consultant to develop
a small telephone system. This system was intended to be controlled
by a PC and provide 8 local phone lines with 3 outgoing lines.
A breadboard was already built using a Motorola MC68HC705 MPU.

The client originally wanted me to finish the design and get
the prototype working. I found that the board was miswired, missing
parts, was documented wrong and the software had numerous bugs.

The solution:

At first I tried to fix the original design. The source I was
provided did not match the board. I reverse-engineered the board
software and updated the source to match. Numerous bugs were found.
The board was inoperable due to poor design.

The client wanted me to get it working as a "proof of
concept." He also wanted to get some more prototypes built
so his software developers could develop software.

I resisted the idea of making more wire-wrap boards. This in
not my development process. I design straight to a PCB. The client
was very leery about going straight to PCB. He wanted to make
sure it would work first. I told him that if I designed it, it
would work. I explained that my design process is to thoroughly
design the product on paper. I do not slap something together
then fiddle with it until it works. This is what the previous
designer had done. The client finally agreed to go straight to
a PCB.

The client also had changes to the design that he wanted. I
noted that the existing design was a mess and a total redesign
would actually be faster than fixing the current design.

The Design:

Above is shown the FIRST PCB. This board contains over 350
parts. I ended up doing all the work including PCB layout and
building the prototype. I normally use subcontractors to do this,
but they happened to be too busy at the time.

The board consisted of a Motorola MC68HC11 processor with Mitel
telephone interfaces. The board also included ring generators,
call progress tone generators (busy dial-tone etc), Caller-ID,
DTMF decoders, and linear and switching power supplies. The entire
board worked off of a small wall transformer.

The above board is the first cut. There are a few jumpers on
the board to fix errors generated by the CAD software. As far
as design changes, a few resistor values were changed and there
were some minor changes to the switching power supply to improve
efficiency.

The board has no ROM software. On power-up it waits for software
to be downloaded from the PC. This prevented the need to burn
ROMs or field upgrade of software.

I developed the on-board software using the GNU 'C' compiler.
Using 'C' instead of fhe assembly language of the first design
made the software much more manageable. Some low-level routines
were written in assembly for speed.

To test the board I wrote three applications using Visual C++.
The first is a small serial server:

This application interfaced with the board via a serial interface.
It downloaded code to the board then acts as a server for applications
via anonymous pipes.

The main test application operated the board as it would normally
be used:

This application shows the status of the 8 local lines and
shows events. It routes incoming and outgoing calls to the appropriate
ports. It also displayed the Caller-ID of any incoming calls.

The third application was an online debugger. The board software
was difficult to develop without a debugger so this was developed
first:

This debugger operates separately from the application. It
will display the registers and source disassembly. It allows displaying
memory, watching variables, single-stepping, stop/run, and setting
breakpoints.

Development Time:

Total development time was about 5 months. Most of this time
was taken waiting for PCB boards to be fabricated and waiting
for parts. My total time was about 200 hours.

Although the board worked properly and the software worked.
I can't consider this a total success. The client continuously
wanted to change things and did not actually know what he wanted.
Ten boards were delivered with the software in about the time
of the estimate. The client never finished the project, he still
cant decide what he actually wants.

The above scenario is typical for failed projects. It is not
design problems, but the client not knowing what they want up
front. In my experience, the development is totally dependant
on developing specific requirements and specifications up front.
Once that is done, design is straightforward and can easily be
estimated. See the "Design Process" section for more
information.