|
SHDesigns: Embedded Systems Design, Consulting and Developer Resources | Page hits: |
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.
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.
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.
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.
Return
to main pageBack to Project list
Project 4