I’m sure you where all excited with that makefile from last time. Reading between the lines (well, actually it had it’s own whole line, but that’s beside the point) about the progress on the robot project. Well, I’ll tease you a little more.

To start with, I found I had to add some more lines to the linker flags. I found that dd-wrt mini, which we are using, does not have libstdc++ installed. The toolchains have a copy of the library for mipsel, but the read-only filesystem of the router prevents it from being loaded even if copied there to the writable part. So there are two ways of dealing with that. First, we could build our own version of the firmware and include the library there. Every possible and easy to do. The other option would be to statically link the library in at compile time. Normally, such a thing is frowned upon, as it makes bigger binaries and the point of the libraries is so that many programs can use them without having their own copies. But, this is a one off program, and statically linked programs are a little faster, and library itself would be larger when dynamically linked than the whole program with it statically linked. It also means that the program will run on standard firmware without issues.

You might notice from that and the makefile that the program is all in C++ now. I reworked a lot of code and added in a bunch of new functionality. The new code is the main reason for the make file. Three files is ok to deal with manually, but I knew that it wasn’t going to stay as three files. It has grown to 6 .cpp files, and I’ll probably end up with at least 2 more.

Well, what does it do? First, we have some sensor classes. These serve as objects that can handle the different types of sensors. As of now, we have the magnetometer, the accelerometer, and the mouse. I can’t say that the accelerometer functions will accurately calculate distance yet, as I haven’t been able to get good data to test with, but in theory it should work. These objects will be shared between the sensor reader functions and the position update functions. Secondly, there is the serial functions. This is just a set of functions that open, read, write, and close the serial port. These where all mostly written before, but now it’s packaged up nicely. Thirdly, there is the position update file. This provides a position class that has functions to keep track of where the car is and where the goal location is.

We can pause here to look at the main file, which drives this system. It opens the serial port, and attempts reads, at which point, it will feed that data into the position system. The position system will calculate an X and Y and angle relative to the starting point. I tested this code with a small test that spit out a few angles and distances (not accelerations). I then had the positioning system spit out an X, Y and angle in comma-separated-value format, which can be imported into a spreadsheet. Plotting this, I saw the angles and the movement that I roughly expected. This was rather exciting.

I have since added a class for a “movement” or a simple step (a long the lines of “move forward 2 feet” or “Turn right 40 degrees”), some functions that read that in a queue and execute them, testing for when it’s done, and as part of that, code that will send the one byte commands to the microcontroller to drive the car. This portion has not been tested yet, but will be soon. We are working on getting the microcontroller powered by the car battery and working on getting good distance data from something.

The next piece that I haven’t quite cracked is point to point drive. I have some equations and some code, but that will have to be re-written for C++. I also need to work out the inter-router communication. But if I can’t get one car to go, I can’t get 4.

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.