原创 Embedded development, then and now (Part 4)

[Continued from Embedded development, then and now (Part 3)]

The 80486 project

After being spoiled by the facilities of the 68332 project, the next one was somewhat of a letdown. This time, we were back, at least initially, to the hardware guy/software guy sort of mentality. It was a pretty big project, and I was building only two or three "apps" in the system. By the time I arrived on the scene, lots of decisions had already been made. These included the choice of the processor, the I/O devices, the C language, the development tools, and the RTOS. So, for that matter, was the program architecture. There were a lot of I/O signals, mostly analog, so the architecture was designed around a input buffer array that cycled through the A-to-D channels in a specific order. The job of our apps was to read the data at the proper time, process it, and send the results out again. Some of the data went back out to devices again, but most just went to graphic and numeric displays.

Originally, we had planned to use an industrial-quality C compiler designed for real-time, embedded applications. But for preliminary development, we agreed to use the Microsoft C compiler. In time, however, the "preliminary" part morphed into "forever."

This decision was to lead to some consternation, because we knew that the floating-point routines in Microsoft's math library weren't reentrant. To use their compiler in production, we all had to agree not to use floating point. This decision made the problem much harder.

Later, we realized that the problem was not a problem, as long as one task using the floating point processor didn't get interrupted by another, also using it. Getting around this limitation was as easy as splitting the f.p. computations up into small sets, and disabling interrupts while processing each set. Or, even easier, simply agree that only one app got to use floating point.

Although the development system for this job was capable enough, it was definitely a step down from the 68332 project. There was not even the pretense of the features of an IDE—we used separate Windows and MSDOS apps for code development, testing, downloading, and testing. We had no ICE, relying instead on remote hex debugging.

Despite the step down in our development system's capabilities, this was one of the most fun projects of my young life. That's because I got to—perhaps "was forced to" would be more accurate—use my skills from so many different technical disciplines.

My boss was a big believer in the generalist, as opposed to spe******t, philosophy. He was adament that we not be divided into "hardware guys" and "software guys," but rather know and understand all aspects of the system. Whenever I asked a question about how some gadget in the hardware worked, he'd bark "Get out the schematic and see for yourself!"

At one point, he had me checking a new circuit board to make sure it matched the schematic. There I sat, a Ph.D. physicist "software guy" and an expert on embedded software development, using a multimeter to buzz out the copper traces on a PC board.

I grumbled, "Dammit, Jim, I'm a software engineer, not a lab tech." To myself, I thought, "Man, at the salary this guy's paying me, this has got to be the most expensive circuit board validation in history."

In the end, though, I learned that the boss was absolutely right. The system was entirely too embedded, too tightly married to the hardware, to divide it into software, hardware, and systems pieces. Or control pieces or algorithmic pieces. It all had to play nicely together, and that took someone who understood the funcionality of all the pieces.

Now, I love electronics; it was key in my Master's thesis. I also love microprocessors, having been in on the ground floor. And I love digital logic. And math algorithms. And physics. And software engineering. It's not often I get to use skills in all these disciplines on any one job. But to make this job work, I had to dredge up everything I'd learned in all these disciplines, plus quite a few more.

Once I got over the shock of being yanked out of my comfort zone, I didn't just accept the boss's notion of doing it all; I jumped in with both feet.

Like any high-tech company, ours had an electronics lab, and a "chief hardway guy" working in it. But he was always in the greatest of demand, and I didn't want to wait for him to have time to talk to me. Anyhow, I got tired of going into the lab to ask, "Where did the Phillips go?" or "May I borrow the multimeter?"

So I went to Radio Shack and bought myself a CARE package: A set of hand tools, a soldering station and soldering aids, a multimeter, a logic probe, and various electronic components. My desk drawer began to look more and more like my partner's briefcase.

In the end, I found myself not just involved in all aspects of the program. I was, quite literally, embedded in them. At one end of my desk was the software development system and the UUT. At the other end was an oscilloscope, multimeter, signal generator, and logic probe. Later, it included precision thermometers, air and vacuum pumps, and more. In my desk drawer were the circuit components and tools. Below that were a few custom test gadgets I'd built myself. Not far away was a PROM burner, FPGA burner, logic design software, and support software. Standing in the corner were a couple of tanks of nitrous oxide.

In the last system I built for that company, I got to exercise all my skills and then some. I had a lot of help designing the more complex parts of the circuitry, but I was involved in every other aspect. When the prototype circuit board proved to be too noisy, I found myself sitting next to the PC layout guy, showing him how best to route the power, ground, and signal lines, and where to put the isolation caps. When our first board got populated, I was the one who did it. One step at a time, testing all the way (unit testing, remember?).

When one of our fabricators got chips upside down, I was the one that found them. When a part failed, I found that too. When the pressure control system proved to be unstable, I found that too, and redesigned it. And when we learned that the sensing device required a lot of digital logic, I worked with the sensor's vendor to work out a fix. I picked the serial PROM that solved the problem. Then I designed the logic and burned the FPGA.

And I loved every minute of it.

Today's development systems

Until a few years ago, I used to attend the Embedded Systems Conference every year. I watched with interest as the capabilities of chips and systems improved, and the development systems and software got so very much better.

No more SneakerNet for these systems. No more hex debuggers either. It seemed that almost any device that involved digital logic, also had a C compiler and a symbolic debugger. Often the toolsets was the GNU toolset. Not my first choice, because I'm a GUI/IDE sort of person. but still very capable, and familiar to virtually everyone.

Today, there's been yet another dramatic shift in development environments. Today, emphasis has shifted from the GNU toolset to custom toolsets based on Visual Studio. Some vendors actually use Visual Studio, some use its look & feel. But all are tightly integrated into proper IDEs, with excellent support for cross-compiling for an embedded system. Far from SneakerNet, modern systems talk to the IDE through high-speed connections.

As I sit here typing this, there a tiny PC board, about 2 x 3", plugged into my USB port. This is not just the core processor, mind you. It's the core processor plus its evaluation board, with a fast CPU and more memory than I used to have in my hard drive. It came with a very complete Visual Studio IDE, and a built-in RTOSes. I can choose from a bewindering array of pre-built software modules.

There's a second board plugged into my Ethernet port. Running their IDEs is as simple as clicking on an icon in Windows, and if their user interfaces aren't Visual Studio, they're close enough for me.

With systems like this, I'm back down to creating a new build in seconds. Awesome.

I chose three of these systems for nostalgia's sake. One has my favorite 68332 chip; two more have Z80-like processors. I can get away with choosing them this because, now that I'm retired, I don't have to explain to my motives to anyone.

A whole set of gadgets is based on Parallax's wierd and wonderful Propeller chip.

I have one more system to buy. That will be my only concession to leading-edge technology: A high-end ARM system.

Let me see, now. Where did I put that logic probe?