Interview with Jack Ganssle

Featured Engineer

Jack Ganssle

Jack Ganssle - Principal Consultant, The Ganssle Group

How did you get into electronics/ engineering and when did you start?

Oh, I was always the quintessential nerd. Probably around 8 or 9 years old I built my first crystal radio, and dove into the electronics pool and never surfaced. As a teenager I had a lab in the basement, which was filled with all sorts of electronic equipment. My dad worked at a startup, and we kids were (quite against our wills!) drafted as janitors at around age 13. But the deal was that we could keep what we found on the floor, and the engineers there were slobs. So I got all kinds of used components.

At 16 I managed to get a part-time job as an electronics technician. We were doing Apollo ground support gear (that was the year Apollo 11 landed on the moon). My boss didn’t know much about digital, so I wound up doing a lot of redesign of his gear. That morphed into a lot of travel, and balancing that with college was “interesting.” One time I got back from a month overseas, sat down in Calculus 3, and asked the guy next to me “when’s the next test?” Alas, his answer was “today!”

Then the microprocessor was invented. No one at the company knew how to write programs, so I was promoted to engineer and started coding and designing all sorts of embedded gear.

How has engineering been as a career?

After almost 40 years as an engineer the answer is simple: awesome. It has been one cool project after another, and there is truly never a dull moment. I remain completely puzzled about why so few kids today want to become engineers. The work is fascinating, and the pay is much better than average. In the USA the average family income is around $51k/yr, but a mature engineer alone makes twice that.

And I think engineering has a certain nobility about it. We don’t meaninglessly push paper around or manipulate financial markets. We build the world, we create products that make peoples’ lives better.

What is the favorite hardware tool that you use?

Hands down it’s the oscilloscope. I have a bunch of them, but my favorites are the mixed-signal scopes. Today there’s a lot of USB scopes, which are fine, but I prefer one with its own screen and a panel full of knobs. It’s so much easier to twist a knob than to click a mouse to change a setting.

What is the favorite software tool that you use?

This will sound odd, but it’s probably Microsoft Word. As a young engineer I hardly ever documented anything, but age brings wisdom. Get everything in writing, saved on disk. Never count on memory. Write clearly, concisely and with clarity. Engineers typically have an aversion to this, but we have a responsibility to document everything.

What is the hardest/trickiest bug you have ever fixed?

There have been so many! I’ll give you a class of bugs that have been tough. In the 80s and 90s I ran an in-circuit emulator company. Our tools plugged into the customers’ boards in place of their CPU. Supporting the customers was terribly difficult since every board was different. The customers would often call with very non-specific problems, like “my board doesn’t run with the ICE installed,” or “my board only works with the ICE connected.” Figuring out what the problems were, especially over the phone, was at times agonizing. Often the problems were subtle results of Maxwell’s Laws, due to reflections or ground bounce, but troubleshooting those made you old fast.

What is on your bookshelf?

Just about every book I can find on electronics, software engineering, and especially embedded systems! I count 13 books on those subjects that are currently in my “to-read” pile. Examples include “Design Patterns for Embedded Systems in C” by Bruce Douglass and “Mission-Critical and Safety-Critical Systems Handbook” by Kim Fowler. There are also 17 books in another “to-read” pile that have nothing to do with electronics. My surveys show the average firmware engineer reads just one tech book a year, which is a damn shame. There’s so many cool ideas going on in this business.

What has been your favorite project?

The first emulator I designed. That was when electronics still cost money, so minimizing parts count was critical. It had 17 ICs, and the CPU was shared between the emulator itself and the target board. The firmware in that thing was exquisitely-complex as the CPUs context had to be shared. So, for instance, when the emulator hit a breakpoint while running the user’s code the resulting stack pushes could be anywhere in memory, depending on what the user’s stack pointer was set to. So the emulator had to have hardware and software that could capture the pushes in its own, limited, RAM (because I had made the decision to use no target resources).

Do you have an experiential stories you would like to share?

Well, when I was in high school I built a lot of amplifiers and ham radios using vacuum tubes. Those needed high voltages, typically around 300V. My bench was three feet from a cinder block wall, but I had to move it, because every time I got I my head would bang against the wall. It was better to get thrown across the room, which absorbed the kinetic energy.

On another occasion a friend accidentally grabbed a selenium rectifier with 500V pumping through it. He was locked on, his muscles rigid, screaming. I stupidly pried him off, instead of killing the power.

Then there was the system that analyzed oil and protein in different substances. We used ether as a solvent. One day I dropped a gallon glass bottle of the stuff. We were all really stupid the rest of the day.

What are you currently working on?

I write extensively about this industry, and do a variety of projects to generate interesting topics. So, for instance, I’m working with some very high-speed logic to show how the Fourier coefficients mean that probing a circuit can cause the system to fail. I’m also working with the new version of Microchip’s MPLAB using PIC32 and PIC24 processors, and on another project with ST Microsystem’s Cortex-M4 part.

What challenges do you foresee in our industry?

The biggest one is the growth in size and complexity of firmware. I travel all over the world talking to embedded developers, and find that few use any sort of disciplined process. Mostly the industry relies on heroics, which works great on small projects, but it just does not scale. I think software today is an art, but it will have to become an engineering discipline.

How is the field changing?

The IEEE raises constant alarm about the declining number of EEs in this country. And a lot of work is being shipped overseas. I probably get more phone calls from India alone than the USA. Offshoring will only increase. I think the Western engineer of the future will need some different skills: writing, doing presentations, and the like.

The engineer of the future here in the West will be a nexus in the company: this will be the person who can talk ones and zeroes to the team here, and the team overseas. He/she will be able to talk features and benefits to customers, and profit and loss to the boss. Think about it: no MBA, no “communications major” will ever have the tech skills needed for this position. Only an engineer can do this. And the increasing scarcity of EEs, especially, will mean every-better salaries.

Name some engineering “fads.”

Symmetric multicore is one. It’s being sold as the answer to our performance needs. While it does offer some power management benefits, the shared caches and memory busses mean that it will never scale performance as advertised, except for certain naturally parallel problems. Heck, we’ve been working on the parallel programming problem for forty years and have made essentially no progress.

Asymmetric multicore, though, has been very successful and will continue to be so. In fact, I expect that we will eventually use CPUs like we use transistors today, thousands, even millions of them.

Android is another fad. It will succeed, but will fade from a religious issue to just another tool we routinely use. Linux followed the same progression: once it was an end in itself; today it is a resource we use as needed.

Previous Next

Previous Spotlights

Featured Products

PCB Tools

Passive Tools

RF Tools

Math

Extras