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!

After a miserable start Microsoft gave up on a silly advertising campaign (and supposedly also a very expensive campaign) to have Bill Gates and Jerry Seinfeld explain to me why Windows was wonderful. Their next attempt was the “I’m a PC” campaign that was somehow supposed to convince me that it was cool to use Windows. Their latest attempt now tries to convince me that purchase price, rather than coolness, is the primary factor I should use when deciding on a new laptop. Uh, what?

I appreciate value as much as anyone else, but seriously Microsoft is once again missing the boat. I’m sure the Apple execs are laughing (again) at this new attempt. I certainly am. In addition to laughing I’m also quite puzzled why Microsoft seems to be funding the advertising for Best Buy and HP. Whatever.

People like their iPods and iPhones because they feel nice to use. Ok maybe people get them because they look cool. Maybe coolness is why people buy, but that isn’t why people recommend to their friends. When you ask people who have a MacBook whether they’d recommend one, they aren’t going to tell you about price or about coolness. They tell you about the joy of using it and getting things done. They tell you about the joy of having a computer that “just works” for them.

Usability has always been a key thing for Apple and it really shows. I believe this is because Apple creates a cult-like passion amongst developers and users about it. I believe that Microsoft is interested in usability, but somehow they can’t seem to make it work. You can watch Steve Ballmer run around shouting “Developers! Developers! Developers!” but is he really trying to create the passion and commitment to design? Probably not. There is even a famous email from Bill Gates where he bitterly describes his frustration with Microsoft products.

Its almost like nobody there actually gets it, but that certainly isn’t true. There are “islands” at Microsoft where usability really shows (Visual Studio is my best example off the top of my head – it is exactly the right tool for me to write solid software) but the overall consistency is lacking across Windows as well as every other application. I gotta say I’ve never believed you can have real usability without end-to-end consistency, and Microsoft’s product portfolio seems to be a perfect example of that.

I’ve been lucky enough to have been introduced to real usability concepts, and when you understand the science behind that word you can appreciate why Apple seems drenched in it but Microsoft isn’t even in the same neighborhood.

I wrote a few days ago about my work on a better DXF export module for Inkscape. I was using it again today for my upcoming CNC milling efforts and found a few bugs plus added another feature.

There is a bug in Inkscape’s simpletransform.py when it attempts to handle transformations of scale, rotate, etc.

I also improved my own exporter and added a feature that creates POINT entities instead of LINE entities for objects on layers that end in the word “drill”. SheetCam uses POINT objects for drilling and I didn’t have an easy way to create them. There really isn’t a way to turn this behavior off (other than not end your layer names with “drill” so if you end up using this extension, be aware of this). It works best with small rectangles because it will compute the center point of the path bounding box as the location for the POINT. I just create small rectangles the same size as my drill hole.

I also corrected the list of dependencies in the better_dxf_output.inx file.

For anyone who is interested, visit this page to download all of the required files.

I’ve been using SheetCam to generate g-code for my CNC mill and so far I’m pretty happy with it. It probably isn’t the top-of-the-line CAM software available but its (so far) doing the job for me. SheetCam consumes DXF files – a vector format originated by AutoCad. So I needed something that would generate DXF and I wanted something simple. Someday I’ll probably want to invest in a high-end CAD program but for now I really wanted something very simple and very cheap or even free. I immediately thought of Inkscape, the free vector drawing program for Windows and Linux.

I’ve been using Inkscape for other projects for quite a while and I had noticed it would export to DXF so I thought I was all set: just draw my part outlines in Inkscape and export a file for SheetCam. My first experiment with one simple path object was successful so I optimistically figured everything else would simply work. Oh that would have been too easy…

First I discovered that the Inkscape DXF export doesn’t support layers. It also doesn’t support objects other than paths (Inkscape treats rectangles and circles and such as objects other than basic paths) so my exported files were mostly blank. Although figuring out these problems took quite a while because I (naively) thought all of this would simply work so I didn’t bother to research it very deeply from the start.

So I started to dig into the problem in the Inkscape bug database and sure enough there were two additional problems highlighted:

1. the DXF export did not support objects with the “transform” attribute; this meant that sometimes objects were simply in the wrong position and it was hard to know when it could happen without exceptionally detailed proof-reading
2. the DXF export didn’t produce “usable” DXF for at least some readers; SheetCam wasn’t mentioned by name but it seemed that maybe it wasn’t an uncommon problem

Through my own experimentation I found that SheetCam didn’t import the SPLINE objects from the DXF correctly (they were highly distorted). I will say that the SheetCam support was very helpful in explaining the problem as well as making a couple of useful suggestions that I could do inside Inkscape manually.

It worked, but I really wanted an automated solution to as many of these problems as possible.

Fortunately I discovered that Inkscape’s export module is written in Python and I could easily modify it. So I rolled up my sleeves and made my own version of the DXF export module that solves my problems. I started with the updated version from that Inkscape bug but added logic to save the layer identifier for each object and (using a separate Inkscape module) convert cubic paths into line segments (flattening) automatically. I also fixed up the problem with the “transform” attribute. It still doesn’t deal with arbitrary object types but that is pretty easy to solve (Select All, Convert Objects to Paths).

So now its back to the design stage for my next milling project!

For anyone who is interested, visit this page to download all of the required files.