We’ve finally got around to releasing the designs and code for the Formica robots. You can find a technical report over at Jeff’s website Warranty Void if Removed. The hardware designs are under a CC license, and we’ve GPL’ed the firmware.
I’ve made the firmware available here. To build this, you’ll need to have an install of mspgcc that’s been built (and probably patched) to compile for the MSP430F2254. If you’re using Fedora 9, then you should be able to use my mspgcc RPMs.
Compilation
Compiling it is as should be as simple as running “make”:
[rob@zarniwoop formica-fw-r468]$ make ./freq.py 500 3500 3 > freq.c cp .freq.h freq.h sed -i -e "s/_NFREQ/`echo "$(((1 << 3) + 2))"`/" freq.h sed -i -e "s/_NBITS/3/" freq.h sed -i -e "s/_MIN_PERIOD/500/" freq.h sed -i -e "s/_MAX_PERIOD/3500/" freq.h sed -i -e "s/_SYMBOLS_PER_BYTE/`./.sym_per_bit.py 3`/" freq.h curl -s http://users.ecs.soton.ac.uk/rds204/formica/rev.php > .fw_ver msp430-gcc -o main -mmcu=msp430x2254 -g -Wall -Os -mendup-at=main -DRAND_WALK_SPEED=3 -DFW_VER=`cat .fw_ver` main.c ir-rx.c freq.c net-rx.c opamp-1.c ir-tx.c ir-tx-data.c net-tx.c adc10.c random.c motor.c virus.c smbus_pec.c battery.c ir.c food.c bearing.c flash.c behav/braitenberg.c time.c behav/parking.c behav/watchdog.c -Wl,-T,lkr/msp430x2254-lower.x Firmware revision 485 msp430-gcc -o main-top -mmcu=msp430x2254 -g -Wall -Os -mendup-at=main -DRAND_WALK_SPEED=3 -DFW_VER=`cat .fw_ver` main.c ir-rx.c freq.c net-rx.c opamp-1.c ir-tx.c ir-tx-data.c net-tx.c adc10.c random.c motor.c virus.c smbus_pec.c battery.c ir.c food.c bearing.c flash.c behav/braitenberg.c time.c behav/parking.c behav/watchdog.c -Wl,-T,lkr/msp430x2254-upper.x Firmware revision 485 cp -f freq.h .freq.h.win cp -f freq.c .freq.c.win [rob@zarniwoop formica-fw-r468]$
This will generate two binaries: main and main-top. These contain the same code but they are linked into different regions of the flash. You can load either one of them into the robot’s MSP430. However, when you start working on getting them to flash each other over IR, you’ll need to make sure that you’ve got the right ones loaded.
You may notice that there’s a curl in that make output. This grabs a firmware version number from the web. Obviously you can change the URL this grabs it from, but feel free to use the one that I’ve set up in my ECS account.
p.s. I should add that none of the stuff from the Alife conference has involved the title “Formica” or our logo, which was a little dissapointing. So, let me point out that this is the same project as in all of these news stories.
I got fed up with having to run through the build procedure for mspgcc with others. I think I must have done it four times now. So, I’ve packaged it into some RPMs that I’ve built for Fedora 9. I’m trying to get them into the Fedora repositories, but for now you can download them from here. These include the patches for the msp430f2xx, and the other patches that the mspgcc guys recommend.
I haven’t done GDB yet, but hope to over the next few days.
I spent today working on a bug in the driver for the TI UIF MSP430 programmer. It stopped initialising properly in 2.6.24, but it worked in 2.6.23. I did a git-bisect between those versions to find the commit that induced the fault. I narrowed the search a bit by telling git-bisect to work on commits only in drivers/usb/, as I hypothesized that the bug was induced somewhere in there.
About 10 builds and 20 reboots later, I found the commit in which the problem was happening, and then read some stuff about USB etc (the LWN device drivers book proved invaluable yet again) and subsequently generated a patch. I’ve sent it to (what I think are) the right places.
If you can’t wait for the next kernel release (if it passes review…), then you can rebuild the ti_usb_3410_5052 module by downloading this tarball, untarring it and then running “make” in the resulting directory, and then “make install” as root. You will need enough of your kernel’s sources hanging around to do this. In Fedora, these are provided in the kernel-devel package.
Update (5th April ‘08): The patch has made its way into Linus’s tree, so I think it’ll be in 2.6.25.
Dear people,
Please find git mirrors of the mspgcc CVS repository modules here. They are updated every 2 hours.
The time for these to checkout is much faster than from CVS.
Yours sincerely,
Mr. Rob
This makes me feel very happy:
Breakpoint 1, sd_state_run (in_byte=201 '', ob=0x272 "z\002\223")
at sd.c:366
366 r_received = FALSE;
(gdb) print r_err
$1 = FALSE
(gdb) print/x csd
$3 = {0xaa, 0x55, 0x0, 0x0, 0x0}
(gdb)
r_err is a variable which states whether the SD card reported an error in its response to the read command. The csd array stores 5 of the bytes read from the SD card. The byte ordering is the wrong way around, but other than that it’s all fine.
After spending several millennia attempting to discover what was causing my MSP430 to reset randomly, I realised that it was because I hadn’t got any RAM left. I think that the bss/text sections began to overlap with the stack - which wasn’t pretty! I had previously been attempting to store 64 bytes of data read from the SD card in an array. This meant that there were 114 bytes of the 128 bytes of memory in use, leaving only 14 bytes for the stack.
Reducing this array to 5 bytes (I’m not that interested in buffering more than 1 byte from the SD card) solved all problems. Now I can read data! w00t.
- 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.
I just wrote some code for the MSP430F2011/2/3 to control two H-bridges connected to a bipolar stepper motor. Available in git form here:
git clone http://users.ecs.soton.ac.uk/rds204/git/stepper-driver.git
Takes a STEP and a DIRECTION signal - ready for connecting to a parallel port for use with EMC.
As for what it’s driving - it’s amazing. More on that later!
Hmmm. Two identical situations, and no idea about why one’s different to the other… I know, I’ll take a dump of SFRs in both and then diff the result…
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"
I just finished sorting out using the toolchain for the PWM board. Problem with the toolchain that I had was that the binutils I had installed (2.16) doesn’t support the MSP430F2013. After some searching around I found the patch I needed to apply to binutils in mspgcc CVS - and then managed to find a post about it on the mailing list.
Once the toolchain was built I ran a simple program that toggled the output pins continuously:
#include <msp430x20x3.h>
static int i = 0;
int main( void )
{
WDTCTL = WDTHOLD | WDTPW;
P1SEL = 0;
P1DIR = 0xFF;
while(1)
{
P1OUT ^= 0xFF;
}
}
The program ran correctly, and the level translation between the MSP430 and the servo outputs worked nicely. Good. Only motor controller to go now, and then we’ll be living in a softwarey world. Ah yes - the TI USB UIF interface seems to be working perfectly in spy-bi-wire mode :-)
| Older Posts >> |
Site by Robert Spanton. ©2008