I just wrote a udev rule that would make any userspace i2c devices be owned by the i2c group:
KERNEL=="i2c-[0-9]*", GROUP="i2c"
(You can stick that in a file in /etc/udev/rules.d if you’re using Fedora).
- Add 4 lines to the firmware for the MSP430s that sequence the stepper motor drivers so that they half-step (so that there are sometimes two active coils).
- One’s resolution has doubled.
- Dance.
- Push changes up to public firmware git repository.
We did have a resolution of 0.2mm per step. Now we have 0.1mm. w00t.
Have just spent an hour or so setting up an RSS feed for John’s New Zealand adventures. Should update every half an hour.
Source used to generate it available here :-)
Edit: Something’s gone wrong with the ECS servers… I guess it’ll be back up soon…
Edit: Seems to be back up now.
- 0830: Received a text from Tom containing a highly compressed set of questions relating to the power board. Set about answering them when I got up.
- Processed some paperwork.
- Worked on Farnell screen scraping - progressing nicely. Some nasty problems involving Unicode strings getting munged about though.
- Read about John’s escapades.
- Had some xbee related conversations with Phil. Sadly massively diverged into setting up his ssh config.
- The random period of immense internet laggyness started early today. Around 7pm I guess. Moaned profusely.
- Performed a very short investigation investigation into radio modules for general stuff-monitoring projects. Decided that the CC2420 might be good - but a little expensive (~£5 a chip from Farnell). Will continue search for cheaper alternatives. Would be good to produce a large number of devices that use them.
- Looked for an extension lead casing manufacturer. Was pretty unsuccessful. Wanted to find an extension lead casing with space for some extra electronics in it…
I want to be able to program and debug PICs with my MPLAB ICD 2. Unfortunately, Microchip doesn’t spec the USB interface to the ICD 2, so unless I reverse engineer it there’s not much I can do but use the Windows software they provide.
I don’t like windows.
So, I installed Windows Server 2003 in the version of QEMU that the KVM people produce. The install ran really smoothly up until there were 39 estimated minutes remaining. It then took around 4 hours to complete. I installed MPLAB in the VM, plugged the ICD 2 into my laptop and then “plugged” it into the VM’s USB. One of those annoying little “you’ve just done something” balloons appeared and I selected “automagically locate driver”. It failed to find a driver. Urgh.
I then thought “Hmm. I haven’t actually tested that MPLAB works in the VM”. I ran MPLAB. It said something along the lines of “MPLAB doesn’t work in this operating system”. Damn.
Take 2
So, I started to create a new VM containing XP. Many hours later I had a fresh install of XP. Installed MPLAB. Ran MPLAB. Worked. “Plugged” ICD 2 in. No magic bubble. Rats.
“Perhaps I need SP2… I’ll run Windows Update.”
I ran Windows update. Many many many hours later I have SP2 installed. Plugged in ICD 2 and joy - magic bubble appears. Automagic search for driver successfully installs the driver.
From when I’ve used the ICD 2 before, I remembered that when one plugs it in, you get two magic windows “device connected” beeps - and one has to install two drivers. I’d only installed one on the VM and the magic bubble generator appeared to have run out of fuel.
Then I noticed that the USB Device ID of the ICD 2 had changed. Presumably the first driver changes it in some way after loading firmware into the ICD 2. Telling QEMU to connect the second device caused Windows to locate the device and to generate another magic bubble.
Yay!
I ran MPLAB and it successfully updated the “operating system” on the ICD 2:
I have yet to try it with a PIC… That’s the next step :-)
I spent the first half of today learning Tcl. Then I started writing a gumsense extension for it:
load ./libgumsense.so gumsense::open puts "The time is [gumsense::read_time]" gumsense::set_time 3 puts "The time is [gumsense::read_time]"
(NB: I’m experiencing problems with making it a package at the moment because the gumstix buildroot doesn’t install everything (I think) it should - wasn’t a priority.)
Output:
# ./test.tcl The time is 1176423144 The time is 3 #
So now I just have to spend a few hours wrapping Tcl around the C library, and I’ll have got somewhere…
Four days ago I started working on getting the Gumsense to turn the Gumstix supply rail off when Linux has shutdown. I started writing a blog post containing all the things that I had examined. I’m still writing that post; it’s getting pretty long, and will arrive soon.
During that process, I realised that I was going to have to write a kernel driver for the Gumsense. I’ve now written that driver. It’s the first kernel driver I’ve written. It’s a relatively simple driver, but it represents a big increase in my knowledge of Linux internals, and I’m pretty pleased with it. It’s an I2C chip driver and hooks into the Gumstix platform code (which I also had to slightly modify so that I could hook into it).
After a surprisingly straightforward and pleasing construction and debugging session, the Gumstix is now on the Gumsense mark 2 :-) The Gumstix powers up fine and communicates with the MSP430 successfully.
So far I’ve found two mistakes and two slight annoyance on the board:
- I’d missed a ground connection to the output capacitor and diode of the Gumstix switchmode supply. Easily fixed by a short piece of thin blue wire soldered between the diode and a nearby grounded via.
- I’d done something weird in the Eagle schematic editor. Eagle has an annoying feature that allows two unconnected wires on the schematic to become part of the same net. That’s not so bad - normally I promote using netnames to connect different parts together. The problem is that in this case, only one of those tracks is labelled. So, I ended up with the MSP430 supply being connected straight to the voltage regulator rather than going through a schottky diode first. This meant that the button cell initially didn’t do anything. Fixing this required the cutting of 4 tracks and the addition of 2 very short pieces of blue wire.
- The first slight annoyance is that I’ve put a dual diode (BAT54C) too close to a capacitor. It all fits, it’s just a little tight.
- I neglected to put a decoupling/resevoir capacitor on the MSP430 internal reference output pin. The datasheet recommends this. I’d written it down in my list of things to do before the board went off to made too. For some reason, I just completely ignored it.
So, the blue wire count is now three. Analogue section next.
I’m currently:
- Running linux on a gumstix
- Running gdbserver on that gumstix.
- Debugging a program on the gumstix using gdb on my laptop (which is running linux)
- Remotely debugging the msp430 that’s connected to the gumstix I2C bus
Oh, but wait, msp430-gdbproxy and friends aren’t free. Arrrrgh. I can feel my soul dissolving.
If I ignore the dissolving for now, it’s all amazing. So much debugging.
| Older Posts >> |
Site by Robert Spanton. ©2008