A while back I posted about my work to enable support for the Microchip MCP2515 CAN controller with my Gumstix Overo. At the time I was confident of success because I was successfully receiving messages from my AVR setup. It was only recently that I discovered that in fact although reception was ok, transmission was not actually working.

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.

I’ve had a long interest in using Controller Area Network (CAN) to communicate between different components such as sensors or GPS modules or motor controllers. I wasn’t sure if I could do this with the Gumstix Overo board, but I got excited when I found out that Linux kernel version 2.6.33 would be including a driver for the Microchip MCP2515 CAN chip.

This required creating a custom image for the Overo, which meant setting up a build with OpenEmbedded. The Gumstix guys made it sound pretty easy in their instructions, so I set off to make it happen. I started with a virtual machine with Ubuntu 9.10 and set up bitbake and OpenEmbedded as suggested.

I’ve uploaded a tarball of my user.collection directory with overrides for the Overo machine configuration (you could probably ignore that) and for the Linux 2.6.33 recipe to include my configuration and patches to the Overo’s board initialization code for the MCP2515 chip on SPI bus 1 chip select 0.

My working environment for the org.openembedded.dev component uses change d535da0dfe20e965adb49d3acf720e7f9feb58c6. I’m sure by the time you try this there will be newer versions, but I can’t say whether my patches will work or not.

As for the hardware, the Overo uses 1.8v internally but the MCP2515 uses 5v. I used a few SparkFun logic level converter boards to translate voltages. Despite what you might read on their website, DO NOT USE the RX channels as this will send 2.5v into the 1.8v-capable pins on the Overo! Only use the TX channels (they are bidirectional and work at the correct voltage). I needed to translate five pins (SCLK, MISO, MISO, CS, and an interrupt pin) so I used three of the SparkFun boards.

I was able to use the candump program from the socket-can test tools suite to verify correct operation. Awesome!

From the exceptionally low frequency of updates to this site this year you’d think that I have nothing interesting to post about. Not true. Things have been exceptionally busy at work, and I’ve also managed to find some interesting things in my pursuit of building robots.

I took a trip for work to the Sophos HQ in Abingdon, United Kingdom a couple of weeks ago. Its just outside of Oxford, and its a great place. It was really nice to meet people I’ve been talking to (over the phone) for quite a few months now, and the week I spent there was incredibly productive. This was the culmination of a lot of work since spring, and it seems like its only getting more busy now through the summer.

For my robotics hobby I picked up a Hammer board from Tin Can Tools. This is a development board built around a Samsung processor with an ARM 920T core. I have this crazy idea of making a Line Maze robot that runs Linux for the Seattle Robotics Society Robothon event this October. Seriously!

The other major “toy” is my new iPhone 3GS. I’d been waiting for the new model to come out, and I even took time off from work to go stand in line on the morning it was released. I really like it, definitely another solid Apple product. I’ve slowly been re-incorporating Apple products into my household: a 15″ MacBook Pro, a Time Capsule, and now an iPhone. It is just so much better than my previous phone (Motorola Razr) and its also much better than any other device I looked at including the Blackberry product line and the phones running Google Android. I’ve got the iPhone SDK installed and have started writing my first applications. Learning Objective-C is nifty although it makes my brain hurt a little after so many years of writing C++ and Perl/Python/etc.

The day I bought my iPhone I left it with Eileen and I went out to play golf with a friend. By the time I got back she had fallen in love with it too, and demanded we go out and buy her one. So now we are a two-iPhone household.

Golf. Yes, golf. I’ve been playing pitch-n-putt (par 3) golf with people from work this summer and having a great time. I’m not that good but still its a great way to be outside and includes a small amount of physical activity. I don’t think I’ll graduate to playing a full-size course but these short courses are a lot of fun. We’ve lived around the corner from a course for a number of years but never been there. Now I will often get home from work, pick up the clubs and walk five minutes down the street to play nine holes. Lots of fun!

I found an interesting AVR32 development kit online that promised to be very inexpensive yet flexible enough for full prototyping. I quickly jumped at the chance to order one of the AVR32 DIL modules, and after a quick email with Rikard Strömmer (the seller) to work out the details I bought it via Paypal. It arrived in the mail last week and I spent a few hours yesterday playing with it.

Rikard sent me the full development kit, asking for some feedback. I found a few very minor documentation errors (he will fix them pretty soon I expect) but otherwise the kit went together exactly as advertised. I took several pictures during the build, you can see them here.

Anyone who already has a well-stocked prototyping workbench doesn’t really need anything more than the AVR32 DIL module, but even so it was very convienent to have just about everything required included – you have to provide your own 9v battery, some jumper wire and a solderless breadboard.

I’ve just started to play with the software side. Atmel makes a very rich software library with plenty of examples available online. They also supply a version of GCC, similar to the WinAVR package for the 8-bit AVR line. It is nice to see them taking the free software approach, makes it very accessible for hobbyists.

Rikard’s instructions have you modify one of the Atmel examples as your first program. It blinks one of the LEDs and uses the push button (left side of the board) to turn the second LED on. The reset button (right side of the board) works too. I made a little movie of it in action, watch it here.

The AVR32 is quite a bit more powerful than the 8-bit AVR processors I’ve been using in my robot projects. I’m not quite certain what I’m going to do with it yet but it would make a great upgrade for the AVRCAM project, or maybe use it for the heart of an inertial navigation unit, or maybe as the brain for a whole new robot project.

I’ve put together pictures of the CAN bus “sniffer” project I made recently. Here is a picture of the “sniffer” hardware implementation, connected to another project that reads data from a GPS module (that small square thing in the lower right corner of the photo).

The basic idea is that the GPS interface board (the green board at the bottom of the picture) is reading data from the GPS module, doing some processing of the data, then forwarding latitude and longitude over the CAN bus to anyone who wants to listen. Someday I’m planning to implement a robot that will use that data to help navigate.

My robotics library contains the “sniffer” demo program (it uses the same hardware as the can_mcp2515 demo) as well as the code I wrote to parse the GPGGA-style sentences from a GPS module like this one.