Since our robotics kit uses an I2C bus, it would be really handy for me to have a USB-to-I2C adapter. With the addition of a simple RJ11 adapter, I’d be able just plug in a module and start hacking on it without the annoying set-up times, that involve sorting out the Slug and power board combo. If Student Robotics had several of these adapters, then any member could just grab a module and start hacking on some code.
i2c-tiny-usb:
I’ve just come across Till Harbaum’s i2c-tiny-usb design. Rather surprisingly this uses a relatively cheap ATtiny45 Atmel AVR and nothing else. It bitbangs the USB protocol. Apparently, this works rather well. What’s even more exciting, is that there’s a kernel driver available for the i2c-tiny-usb. This makes it behave as a proper Linux i2c bus device, so interacting with it from software couldn’t be simpler. This board can be an I2C master with clock speeds of up to 50KHz.
OSIF
The Open Source InterFace (OSIF) is part of the OpenServo project, and I believe was designed by Barry Carter. Carter took the i2c-tiny-usb design, and adapted it to use an AVR with more pins, and upped the maximum I2C clock speed to 400KHz. Furthermore, the board has support for serial (I think UART), 6 GPIO lines and an ADC channel. Barry Carter sells the OSIF for £20 a board.
Carter also provides a kernel driver for the OSIF as well :-D
I bought an OSIF earlier today. I like the way that the OSIF uses work from two previous open hardware projects to create
I long for the day when I can do things like this:
Almost everybody enjoys one editor more than others – so why don’t we embed them in all text-areas?
My editor-of-choice is EMACS, and I’d really like to be able to use all of it’s features in all of the text-boxes and text-areas that I experience whilst browsing. EMACS multi-tty support would be particularly cool combined with this (in fact – it would almost certainly be necessary to make it viable!).
This guy agrees with me!
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 :-)
Spent a fair chunk of today sorting out Phil’s hard disk. Mac OS X had impolitely destroyed his partition table for him. I used TestDisk to recover it. There were a couple of issues, which meant that it took a little longer than it was “supposed” to.
It located a couple of adjacent ext3 partitions (Phil’s Fedora and Ubuntu roots) and generated some overlapping numbers for them. I had to manually edit the partition table using sfdisk to get it right. I particularly enjoyed the rollback-like features that sfdisk has (using -O and -I). I had to tell sfdisk to use sector units because it defaults to cylinders.
Then Phil gave me food. Excellent. Technical support for food.
Got a couple of management textbooks out from the library earlier. They’re really boring. Seem to be stating the obvious. Joy.
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).
I just downloaded the vala source. When I went to untar it I found that it was exactly two months ago (to within the hour) that I downloaded it:
[rob@prefect downloads]$ ls -lu vala-0.0.*.bz2 -rw-r--r-- 1 rob rob 632114 Jan 28 22:58 vala-0.0.5.tar.bz2 -rw-r--r-- 1 rob rob 691498 Mar 28 22:22 vala-0.0.8.tar.bz2 [rob@prefect downloads]$
Perhaps i’ll download the source again in two months time.
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.
Getting python onto the gumstix requires some work. By selecting python, the file system goes from 4 Mb (4131692 bytes to be exact) to 11Mb (11495444 bytes). That’s OK for the 16Mb gumstix boxes, but seems a little wasteful. After close inspection with the help of baobab, I find that a lot of it’s taken up by the python libraries:
[rob@prefect bin]$ pkg-config
PPPPPPPPPPPPPPPPPPPPPPIIIIIIIIIIIIIIIIIIIEEEEEEEEEEEEEEEEES
[rob@prefect bin]$
Since a couple of days ago, when I wrote about the kernel patches that I generated to get the UIF working, I have had a response on the mspgcc-users mailing list. The problem has already been fixed in 2.6.20, so my patches aren’t required.
The reason that I previously thought that the fix hadn’t found its way into the kernel was that it had been fixed in a different, and better way – thus the code changes I was looking for weren’t there. The fix that’s in the kernel is a much more sane approach than the method I copied off the mspgcc-users mailing list. So I’m now running 2.6.20, and the UIF (and presumably the EZ430 – I don’t have that here at the moment) works fine.
One thing that may slightly irritate people when first installing the UIF is that you need to add a rule to udev. This rule is: (edit: you probably don’t want to use the rule below now – see further below)
SUBSYSTEM=="usb_device" ACTION=="add" SYSFS{product}=="MSP-FET430UIF JTAG Tool" \ SYSFS{bNumConfigurations}=="2" \ SYSFS{bConfigurationValue}=="1" \ RUN+="/bin/sh -c 'echo 2 > /sys%p/device/bConfigurationValue'"
And then it works (remember to reload udev rules with “udevcontrol reload_rules
“). I’m not 100% sure what it does, but from looking at the rule and driver code, it would seem that the TI USB->UART chip in the debugger can has more than one configuration, and that affects what firmware gets loaded into the USB->UART chip. The udev rule associates the device description string (“MSP-FET430UIF JTAG Tool”) with the correct config value (2).
Edit: Things have changed in udev since I wrote this post. The rule I now use is:
SUBSYSTEM=="usb" ACTION=="add" ATTR{product}=="MSP-FET430UIF JTAG Tool" \ ATTR{bNumConfigurations}=="2" \ RUN+="/bin/sh -c 'echo 2 > /sys%p/bConfigurationValue'"
Edit (27/03/2008): Things have changed even more. Now I use this rule (with udev 118):
SUBSYSTEM=="usb", ACTION=="add", ATTR{product}=="MSP-FET430UIF JTAG Tool", \ ATTR{bNumConfigurations}=="2", ATTR{bConfigurationValue}="2"
<< Newer Posts | Older Posts >> |
Site by Rob Gilton. © 2008 - 2019