nerd1951.com

It’s been a busy week around here in nerd1951 land. I’m moving which just makes it all so much more exciting but on to the techie stuff:

I’m going out to Silicon Valley for some advanced FPGA training next week. Actually it’s about using a particular FPGA core that’s advanced. My Verilog skills are still pretty rudimentary. I actually downloaded a design to a real FPGA for the first time today. That was fun, made some LEDs blink. The way I figure it, if I want to stay in the computer networking world then I need to become a logic designer at least part time. I want to become as fluent in Verilog as I am in Java (note I didn’t say C because I’ve been using C for almost three decades). I use to do logic design back in the days when a soldering iron was the only logic programming tool. Then I learned Able which is a lot like learning assembly compared with Verilog.

We’ve started a little embedded Linux informal study group at work. We all want to learn more of the nitty-gritty details of how to bring up Linux on our own devices. It’s becoming obvious to me that in-depth knowledge of building custom Linux kernels is becoming a requirement for embedded systems programming. We choose the Linksys WRT-54G as our first target. You can’t buy any kind of processor eval board for what the Linksys router costs. So this week, I set up a Linux build machine at work with the OpenWrt build environment and kernel. I built the Kernel. It’s not that complicated. Just typing something like make <target>. Then I downloaded it to my WRT-54GL. It was a thrill to Telnet into my router and see Linux come up. I think the next step will be to build some kind of Kernel module or change a driver and dig into the boot code.

On my real job, I’m using ucLinux with an Analog Devices Blackfin processor. Again the tools and kernel distribution on the Web were first rate. I was able to download the sources, build the toolchain and the kernel and boot Linux on an eval board in just a couple of days of work. I’ll have to write some drivers as well as the applications code for this project.

Another part of the same project is a sharable library that runs on an X86 Linux host. The library provides an API for communicating with the embedded device that we are building. In the past I’ve always written API documents using Word, then written the C or C++ header files, cutting text from the Word document and pasting the text into comments in the header files. I decided that this was stupid since I know that Doxygen will create documentation from a well documented header file. So I forced myself to learn Doxygen which wasn’t too hard since it can work just like JavaDoc which I’ve used in the past. There’s a real productivity gain from only writing things once. It reduces errors and makes it easier to keep the documentation in sync with the code. But I think the biggest advantage is the discipline that this process imposes. It forces a consistent style for data and function headers. Since you know other people will actually see your comments in a document, it makes you do a better job at writing useful comments and quality code.

I usually keep notes in a notebook when ever I tackle something new in case I have to do it again. That way I don’t have to figure out all of the details again the next time I do it. Recently, I’ve taken to writing myself “how-to” pages if I do something more than once. I’ll be doing this a lot over the next few months as I set up cross development environments for various processors and vrsions of embedded Linux.

I’ve decided to post my “how-to” pages here so I know where to find them and in case someone else might find them useful. If you do find something useful, please send me any questions that may come up or let me know if I should add anything to make the pages more useful.

Here is the first “how-to” that I have posted: Ubunto VLAN How-to.

In embedded systems programming we control things that the rest of the world depends on. Everything from cell phones to ABS brakes systems to fly-by-wire aircraft controls on modern passenger jets. Sometimes it’s easy to lose track of this when we are bogged down in hundreds of lines of code looking for a bug. Sometimes you want to let something slip by that doesn’t seem too serious. That’s when the real world can turn around and kick you in the face.

Bugs in embedded systems software can cause repercussions that range from inconvenience and monetary loss to injury and death. If a bug in a consumer device bricks it you can wind up with a lot of unhappy customers, a bad reputation and even sink a company. A bug in a medical device can kill, and has.

I’ve been lucky. My worst bug corrupted the configuration data in a networking device. After a software upgrade the configuration data was lost. Even after I released a patch that fixed the problem, the device had to be set up from scratch. I have done things like cut off a few dozen phone calls or cause telecom equipment to do unnecessary redundancy switchovers - inconvenience and monetary loss – unless one of those calls was a 911 call.

When I’m working on a system, I try to think about what it’s being used for – emergency services communications, steel mills, toxic gas detection, or even just consumer electronics. I think about 911 calls when I design, code and test software. Whose life may be on the line or whose livelihood may be on the line.

Embedded systems software is out there in the real world, not part of cyberspace. I think this puts an ethical responsibility on us to develop the safest, most reliable software that we are able. People who never even know we exist are out there depending on us every day.