nerd1951.com

Activity on nerd1951.com has been little to none for the last several months (I have a talent for stating the obvious).  But his is about to change.  nerd1951.com will be getting a complete make-over soon.

My interests have moved on from computer networking in embedded system to multi-media and embedded systems.  It seems that a lot of the current interesting work in embedded systems includes multi-media.  The applications range from portable entertainment gadgets to robotics.  Tele-presence and remote sensing are important multi-media embedded systems applications.

The blog portion of nerd1951.com will be moved to its own page and I’ll continue to use Wordpress for that but I’ll probably delete most of the old content.  The main page will be dedicated to projects and news from other sources and will include some multi-media content.  I’m looking at using joomla for that.

I’m also working on a fun digital speech processing application that I will share here after the website make-ver is complete.

I’ve been doing a bit of work lately on a project that uses the Analog Devices Blackfin processor. The application is very ‘net-centric so we decided to use Linux, specifically uCLinux for the operating system. Of course this means that our development tools are the GNU compiler collection and all of its related applications.

Often, one of the hardest parts of a project like this is getting Linux up and running on your target hardware. The Blackfin uCLinux web page is very well organized and has a lot of good information. I downloaded the tools and the Linux distribution from their site and had Linux up and running on a development board in a matter of hours.

One thing that is an absolute necessity is to have a JTAG interface for programming FLASH through the processor. Once you have the boot program running you can program the FLASH using commands that the bootstrap provides but you need to get the bootstrap in FLASH first. An Austrian company, Blue Technix sells a USB JTAG ICE for the Blackfin called the Ice bear. It’s about $320 (US) and since they are in Austria, it could take a couple of weeks to get one so you need to plan ahead. The ICE worked just as advertised and was critical to the success of my project. Blue Technix also has some low cost eval boards too but given the Euro/Dollar exchange rate you might do better getting something from Analog Devices or one of their distributors.

As I was saying, the hard part is often getting Linux up on your own hardware. My target had some fundamental differences from the Eval board that I started working with. Like most micro controllers, the Blackfin has a bunch of multi-function pins. It also has two UARTS. Well our design used UART0’s data out pin as a software controlled hard reset. The other fundamental difference was that we were using SPI serial FLASH instead of the parallel NAND FLASH used on the eval board.

Porting the bootstrap went pretty smoothly. After about a days work, I had the bootstrap working. But it was different with the Linux kernel. I disabled UART0 and enabled UART1 using make menuconfig. But every time the board started to boot – bam! It reset almost immediately. I knew that somewhere the function for that pin was being set up to be UART0’s output. It took about three days of searching the code but I finally found it. The I/O pin setup for both UART0 and UART1 was hard coded deep in the init code. After I fixed that, I could boot Linux using TFTP.

The next step was getting Linux to work out of the SPI FLASH. There are two approaches to this. You can create a complete compressed file system image for a RAM disk system. Then you have the boot program copy the image from FLASH to RAM, decompress it and go. This approach is very simple to configure because it’s the stock build that comes with the distribution. The downside is that you don’t have any non-volatile storage without jumping through hoops.

The second approach took me a couple of more days to get running. You build a file system for FLASH and a kernel image. There’s more to configure to get this to work. One thing you need to keep in mind is that you can’t use any loadable kernel modules to access the file system since you need the file system to load them. The nice part about this is that now you have a file system that’s almost like a disk. If you make changes to your application you can use FTP to load them on the target. You can also use the system logger to log to syslog (they actually call the log /var/log/messages).

Throughout this whole process I was able to get very good support from their web site and forums. If an answer wasn’t in the documentation wiki, I would most likely find it by searching the forums. When I posted questions to the forum, I often had an answer within an hour or two. The documentation and support were better than many commercial RTOSs and cross-compilers that I’ve used.

What really amazed me was how well the tools all work. I wrote a pretty complex application in C++ using many of the C++ library classes, Pthreads, sockets, and all kinds of system facilities. I got it all working on my desktop Linux machine. Then I just recompiled my application using the Blackfin version of the tools, loaded it on my Blackfin uCLinux system and it just worked.

The one thing though that you have to remember is that if you’re messing with the kernel then according to the GPL, anyone who buys your product is entitled to the source code. Then they’re also allowed to re-distribute that code. If you’re working with custom hardware then you’re going to be messing with the kernel. I don’t think that this requirement ever hurt sales of the Linksys 54G routers though. If the project is for a government agency, they may require full source code anyway.

The Large Hadron Collider has been in the news a lot lately as they begin the process of bringing it online. Any physics experiment on this scale is bound to inspire some geeky humor (I don’t believe that’s an oxymoron.) Here is a sampling of some of what I’ve found on the net:

First the question on the minds of many,
Has the Large Hadron Clollider Destroyed the earth yet?

Next is the LHC Rap. This is actually pretty well produced and explains what they are hoping to accomplish. When I watch this though, I can’t help but think that all those people dancing around probably have PHDs and learned more math by the time they were twelve than I’ll ever know.

And finally, you can always count on XKCD as a source of relevant (pardon the pun) nerdly humor:

I also found a funny play on words or two but they’re not for a non-X rated website. I’ll leave those to your imagination. A Google search for them is an optional exercise for the reader.

Every once in a while I go over to techdirt for some interesting reading while I’m “waiting for something to compile.” They’ve had a number of posts about e-voting and voting machines in general. One in particular caught my eye: Palm Beach County Lost 3,400 Votes; Claims Different Sequoia Scanners Count Differently. One of the issues that they raised is that it is difficult for local jurisdictions to verify the operation of voting machines because the manufacturers have been highly resistant to independent inspection of the systems.

In another article on techdirt, E-Voting Isn’t Perfect, But It Takes Less Work to Corrupt Big Elections, they explain why e-voting makes it so much simpler to rig elections. The article references a paper, Voting System Risk Assessment via Computational Complexity Analysis by Rice computer scientist Dan Wallach. Being the nerd that I am, I downloaded the paper and read it. It’s pretty scary if you believe in democracy.

I’m sure that the technical community can do better than this. If we don’t want companies like Diebold and Premier counting our votes using flawed equipment and security features, I think we need to do something about it ourselves. I think we should form an organization to develop an open source voting machine. I’m sure there are some very talented computer security researchers out there who could design procedures that would make vote tampering nearly impossible. Just look at OpenSSL which is used for thousands of financial transactions every day. I also think that the open source community is better at developing reliable software  than for-profit enterprises that are more interested in minimizing cost than maximizing value.

An open source voting machine would have the following advantages:

• The complete design, hardware, software, procedures, would be open for inspection by any government body or independent panel.
• The project could attract the best and brightest in computer and systems security to ensure state of the art fraud prevention.
• The project would also attract top talent in hardware and software development.
• Local government agencies could have competitive bidding for the manufacture of the voting machines. The machines could even be made available to budding democracies in other countries.
• An open source community would be more willing to admit to flaws and mistakes and correct them.
• If fraud is suspected the open source community would be available to analyze the evidence.

I don’t know if this is a crackpot idea or a chance for us tehies to help preserve democracy. I don’t know, there may already be a project like this going. I would be interested in what others think of this idea and if anyone might even want to work on a project like this.

It’s hard to believe that I’ve been pursuing a car-free lifestyle for almost two years now. I need to explain that a car-free lifestyle doesn’t mean that you never drive anywhere. Some places really are difficult to reach without a car and if you need to move something heavy any distance, you need some kind of vehicle. To me, living car-free means not using a car for your every day trips, primarily commuting to work and shopping.

Living car-free became more of a challenge when I moved at the end of January. The distance to work changed from six miles to twenty five miles. On a good day I could drive this in about 35 to 45 minutes. If there’s an accident or the weather is bad, it could be much longer.

Using the subway and bus, it takes me a little more than an hour and a half. But I use most of that hour and a half. Being stuck in a subway or on a bus with nothing to read but Stroustup’s The C++ Programming Language has motivated me to read it from cover-to-cover. Something I would never have done otherwise. I’ve always just read bits and pieces for reference. Reading the entire book, I uncovered many nuggets of C++ wisdom that have paid off in my work daily. I’ve also been able to do quite a bit of writing while riding to work.

I can also bike part of the way to work and bus the rest. This is still the same hour and a half commute but I get a good 15 or 16 miles of biking in, mostly on hiker-biker trails away from the traffic.

Where I live now, I’m only a mile from restaurants, supermarkets, movie theatres and all kinds of stores. Almost everything I need is within walking or biking distance. If I want to down town DC, I’m only a half mile from the Metro station.

So, while I call this car-free insanity, as I watch the price of gas creeping closer to four bucks a gallon, it doesn’t seem so crazy.

I’ve been using Ubuntu Linux for about a year now and have been quite happy with it. I use to use Fedora but I have had problems with the recent releases running on new hardware. Ubuntu seems to have better hardware support. The other big difference is that Ubuntu takes a minimalist approach in their distribution, providing the minimum useful system on the distribution CD. All the optional packages you may want are provided on Ubuntu and Debian Linux web sites. Ubuntu provides a software package manager that takes care of downloading and installing what ever software packages you may select.

The one problem that I have had with Ubuntu is that I could not successfully build GCC cross-compilers on the latest release, Ubuntu 7.10. I use and excellent script called crosstool to build cross-compilers. Crosstool has always worked fine before for me, even on earlier releases of Ubuntu. Finally, in desperation, I checked the crossgcc mailing list (reminder to self: RTFM!). The answer was there and was quite simple. It seems that on Ubuntu 7.10, /bin/sh is linked to /bin/dash. I didn’t realize that there were so many shell programs out there. I simply linked /bin/sh to /bin/bash and crosstool worked perfectly, allowing me to build cross compilers for the ARM and PowerPC processors.

I published another how-to: Ubuntu Ethernet Aliasing How-to. It’s pretty simple once you figure it out but I could find no help on the Internet so I thought I’d post it.

Faster logic and processors have had a huge impact on implementation technologies over the last couple of decades. Nowhere is this more apparent than in signal processing. Functions that were the sole domain of linear circuits have been taken over by digital technologies. But what digital technologies should you use? That answer can be complicated.

Late last year, I was developing control and monitoring software for a mobile satellite networks central earth station. One of the boards my software was controlling was a sophisticated demodulator. An expert in signal processing had developed mathematical models for the demodulator and two vendors were chosen to convert the models into a working demodulator in order to reduce risk. One vendor used programmable logic and the other used a software approach running on multiple CPU’s to obtain the required performance. In the end, both implementations worked but one had slightly better performance and the other used more power. In this case the decision was easy because we had two working implementations and could measure their performance. In most projects however, the hardware/software trade off analysis must be done at the start of a project.

Last week I spent at a vendor’s site integrating the modem for the mobile satellite terminals. I had a chance to see the process of implementing a design from a mathematical model close up. The model was captured using a mathematical model and simulation tool. The engineers could then simulate the modem and tweak the model as needed to improve performance. Once they were satisfied with the model, another tool was used to convert the model directly into a logic design language. The design was then programmed into an FPGA in the mobile satellite terminal.

To test the demodulator, they used a signal generator that could generate modulated waveforms using the same models that they had developed to implement the modem. Seeing this process close up was an eye opener. Software, logic design and even test equipment driven by mathematical models made me realize just how irrelevant the underlying implementation technology has become. The real intellectual property was in the mathematical models and the C source code or VHDL are just bookkeeping.

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.