We've all been there: the hardware for the system isn't done yet, and the software development is being held up for lack of a way to do incremental testing. Or, just as often we see the case where a single prototype hardware unit is built, but has to be shared between everyone who needs it, and the software team gets little access time. This is Not A Good Thing.
Enter the Software Development Unit. This
is a chassis with enough hardware to provide what the software team needs,
i.e. a running processor, clock generation, interrupt logic, scheduling
timer, memory space, and enough I/O to run whatever peripherals are going
to require low level drivers, such as the front panel.
Here is a typical problem case, a data acquisition unit.
There is a lot of software required to drive this little beauty, and the
schedule is really "success oriented." But you cannot have this prototype
because the hardware guys have it torn apart (again!) to fix some analog
problem. Now what?
Here is another example. The team is working 18
hour days getting it ready for the big demo, and the hardware is still
being assembled up to the last week before the customer is scheduled in.
What can you do?
Enter the Software Development Unit. On the front
of this example is the same set of pushbuttons and the same display as
the real system will have. It is self-contained, and is built specifically
to suit the needs of the software developer. The entire memory and
I/O maps are just like the real system. All that is missing is the
specialized I/O unique to the end item. That could be added, but
then the hardware guys would try to steal it... The object is to
make it complete enough to allow real testing, but inexpensive enough that
several can be built, and the whole software team can have access to them,
right there in their own offices. Yes!
Inside the Software Development Unit there is not a lot
of hardware. Note, though, that it has its own built in power supply
so the hardware guys (or the calibration lab!) won't steal it.
That makes it safer, too. That single printed wiring board in the
bottom of the chassis has the entire processor section on it.
This is the first of two example Software Development
Unit printed wiring board designs. This one was built to be cheap
to build, easy to duplicate, and general-purpose. It has enough excess
I/O control that it has been used as the controller in a two-board system
where the other board has the specialized hardware devices. The software
team needed a scheduler interrupt, LCD display driver, front panel switch
input, two serial ports, a real-time-clock, watchdog timer, and not much
else. Mission accomplished.
The second example is obviously related to the first,
but has been changed to allow the testing of a specialty interface.
In this case, the space taken by one of the serial ports was recycled to
allow the addition of a National Instruments IEEE-488 interface chip, and
an alternate processor type in a smaller package. The key idea is
this: the Software Development Unit can be customized to do whatever
is needed.
It is time to give credit where credit is due. I
once worked with a great software guru, Dave
Hoag, who asked that this set of features to be built into a
box, using one of the 68xxx family of processors. I designed and
built the box, and we added features as they seemed appropriate.
Some ideas are worth repeating, and so I did, this time with the 80C186EB.
Thanks Dave!