Debugging the mcp251x Linux driver was an interesting exercise. Google wasn’t much help, as it seemed the few others attempting this same feat were either successful or completely unsuccessful. My situation suggested I didn’t have any electrical problems nor did I have any compatibility issues. Though resolving my problem I learned a whole lot of stuff I didn’t expect to, but it was really fun and rather educational. Maybe by sharing my diagnostics process others can learn something too.

Since I had a working receiver I was working under the impression there was some sort of issue with the way I configured the mcp251x driver. I tried upgrading to the latest version of the kernel (2.6.34) but no joy. I also looked at the latest development version of the mcp251x driver from the SocketCAN project. No new insight there at all.

From building a simple driver for the AVR chip I had a good working knowledge about how the MCP2515 works, so I figured it was really something to do with how the driver was written. It obviously wouldn’t be a generalized problem, but I had no idea what could be wrong. I started by adding a whole bunch of printk() debugging statements to better trace how the driver was called from userspace. Something odd was happening where the driver was repeatedly polling the MCP2515 chip for status. I traced what it was doing in the code and also followed the SPI conversation using my Saleae Logic logic analyzer. Nifty device by the way, highly recommend it. Turns out it didn’t really help solve the problem, but it did manage to help eliminate various false leads.

The SPI conversation and responses were perfectly normal. More printk() statements later and I was rather stumped. Then it occurred to me (at a time I wasn’t actually in front of my project) that there really should not be any polling. The driver configured itself with an interrupt line to know exactly when an event was pending. The polling I could observe over the SPI bus suggested this mechanism was not working (the status returned by the chip was correctly suggesting there was no pending events most of the time).

Turns out the default Overo build from OpenEmbedded sets up the GPIO pin for the interrupt line with a pull-down resistor. The interrupt line should normally be high then pulled low to signal a pending event. As far as I could tell, the pin was never actually being pulled high enough to be sensed by the Overo processor. I expect that the voltage level converters I’m using are to blame, failing to overcome the resistance of the pull-down resistor. This meant the Overo was seeing the GPIO pin as a low logic level all the time, leading to a constant interrupt. When this happens, the interrupt handler will fire and poll for the reason for the interrupt. Inspection of the code suggests this could starve the transmit code path from ever getting enough time to send messages. Indeed this would explain the situation I was observing. I adjusted the pin configuration in the u-boot recipe (now in my user.collection) to use a pull-up resistor instead, and now everything is fine. Because of the way that the mcp251x driver is written this should be ok.

I also discovered my previously published user.collection tarball was not matching my actual configuration. For reasons that are (again) likely due to the voltage level converters I lowered the maximum SPI rate to 500kHz. I’m using a CAN bus speed of 125kHz with a very low message frequency, so this doesn’t seem to be a problem. I was also annoyed by several of the useless messages printed to the console from the SPI driver and the mcp251x driver, so I commented them out with my own patch. Both issues are now fixed in the tarball. Download, roll into your own user.collection directory, and enjoy.

It turned out delicious and I’d highly recommend it.

I did get up and go stand in line at the local Fido store at 8am (they open at 10). The first guy in line was there at 2am, the next fellow arrived at 5:30. The two other people in front of me arrived between 6:30 and 7am. I was fifth in line, and more people started arriving rapidly. By 8:30 there was ten people waiting. The “rumors” said this particular store would have as many as fifteen phones for sale but only three 32gb models. A quick poll revealed that of the four people in front of me only two were buying the 32gb model so I was likely to get one if I wanted one (I did, I was replacing a 32gb 3GS and didn’t want to downgrade).

Nothing like hanging around with a bunch of other fanboys for a few hours debating the positives and negatives of Apple, OS X, MacBooks, and of course the different iPhone models! It was pretty easy to pass the time.

By 9:30 the staff arrived and started to prep the store. Nice people, but you could tell they had a long day in front of them. Fortunately they had a great attitude about it and we had lots of fun chatting them up. Those of us standing in line started getting antsy though, and at least another ten people had arrived looking to buy the iPhone. Other people in the mall gawked at us a bit wondering why were were silly enough to be at the mall well before it opened. Precisely at 10 the first sale began, but of course it takes FOREVER to process these purchases. I didn’t get mine until after 11am then had to wait for activation later this afternoon.

I bet there were at least 10 people turned away while I was there and I bet even more were turned down today. The local news said every place was sold out almost immediately this morning. Once again, Apple will get to publish stats about completely selling out in a matter of hours.

I’ve been playing with it for a few hours now and really love it. Well worth the money and time spent.

The B&B has a nicely equipped kitchen so we made our own meals most of the time. I made ham and cheese omelettes each morning and we grilled out for lunch. Dinner was usually fruit, cheese, and wine (or port – we had a nice Smith Woodhouse LBV with us).

We did have lunch in town once, at the Sweet Water Bistro (Urbanspoon link). We stopped in Mike’s Gelato as well, for a refreshing treat while poking around town. We didn’t get to Smitty’s but was recommended; next time we’ll go there for oysters for sure.

Gibsons is about 40 minutes by ferry, and the B&B is another ten minute drive. Highly recommended if you are visiting that area.

I uploaded some photos here, enjoy!

The drive shaft is made from 1/4″ steel rod turned down at each end using my Sherline lathe. This was the first time I turned steel on it, and it was surprisingly easy to work with. So far I’d say brass and steel are better materials to work with than aluminum (at least on the lathe). I turned each end down to 0.2″ then proceeded to cut the end to be somewhat ball-shaped. I only needed a couple of these so eyeballing it worked really well. The pin is some brass rod I had, super-glued into place. I liked the idea of using a softer material so it can shear away if necessary to prevent motor or gearbox damage in case of excessive force.

The coupler has a socket at one end (to accept my faux-dogbone drive shaft) and a 6mm hole with set screw to attach to the motor shaft. I turned some brass stock down to 0.6″ then drilled out the center for the motor shaft. Mounting it on my mill gave me a good setup to drill the hole for the set screw and mill out the groove on the socket. A tapped hole in the side for a 8-32 set screw completes the job. Depending on how well this holds up I may end up making a new version out of steel.

Here is another picture of the coupler and drive shaft, showing how the two parts fit together. The last picture shows the parts mounted on the robot itself. This now means the mechanical part of the drive train is complete, and (with some batteries and electronics) the robot will soon be rolling around my yard.

The motor mounts are milled from half-inch aluminum plate, holding two GHM-04 motors plus shaft encoders from Lynxmotion. These motors should be plenty powerful enough and also have a good top speed for this application. It took me a few hours to mill out the two mounts using my CNC Sherline. I need to make some couplings and drive shafts to get the motors connected to the rest of the drive train.

The steering mechanism is from the original RC truck chassis, I just needed to do something about controlling the servos. I set up an ATMega88 that sends the necessary pulse train for servo control. Eventually this chip will communicate with the Overo over CAN, also talk to the the motor controller board I purchased from Pololu, and will have a custom circuit board. For today its only task is to control the steering servos, accepting keyboard input from a serial console.

I needed to calibrate the servo pulse train to the desired positions of the steering mechanism as its installed. Normally servos are a wide range of motion (most go 180 degrees) and accept a pulse train with widths between 1ms and 2ms. These servos do that just fine, except there was no way to know where “center” was in relationship to the wheels. I also wanted to make sure I was getting approximately the same angle on the front and back steering. I created a little jig using some right-angle machinist squares plus clamps plus a ruler. Finding the center position was easy, then I mapped out the servo position required to move the wheel indicator in half-centimeter increments. I ended up with a table of 25 different entries for the front and the back steering servos that give me consistent control. Given the slop in the steering mechanism from this truck chassis, I figured this was good enough.

Here is a little movie of the steering in action. I set up the camera on a tripod then was pressing keys on my laptop that instructed the microprocessor to move the servos to particular locations. I have fully independent control over the front and back steering, and it really looks awesome.

You might also notice in the top right corner of that picture my new Rigol 50Mhz dual channel oscilloscope. Its a nifty piece of equipment, lets me look at signals like the servo pulse train easily. I picked it up from eBay for a reasonable price and so far (having only used it for a day) am very pleased. I recently also bought a Saleae Logic analyzer that I’ve been pretty happy with. I’ve been using it with the “early preview” version of the Mac software. It has bugs but so far none have prevented me from getting the job done. I’d recommend both pieces of test equipment for your own bench.

I have no idea how it worked out so well but through the miracle of online ticket purchasing combined with some amazing luck we scored front row seats on the floor, right in front of the stage. If I’d wanted to, I could have jumped out of my seat and easily leapt on stage. I could have tackled C3PO (Anthony Daniels) if I’d wanted to. Fortunately I resisted this urge and therefore am not writing this from jail.

The event itself was really great, the music was wonderful and we were close enough to watch the individual performances of each member of the orchestra. The only somewhat disappointing part of the evening was having to sit through so many clips from the most recent movies (episodes 1, 2, 3). It really is painful to watch the stilted dialogue and terrible acting. There were plenty of scenes from the “good” films too, especially lots from episode 4.

Of course the famous cantina scene played, with the live orchestra giving a great performance. Even though the film clip was from the 1997 redone version, we all knew Han shot first.

The seat selection process is both thrilling and depressing – GM Place has something like 18,800 seats for each game (sold out every night) and yet there are really only a handful of seats available when we get the opportunity to pick. We could have kept our same seats from last year, but we were looking for something a little better: less behind the goalie and more around the side towards the blue line. We also were interested to get closer to the front row.

We lucked out this year, there were a few seats that met our “upgrade” requirements: about half-way between the goal line and the blue line, and row 3. The picture here shows the view of the defensive zone net from our seat. Nice!

Its going to be a long summer waiting for the season to start!

Already looking forward to next season where we will be cheering for the Canucks again.

We stopped into the local bookstore and picked up a copy at the very next opportunity. There are a quite a few good recipes in this book. We’ve made the fennel salad and rosemary cashews, both are easy and excellent. Eileen really wanted to try the soufflé but I’d never made a soufflé before, and always heard it was really tricky. Certainly there are plenty of jokes about slamming doors and banging pots causing the soufflé to fall. But I decided to give it a whirl anyways, with Eileen’s encouragement. And she said she was hungry, so it was either order something or make the soufflé.

It turned out extremely well. I’ll definitely make it again. Eileen thought of making this as a side to a roast lamb dish, so I’ll have to find an excuse for a dinner party and make it!