Tweet Follow @jack_ganssle

Volume 3, Number 11 Copyright 1998 TGG July 6, 1998


You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com.

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- Embedded Seminar in Chicago
- Hardware Helpers
- Thought for the Week
- About The Embedded Muse


Embedded Seminar in Chicago


I'm conducting a full-day embedded seminar in Chicago, near O’Hare airport, on September 16. It's called "The Best Ideas for Developing Better Firmware Faster", and is for the developer who is honestly looking for new ideas, but who wants to cut through the academic fluff of formal methodologies and immediately find better ways to work.

The focus is uniquely on embedded systems. I'll talk about ways to link the hardware and software, to identify and stamp out bugs, to manage risk, and to meet impossible deadlines.

For more information check out http://www.ganssle.com or email info@ganssle.com.

Hardware Helpers


In the last few issues of the Muse readers have been sharing ideas of how we can improve system debuggability when designing the hardware. A number of folks sent more thoughts along, which are listed here.

Thanks for all of your feedback, and please do keep those ideas and comments coming!

From: Tom Evans
It is fairly cheap to add a four-input comparator (LM139) that monitors the on-board supplies, including any Maxim-generated RS232 voltages. Rig it up to drive a bi-colour LED green when everything is OK (the power-on indicator) and red when there's a fault. It can also be an input into the power-on-reset logic, or can be monitored via an I/O pin (if the CPU can run with some voltages bad).

I've always used a "CPU LED", which is turned on when the OS (or scheduler or event-loop or polling-loop or whatever) finds something to do and is turned off when there's nothing to do. In one project where a lot of work has to be done in a few interrupt service routines, they also turn the LED on. I also arrange to briefly flash the same LED at about a 2Hz rate from the real-time interrupt. It is amazing the programming bugs this simple addition shows up. Simply measuring the average voltage across this LED gives a good indication of CPU utilisation. If it is a bi-colour LED it can indicate error conditions or different processes (say interrupt or mainline) so you can see where it was just before the watchdog bites.

If the power supply is on the same board as the logic, run the 5V rail from the supply through a short, heavy link that is soldered in after the supply has been tested. This also provides a place for installing a "calibrated 0.1 ohm resistor" (a length of wire-wrap wire) for when you need to measure the current.


From: Alan Walker
When designing a PCB, make sure to leave enough clearance around any components that you may eventually want to socket. This is especially important on boards with processors in PLCC packages where you may need to use an emulator.

At assembly time, make sure all components which are attached to the PCB via screws or through panels, are secured prior to soldering. Soldering before tightening everything down is an easy way to break a trace.

Bring out the reset line to small switch or jumper that can be installed on your development boards. This makes is easier to issue a hardware reset.

Some of the better schematics I have seen show the pinout for SOT-23s, transformers, and other non-standard parts on the page where the part is used. For some of the larger packages you may want to add pin numbers to the silkscreen.


From: Pascal Dornier
To add off-page references to OrCAD schematics, use OrTie (shareware, http://www.pcengines.com/orcad.htm).

To analyze ISA and PCI buses, test adapters are available at low cost, e.g. through Halted Specialties or Emulation Solutions.

To minimize the number of samples on PCI bus analysis, add a D-FF that delays FRAME# by one clock -> FRAME2#. Program the logic analyzer to capture those samples where either FRAME# low, FRAME2# high, or TRDY# and IRDY# low.

If your embedded PC does not have a full bus available, at least provide a subset of the 8 bit ISA bus so you can hook up a monochrome video card, a keyboard, a hard disk and a POST code display.

The same "escape hatch" can also be used for in-circuit programming of soldered-in flash EPROMs. A control line from the off-board flash can disable the on-board flash, and execute an alternate BIOS running on a separate (socketed DIP) flash EPROM.


From: Keith Hutchin
When using multiple bench supplies to power a system, be very careful to check the connections before switching them on.... at one company I used to work for, the Technical Director was showing a client around and decided to demonstrate the new system we were designing. The system was designed around Eurocards in a 6 foot tall 19" Rack cabinet. He connected up the two bench supplies (incidentally, both manufactured by his other personally owned company) and powered them both up. One was 24v @ 24A, the other 5V @ 24A. Guess what happened when the logic supply was fed with 24v with 24A behind it .... yes, LOTS of smoke ! He destroyed 6 months work in about 10 seconds flat. The client thought it was highly amusing, but did not place any orders with us. I wonder why !

When using a CAD system to design a PCB, be wary when copying blocks of circuitry if they have already been assigned signal names - you could end up with a lot of circuitry all 'bussed' together instead of being discreet circuits. I know of at least one instance of this.

Be careful when specifying magnification factors on PCB artwork, I have seen an expensive urgent PCB arrive from the manufactures, only to find that it was double the expected size as the wrong magnification factor was written on the film.


From: Carl Farrington
Some of the engineers I work with have started adding tick-marks on the silk screen for every fifth pin on large parts. It makes it SO much easier to find pin 143...


Thought for the Week


Two Digits for a Date, By Steve Wheeler
(to the tune of "Gilligan's Island," more or less)

Just sit right back and you'll hear a tale
Of the doom that is our fate.
That started when programmers used
Two digits for a date.
Two digits for a date.

Main memory was smaller then;
Hard disks were smaller, too.
"Four digits are extravagant,
So let's get by with two.
So let's get by with two."

"This works through 1999,"
The programmers did say.
"Unless we rewrite by then
It all will go away.
It all will go away."

But Management had not a clue:
"It works fine now, you bet!
A rewrite is a straight expense;
We won't do it just yet.
We won't do it just yet."

Now when 2000 rolls around
It all goes straight to hell,
For zero's less than ninety-nine,
As anyone can tell.
As anyone can tell.

The mail won't bring your pension check
It won't be sent to you
When you're no longer sixty-eight,
But minus thirty-two.
But minus thirty-two.

The problems we're about to face
Are frightening, for sure.
And reading every line of code's
The only certain cure.
The only certain cure.

[key change, big finish]
There's not much time,
There's too much code.
(And Cobol-coders, few)
When the century is finished with,
We may be finished, too.
We may be finished, too.

Eight thousand years from now I hope
That things weren't left too late,
And people aren't then lamenting
Four digits for a date.
Four digits for a date.