I apologize for the downtime the past few days. I upgraded my computer’s operating system from Fedora 9 to Fedora 12. Just got the Database re-imported. All should be well, as I grabbed a database dump and saved all the files just before taking it all down. If you notice anything amiss, let me know, and I’ll fix it.

First, I want everyone to know that I love open source software and Free software (as defined by the Free Software Foundation). I use Linux every day on my desktop. I use OpenOffice.org as my office suite. I use Notepad++ on windows, I use Firefox, Thunderbird, Adium, Pidgin, and countless other worthy examples of free software. The issues I’m about to bring up exist in closed source software, and are usually exacerbated by that fact. This is probably a fundamental issues with software. But open source software advocates (including myself) often ignore these issues, or even claim they don’t exist because of the open source nature of the software.

The first issue is with compatibility. Open source advocates often claim that, because the source code is available, one can make the program to run on any system they desire, even if the original developer does not want to, or is even completely unavailable. You could take a long dead project, re-compile it on your new platform, and it works. At least that is the theory. And the idea goes the same in reverse: take a new project, and re-compile it to run on an old system that no one wants to support anymore. But there is a catch. To do either stunt, one has to be rather knowledgeable about programing, and possibly the software they are working with. Then they would probably have to spend a long while porting that software (possibly creating new bugs, removing features, or breaking it entirely) just to get it to compile and run.

Case in point: I recently had a need to run a SIP phone on a Red Hat Enterprise Linux 4 machine at work (for those that don’t know, RHEL 4 is rather old, about 3 or 4 years old, I’d estimate, and they are up to 5.4). My first thought was to try and find out if the rather new Ekiga project was available as an RPM that I could easily install. All available RPMs would not install due to the old version of RHEL. So I tried to grab the source code and compile. After updating numerous libraries as far as I could with RPMs, I attempted to compile Ekiga, only to have it fail because I still lacked some libraries or versions of them. After spending hours attempting to get it to work, I finally gave up and found another way to do what I needed to do. I’ve also had a similar experience trying to build an old program for a new system. There are so many dependencies that it becomes next to impossible.

Windows people usually don’t have much of an issue with this with commercial software, as they often pack in the necessary versions of everything, and manage to make sure they don’t overlap, usually. Running newer software on older machines may work less well because of some libraries and the like, but it usually works ok, at least for a few versions.

So this idea that, because the source code is available, it should always be able to work how you want it is more theory than reality. Closed source software also has this issue, but, because of other workarounds and the like, usually sidesteps it. It does mean that, if someone happened to come along years latter to find some ancient program still running, that they could figure out the bug easier because the code is available to him.

The other issue is related to that last note: that the source code is always available. Sometimes projects die, and, despite attempts to make sure that the source stays available, it might get lost though hardware failure, or server neglect, or some other issue. Most of my projects are only available on my site, sometimes with source code included or available. Some of them are mostly abandoned, meaning I have no intention to work on them in the foreseeable future. If my server died a horrible death, it would probably take my projects with it. I have backups of them, but if I moved on completely and just had this site for historical reasons, I might deem it not worth my time and money to put back up. Or, if I passed the reigns to someone, they might not want them back up, or forget about them and not know they disappeared. I’m not saying that it will happen, but as a what if. Then, if someone finds a link to a project of mine down the line, and realizes he needs the source (or even just the binary), he can’t get it. He searches for a backup, or someone that had a copy at some time, and can’t find one. Then my project, despite being open source and available to anyone, is gone for good, and that’s the end of the line. The guy is out of luck.

I’ve run into that issue before with closed source programs. A binary library I used for one version of my web server had a bug where it wouldn’t release a graphic handle correctly, and thus the system would run out of handles and the computer would have to be restarted. I had found the library about a year prior to when I found the bug. I went back to the site to find it exactly the same. I sent the owner an email though the site, asking for either a fix or the source to fix it myself, if he was too busy to be bothered. No response. I went back a few months latter, and found the site completely gone. Not even a parked page. I probably have one of the few copies of the library left. The only difference this being open source would have made is that I could have gotten the source when I went back the first time. But I could have just as easily missed my chance had the site closed a few months earlier.

I don’t think there are any solutions to these issues. I merely want to bring them to light so that people are aware that open source is not a panacea to possible future issues.

Well, here you go, folks! I’m posting everything here. Code, schematics, the paper, pictures, and a clip of the cars moving! Enjoy! (more…)

I don’t know who all here may have used Makefiles before, but I can say that they are amazing. They let you do a complex compile with one command. Every major project has a makefile because it would take too long otherwise. But they are archaic in their syntax. There are tutorials on how they work, but none are really easy to understand, and always require major editing to work with your project.

I’ve used make files before. Usually when compiling some other program. I’ve looked at them before and knew the general format, but not really how to make one. But I found I needed one to work with my growing code base for my router project. After a lot of poking, proding and researching, I created the following makefile that is mostly generic for whatever source files you have and scales up fairly well to a certain point.

#define the programs and flags to use
CC=mipsel-linux-g++
CFLAGS=-Wall -c
LD = $(CC)
LDFLAGS= -lm
RM = rm

#the output executable
EXE=serial

#List all source files here
SRC = sensor.cpp serial.cpp position.cpp main.cpp

#that should be all the editing. The rest shoudl work based on the above
OBJ = ${SRC:.cpp=.o}

#defines suffixes and how to compile
#clear out any others
.SUFFIXES:
#define the ones we need
.SUFFIXES: .o .cpp

#how to get from .cpp to .o
.cpp.o:
        $(CC) $(CFLAGS) $<

#compile everything and create executable
all: prog distclean

#link all the object files and create executable

prog: $(OBJ)
        $(LD) $(LDFLAGS) $(OBJ) -o $(EXE)

#insert other header files here and uncomment
#$(OBJ) : header.h

#removes object files and the executable
clean:
        -$(RM) -f $(OBJ) $(EXE)

#removes the object files to make things pretty

distclean:
        -$(RM) -f $(OBJ)

Lets walk through that mess. First, when we hit “make” it goes and sets up the variables up top. There, we list which compiler to use (the wrt c++ compiler), the flags to use with the compiler (warn on all, and that we are just compiling, not linking), the linker and it’s flags (linking in libm for math stuff), and our remove command. We also setup with the final executable will be named, and list all our source files. These should be the only lines we have to edit. The rest should be handled automatically, unless there are specific things you need.

The OBJ line takes the list of source files and changes the .cpp ending with the .o ending to have a list of all the resultant object files.

Make then finds our first real rule: all. It sees that to do this rule, we need the prog target and the distclean target. To make the prog target, make sees we need all those object files first. To get the object files, it sees that suffix rule “.cpp.o”. Make knows that for each object file we need, there is a .cpp file that goes with it. So when it sees we need, say, serial.o, it compiles serial.cpp. The “$<” thing becomes the .cpp file when make is running.

So it compiles all the files into object files, and it comes back up to the prog rule.The next step is listed underneath and says to link them all and output the executable. It does that then comes back up to the all rule and sees it needs distclean. This just removes all the .o files to make things nice. That isn’t necessary, but I link it.

So, just by listing all your source files in one line, we can compile and link them all automatically. Much nicer than manually compiling, or doing the same just using a makefile. This helps when you add a new part to your code. you don’t have to do more than list it.

There is one portion where you might have to add things. Sometimes you need to include a header file, but you can’t in the source files themselves. The section near the end that says to list header files should be uncommented and you should place your header file names there. This will be sure to include them for you.

By popular demand, mostly by me, I have uploaded some pictures of my RC car robot project. First, we see a nice picture of the car we are using. Yes, it is a Mustang. It some cheepo car from Target. Nothing special about it other than the size. It is a fair bit bigger than normal RC cars. It’s about 16″ or so long. Enough room for all our gadgets.

Inside is a small circuit board that houses all the goodies that let the car drive, besides the motors. On board there is a voltage regulator, 2 H-bridge circuits (one set for Right/left using small transistors, one set for drive using the large ones on the right), and an IC that translates the RC signals to control the H-Bridges. That IC just has 4 outputs: right, left, foward, and reverse. It just puts a little power out on up to 2 of those pins at a time and the thing goes. It doesn’t have variable speed or turning, but whatever.

This is after we soldered up some wires. It was also taken after we fried the small transistors, but you can’t tell.

And the Underside

I have some more pictures of motors and such, but who cares? Let me know and I’ll post links to them.

Second, we have the brains of the outfit. Not not me. The router.

This is the replacement router, the WRT54GL v1.0. Inside we see all the goodies it has to offer, such as Serial, JTAG, the broadcom mipsel processor, and the normal wireless stuff.

We can zoom in on the serial port, which has the pins added in this picture. There are 10 pins. From what I can tell, 9 and 10 are ground, 4 and 6, and 5 and 7 are the data pins for the 2 serial ports provided. In DD-WRT they show up as /dev/tts/0 and /dev/tts/1, unlike the normal /dev/ttyS0.

Finally, I leave you with very zoomed up picture of our digital compass. Those 6 pins on the top are the same size as the ones on the serial header. The board is slightly smaller than your thumbnail. It can find 64 different angles from north. Not very detailed, but enough for our work. Considering how much anything better would be, this was a steal.