Home
The title being a reference to an old joke about hubris and the difficulty in bootstrapping a complex system.
Anyway. At times, when I have the time, I do a little bit of embedded electronics, using the Atmel AVR. Since I'm an embedded-systems engineer, that might be considered a bit of a busman's holiday, but the AVR is sufficiently different from most of the platforms that I use at work to be a welcome break. The Arduino, while seemingly a popular platform for AVR experimentation, is a bit too simplistic for me: the peripherals are already assigned, you write code for it in a language a little too close to BASIC for my liking, and the weird I/O pin design on the "standard" Arduino boards puts me off. Who designs an open-source embedded electronics development board that's deliberately incompatible with standard prototyping tools? Denied. Instead, I use an AVR development board from Sparkfun, an AVR programmer from adafruit, and the GNU C toolchain and crosscompiler: it's a bit more verbose, but much more flexible,
The hardware tools? Lovely. Customisable, flexible, etc. The toolchain? Not bad. Installing the GNU toolchain can be a bit tricky, so I've run off a set of scripts that semi-automate the install. These are SlackBuild scripts, and when run correctly they generate Slackware packages configured for your system. If you're not on a Slackware, the scripts are quite readable, and if you just borrow their configure lines, then make and make install as usual, you should be fine. All of these packages drop their installations into /usr/local, to keep them separate from the main system toolchain.
IMPORTANT: Make sure /usr/local is in your PATH when you're building these packages, and that you build and install them in order, or else one or more will probably fail.
With those tools installed, you should have a complete AVR toolchain. To test it, download and build the following trivial project. It's designed for the Sparkfun 40-pin AVR development board, but will run on any AVR board with a little modification (the intent here is to demonstrate the toolchain and the Makefile, not the simplistic C code).
I hope the above is useful to somebody. For the most part, I'm just storing these scripts here so I can find them easily next time I need to install the toolchain somewhere, but if anyone else has a use for them, I'd like to hear about it. All the scripts above are in the public domain, as is the trivial LED test. Have fun!
Tonight, I went to BuildBrighton, an informal hackerspace being run in a coworking space in the centre of Brighton. There were some interesting people there, and varying levels of technical ability: some beginners building kits, others (more experienced) assembling full-custom robots and sensor platforms. Interesting night. I'll probably go back, though I don't know if it'll be next week. It's nice to see that Brighton does have a hardware-geek population, even if we seem to be fairly stealthy.
It amuses me to note that almost all of those present were either graduates from or worked at Sussex University.
Well, that was an interesting little voyage through the innards of a complex piece of hardware. As I said back on the 28th of July (eek, a while ago), I can't seem to find the memory location of the Ethernet chip on my development kit (the Decomsys/Elektrobit Node
The Elektrobit help department were ... well, unhelpful, but it's not necessarily their fault: this is an old bit of kit, on the verge of going out of support, so I don't expect too much. Still, they gave me an idea of how to proceed, and I started to wield u-boot's 'md' with abandon. u-boot being the bootloader the dev-kit uses to start up, and md being the 'memory dump' command, allowing me to print the contents of a given memory address to screen, I went on a little sojourn through the machine's IO 'memory' (memory-mapped I/O system, which makes the next bit easier than it would otherwise be). Having written out approximately what I expected to find (a set of 16 contiguous 16-bit registers in memory, with the default startup values from the datasheet, I spiralled out from the area where they should be, looking high and low (higher and lower in memory, in any case). And there they abruptly were, offset from the location in the documentation by 0x300. 0x300 is a rather odd offset, but I assume all the locations were shifted up to accomodate an interrupt table or a new or expanded peripheral or something at some point... Why the documentation wasn't updated is another question entirely. Still. Using the correct base address of 0x42000300 instead of 0x42000000 as in the data sheet, the Ethernet chip kicks straight into life, and the code that wasn't working at all with the old base address suddenly wakes up and starts sending frames. Granted they're a bit malformed, but it's nice to see I got all the memory management and device initialisation stanzas correct despite not getting any kind of useful response from the hardware.
Having the u-boot source code to work from probably has something to do with that. Open-source makes my life easier, again.
Well, it was a busy few weeks. I'm writing this entry in retrospect from November 2009, two months afer the events described, so this won't be terribly detailed. Still, a peculiarity of my blogging software means I can't delete this entry (placeholder though it was for something I never got around to writing), so I may as well make use of it.
In this entry, I helped someone to move house. A couple of weeks ago there was a housewarming, to which I was invited. It was a good evening, at which there was a good mix of people I had and hadn't met before, and at which we decided it was just as appropriate for men to sew as it was for women to work wood, and the apparent views of the general populace be damned.
One particularly interesting conversation amidst the tangle of chat was related to Laban notation. It is one of my core beliefs that everything in the world can be encoded, represented, written down if you can just find the right language to describe it. Music, obviously, is one of them. Dance is much less obvious, but that's essentially what Laban Notation is all about. It's a domain-specific restricted vocabulary that allows the user to describe not just the position of limbs and the shape of the body, but the strength, control and timing of each intervening movement. There are associated symbols and suchlike. Unfortunately, there also seem to be several factions, each practicing a variation on the base notation, which complicates matters somewhat, but I suppose no-one and nothing is perfect.
In other news, I tried to teach one of my other friends to ride a bicycle. This... well, it didn't work out quite as planned. Between my teaching, my jalopy of a bicycle and her inexperience, we successfully failed to learn anything. So it goes - maybe we'll try again some day.
Finally, a little game of RISK. Not so remarkable in and of itself, but it was played against three people I haven't seen in years: friends from high school. One's my mother's neighbour, and one adminsters the DNS for this site. I have to admit, given how we started from more or less the same place, seeing how their lives have developed along different paths from mine is ... interesting. Two of us are married, we all work in tech fields, but there's no way you could mistake one's life for another.
The world turns beneath us, and we all of us change to keep up. 'tis the way of things.
I love it when this sort of thing happens. Shenzhen is a HUGE industrial district in China, home to a large number of electronics manufacturers and fabrication plants. There is a 'blog' of sorts called Hack a Day, who try to act as a showcase of new and interesting hacks that people have created, remixing machinery in their local environment, building a web-server that fits in a matchbox, or whatever. Their quality can be a bit variable, in that some of their 'hacks' are rather obvious or contrived, but I guess we all had to start somewhere. Anyway, Hack a Day have created a few hacks in their own right, one of which is a rather handy little bus analyzer called the Bus Pirate.
Hack a Day made a deal with a company in Shenzhen to make Bus Pirates, and sell them to hobbyists who read Hack a Day. They're currently sold out.
They're currently sold out BECAUSE the Bus Pirate manufacturing line has completely exhausted Shenzhen's stock of PIC24FJ64 chips. There are Bus Pirates sitting around that are complete, save for this small but vital chip. That's ... a non-trivial number of chips.
Yay, Internet, for allowing this kind of thing to happen. Across the world, thousands of hobbyists have decided they wanted a Bus Pirate, and accidentally depleted a world industrial centre of a fairly common part.