Recently I’ve been playing around with my BeagleBoard to get the software situation sorted out for SR 2010 by the time our hardware freeze hits. I really don’t want another year of using slugs (NSLU2s).
I set up a development tree to contain our work, and I’ve written instructions on our wiki on how to get started with the SR BeagleBoard software situation. The Beagle information on our wiki pages might be useful to others outside SR as well.
The Beagle beats the NSLU2 hands down when it comes to computation. That’s not the only advantage that it has over our old friend. We had to manually hack up the NSLU2 in unpleasant ways before we could ship it:
Yes, we had to hack at the NSLU2s with a spoon.
We’re building a board that will sit above the Beagle that’ll make use of its expansion connector. The interconnect on SR robots uses I2C (my hopes for SR 2011 are currently set on RS485). The Beagle will master our bus. One thing that is a definite advantage of the Beagle over the NSLU2 is that the NSLU2’s I2C was bit-banged; we actually have access to a proper I2C peripheral this time.
The Beagle’s serial ports are a major advantage too. We could only access one serial port on the NSLU2, which meant we had to sacrifice serial console (imagine building a kit car then testing it by driving it blindfold) for it to talk to the radio module. The Beagle has at least 2 serial ports accessible, so there’ll be no misery there!
I’m quite surprised by the current state of the BeagleBoard community. It’s relatively young in comparison to the Gumstix community, but it already feels like there are many more people contributing to it. The kernel seems to be driving the board OK now (USB host has only just become functional in 2.6.29 for me), but there are still a fair number of extra bits and pieces that still need cleaning up. The most crucial one of these (for SR) is the configuration of the multiplexed pins connected to the expansion header.
So my current SR task is to get up to speed with the OMAP technical reference manual and brew up some patches that let us use I2C.
I’ve just around to uploading my photos from Student Robotics 2009. This means that I can tell everyone about the fantastic cake that Lou presented us with when we got home:
Thanks Lou :-D
It took us over 12 hours to set-up the Cube for the Student Robotics 2009 competition, and something like 3 to clear it up. Similarly, Lou spent much longer creating this cake than it took to eat. Good things take longer to create than to destroy!
Have a look through those photos for a picture of Chris with an amusing hat. I thought I should make that public before the photos of me wearing it got out…
I present you with the Student Robotics Competition 2009 in one minute and eighteen seconds:
Can’t see the video? Try here.
Get the video in Ogg Theora here.
Unfortunately something went wrong with the timelapse set-up, and so we don’t have the first few hours of arena construction :-( Oh yea, I shortened the night-time section of the video, because it was somewhere around a minute long.
The second Student Robotics competition happened on Sunday. I thoroughly enjoyed it, and I hope all the students involved enjoyed it too.
We have a meeting later today in which there will be much discussion about what will be happening for next year. I’m writing this blog post so that I can get my thoughts down about what has happened without them being too tainted by that discussion.
Firstly, I think the electronics kit was in a much better shape than last year. Last year, there were a couple of fundamental issues that didn’t get fixed at the competition. There were problems with controlling servos, and there were fundamental issues with reading inputs. This year there weren’t any bugs that seriously blocked the teams’ progress.
We found two bugs during the event — neither of which was preventing the teams from actually progressing with their robots. The bug was that the serial lines connecting the slugs to their radios were swapped over. The circumstances leading up to this situation were rather amusing. The prototype of the board that connected the slug to the radio (the “power board”) had its serial lines accidentally crossed. In order to continue development, Tom had, quite reasonably, switched the serial lines over on his slug “umbilical”. Unfortunately, that modded slug got mixed in with some others and ended up being used as a template for modding all the other slugs.
Anyway, this required a really minor change to all robots. Tom and Jeff raced through modifying all the slugs at the competition in around 45 minutes. Luckily this didn’t delay any matches, as teams were still frantically tinkering with their robots.
The second bug that happened became known as the “one second” bug. We shipped out a firmware update to the power board. This update contained some changes that were required to make the radio work. Unfortunately, it hadn’t been thoroughly tested enough and contained a bug that meant the power delivered to the motors would be switched off after one second when in debug mode (teams can fake a radio “start” signal by pressing a button on the power board). Tom patched this quickly and we got it out in an update.
That second bug affected people more than the first, but I don’t think it resulted in too much pain.
We were let down by the internet connection to the event. Last year, I’d routed all traffic through the wireless on my laptop; I don’t recall any problems with it. I had naively assumed that it would be the same this year. Unfortunately there were frequent wireless drop-outs, which resulted in frequent misery on my part, as many of the competition features relied on it.
There were loads of “blue shirts” (volunteer helpers) who attended the competition, and I believe that every single one of them got thoroughly involved with what was going on. That was awesome. However, I’d prefer to see some of that enthusiasm spread out over the rest of the year!
I’m looking forward to Student Robotics 2010. I want it to be bigger, better and more insane. If you are an engineering student or engineer and you’re reading this, please do get involved. Get in contact with us, and we’ll go from there. You’ll need to find some sixth-form students that you can guide through the competition, so start looking for schools and colleges in your area. You don’t have to be from the University of Southampton.
I’ve been hacking away at fetproxy for the past couple of days. I’m now at this stage:
[rob@prefect fetproxy]$ msp430-gdb -n GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=msp430". (gdb) target remote localhost:2000 Remote debugging using localhost:2000 0x0000f800 in ?? () (gdb) info r pc/r0: f800 sp/r1: 7a00 sr/r2: 0000 r3: 0000 fp/r4: 7a00 r5: ff00 r6: 7f00 r7: ff00 r8: ff00 r9: ff00 r10: bf00 r11: f700 r12: bf00 r13: ff00 r14: fd00 r15: 0000 (gdb)
That’s where it’s at right now on my machine. gdb can now read the registers of the target device. The “continue” command’s next…
I’ve spent some time lately sorting out a utility to tile Gerber files. I’ve wanted a utility to do this for a while, but I couldn’t find a utility that would work for me. Then I came across libgerbv, which is the backend library of gerbv, a Gerber viewer.
Since then, I’ve submitted two patches to gerbv, which were both accepted really quickly (yay!).
I had some other issues with libgerbv that I have fixed locally, and I’m working on cleaning up my patch for submission. It needs to touch some more things than my last two, so it’ll take me a little longer. I’ll be talking about that more soon when it’s compatible with gerbv CVS (CVS == sneeze).
It was only after I’d written most of the utility and come across the first libgerbv bug that I discovered that gerbv can do Gerber file tiling when invoked from the command line. My utility has a slightly different than gerbv’s. Anyway, more on that later.
Spirals
I’ve also been working on making a utility to make spirals on PCBs. It’s available here. If you’re interested, you can build it like so:
git clone git://gitorious.org/pcb-spiral/mainline.git pcb-spiral cd pcb-spiral git submodule init git submodule update make
Maybe it’ll be useful to someone else too…
I just had a very quick look into what could be done to fix the FET430 UIF firmware loading issue I wrote about before. The issue looks like it was fixed in this commit. That’s in Linux 2.6.29, which was released 6 days ago.
No work for me to do there then…
Just under 3 months ago, Tom and I reverse engineered the protocol to talk to the TI FET430UIF MSP430 debugger.
We weren’t confident that we could release the source without legal repercussions. We couldn’t really afford to pay a solicitor to find out what our legal position was (I got a quote from one of £600). We gave the problem some thought.
After many discussions about what we could do, we decided to send a letter to TI to ask them whether they’d mind us releasing our code as open source. That letter is here on the right. Click on it to be able to read it. (You may notice that I’ve blacked out my address.)
Today I got a phone call from Thomas Mitnacht, who is Texas Instrument’s Development Tools Manager for MSP430 Microcontrollers and is based in Munich. After I’d explained to him why we’d reverse engineered the protocol, he said that he was happy for it to be released as open source. This is amazing. Thank you Thomas Mitnacht and TI!. I was quite surprised how quickly TI responded to this request.
He said he’d prefer for it to be under LGPL or GPL version 2 so that they could use the code, as apparently they’re not sure yet about how to deal with the patent requirements that GPLv3 has. Personally, I think the patent clauses in GPLv3 are useful and will help to make our software more free. However, given that TI could have given us a much harder time about this, I’m willing to release it under version 2.
Thomas also informed me about some important things to do with the MSP430 debugger. They’re not able to release the source code of their FET430 interface library at the moment. I think this is because of some licensing issues they have with that code. They’re working on a replacement library that will be open source and available at the end of this year. Sounds good. I’m looking forward to it.
I’m extremely happy to release the source code that Tom and I hacked together at 25C3. It’s a bit dirty at the moment, but now that we can have it out in the open we’ll definitely be putting more work into it.
Quit rambling, just give me the code!
I’ve put the code up in a git repository on gitorious. You can grab it like this:
git clone git://gitorious.org/fetproxy/mainline.git fetproxy
Several people have emailed me over the last couple of months asking me for the source. I’ve had to give them all a bit of a disappointing reply, which was “sorry, please wait”. If you’re one of those people, I hope that you understood.
P.S. Further good news: My msp430-gcc Fedora package passed its review a couple of days ago. It’ll hopefully be shipping within the next week.
I’d really like to get a development community around the Formica robots. I really enjoyed seeing Toshaan and colleagues build upon and develop the Formica designs for themselves. From the response we got from Jeff’s 25C3 talk, we know that there are quite a few people interested in building these tiny robots.
So we’ve set up formica.srobo.org; a wiki to act as a hub for Formica robot development. We would like to invite everyone who’s involved in Formica related projects to get involved with it and use it as a repository for information. This site is generously hosted by Student Robotics. Our thanks go to everyone in SR for that.
We’ve also opened up the mailing list that we used whilst the project was part of our degree. We hope this will become a place for people to publicly discuss projects relating to the Formica robots.
In moving to formica.srobo.org, I also transmogrified our subversion repository into a git repository. Details of this can be found on the software page of the Formica wiki.
Klaus and I spent several hours on Friday getting his new monitor to work with his slightly aged graphics card. His new monitor is a Samsung 2048×1152 LCD/TFT.
The G550 specs claim that it supports this resolution through the VGA output. Unfortunately, somewhere along the line, the DDC data was being ignored. The display specs stated that it supported a pixel clock up to 157 MHz, but Xorg told us otherwise and would limit it to 140 MHz.
So the first thing to do was to get it to ignore the DDC data, as this was definitely wrong. The “NoDDC” option in xorg.conf does this:
Section "Device"
...
Option "NoDDC"
...
EndSection
After much testing of various modelines and configuration, we discovered the undocumented “ReducedBlanking” option that allows higher resolutions to be sent over VGA connections with a short blanking period between lines. Modern TFT displays support a reduced blanking interval, as they don’t have to allow time for an electron beam to move back to the other side of the screen.
This did make me wonder whether in the days of CRTs anyone had thought of alternately reversing the direction of each horizontal line supplied through a VGA cable. I think this would allow for a reduced blanking period, higher resolution or reduced pixel clock. I guess CRTs never got up to the resolutions where this was an issue.
The trick is to put this in the “Monitor” section of your xorg.conf:
Section "Monitor"
...
Option "ReducedBlanking"
...
EndSection
This isn’t mentioned in the xorg.conf man page. It should be!
Once we’d found that option and used Erich Boleyn’s CVT Timings Program to generate the required ModeLine with a reduced blanking time, the monitor and graphics card worked fine.
The next challenge was getting a second monitor to work on DVI output of the graphics card. Unfortunately we came across a bug that would have required us to rebuild the mga driver from source. After spending many hours getting the first monitor to work, this was too much for us to bear for one day.
There is a patch in the Xorg bug tracker that will hopefully make it’s way into a release of the mga driver in the future (unfortunately I can’t remember the bug details). Then Klaus’ monitors will both work.
| Older Posts >> |
Site by Robert Spanton. ©2008