peteg's blog 2005-11-12.autumn

Quick hack to fix the slow downloads: somehow the leading 0xf1 byte of a response packet from the RCX is getting lost quite often, so I simply make it seem that if the host gets a packet from the RCX then that packet starts with that byte. Things are a lot faster and more reliable now. The tarball has been updated.

Using the light sensor and a circular 2x2 plate to simulate a rotation sensor is a bit tricky, not the least because the (active) light sensor readings don't seem to vary much - 50 to 54 for me. Secondly there's the question of sampling frequency, and then relating the number of events to the quantity we're really interested in (distance or angle in the case of the turtle). Oh well, I'll see what I can do.

From the point of view of interesting programming, the turtle isn't such a great starting point. The robot is severely limited in the amount of concurrent activity it can engage in; I think one could raise or lower the pen while rotating or moving, but this is hardly useful. It seems to me that the cleverer the mechanism the more limited the concurrency possibilities.

Brown has an interesting course with some labs that help with getting started. Another way to get into interesting-program-land is to sophisticate the task.

As always, I spoke a bit too soon. My hacked version of dll is pretty damn unreliable. (I began writing a control program for the turtle, see. That bit's easier than I thought.) Oh well, another problem for another day.

Wow, things start working. I ripped Markus Strickler's mostly-beautiful osx_usb.{ch} out of the aforementioned lejOS tree and started hacking it into brickOS's mangled dll (dynamic linker and loader). The code for all these sorts of tools starts out as a minor variant of Kekoa Proudfoot's seminal work, is extended with various hacks to get things working under Windows, Linux with that new USB driver, on Solaris, etc. etc. and ends in Mac OS X users tearing their hair out. The code started out as a proof-of-concept and is now more-or-less unmaintainable.

Well, that's my excuse for ungently hacking out the bits I didn't need (viz the old serial device mechanisms, and Windows and Linux support). If the brickOS website looked less dead I may have tried to do it tidily and submitted a patch. As it is, I'm just going to package it up to save the hair of my fellow Mac OS X users. Some notes:

Things are slow; quad-rate download is unsupported.
My RCX had a default LNP (brickOS's "Lego™ Network Protocol") address of 2. You need to specify this when using dll. The following worked for me:
```
dll -v -p1 ../demo/helloworld.lx --rcxaddr=2
```
You can find the address by using the View button: the address is the number that comes up after Addr when you cycle through it, ignoring the final '0'. You can set it by pressing Prgm when it is displayed.

The tools are available here. They are imperfect but enough to get started. I may hack them a bit further into shape in the future, and if you do please send me the results.

With the confidence that I can now get my programs onto the RCX I started building the Logo turtle featured in the Syngress 10 Cool Lego Mindstorms Robotics Invention System 2 Projects book. It's a mechanical marvel. I wonder if it's capable of drawing a smooth curve.

Wow, some success. Back at my parents' place for the weekend, I had access to a Windows machine. This allowed me to get the official Lego™ firmware onto the RCX, and then, well! The wonders one can work with known-good hardware.

The only Mac OS X 10.4.3 / USB Lego tower firmware downloader that worked for me is packaged with leJOS. Indeed, if I was more charitable I would try out their whole system, the core of which is an implementation of most of the interpreter-part of a JVM on the RCX, a nice piece of engineering. That's more than I hope I'll need, but we'll see.

The lejosfirmdl program happily downloaded the brickOS kernel to the RCX for me. I have a minorly hacked version of it that I can supply on request.

Once the brickOS firmware is on the RCX it doesn't take too kindly to attempts to replace it. Apparently one must ask it to commit hara-kiri, leaving only the Lego™ ROM intact and in charge. To quote the aging FAQ:

Because of a limitation in the Lego™ firmware, firmdl3 cannot delete brickOS. Instead, before downloading the new firmware, you must first stop the old brickOS program, and then hold down the Prgm button while hitting the On/Off switch. This will delete the old brickOS firmware, allowing a new download.

Next step: getting a brickOS program onto the RCX. I observe at this point that the linker and program downloader are fused together, and so I cannot just hope that NQC or leJOS will save my bacon this time.

Lesson of the week: don't be heroic. There's a pre-packaged GCC 3.2.2 and binutils 2.13.2.1 available, linked from this rather intriguing summer class at Lund (hello Calle!). Download and install. Trust me, it's much easier than compiling things yourself.

Compiling brickOS itself is still a bit fiddly. I did the following to a virgin brickOS 0.9.0 tree:

util/firmdl/rcx_comm.c fails to compile. I later found the firmdl3 program included with brickOS to be useless, so the quickest "get the compile to go through" hack is just to add #define linux near the top of that file.
blinks that seems to do it.

The tricky part is talking to the USB tower. Almost all the non-Lego™ Lego™ Mindstorms projects appear to have stalled right about when the USB tower became the only thing one could buy. I take that to mean that the people who got all excited in 1998 or so and did all this wonderful work never bothered with the newer RCXs, and that it seemed to have lost its geek chic by 2001 (excepting the Linux afficiandos, of course, who appear to think that this device is worth a kernel driver... in 2.6.something... say no more.).

Picked up the Lego™ Mindstorms I ordered from Dick Smith Electronics from the post office yesterday. (This courier company thoughtfully leaves one's package at the post office if they can't deliver it.)

The first step, beyond opening the box and aahing over all the bits in the kit, is to get a decent development environment working on Mac OS X - and that means GCC, of course. I tried 4.0.2 with little joy, and from a fair bit of googling I got the impression that 3.3.x is a goer.

Some details: we need a cross-compiler to GCC-target h8300-hitachi-hms. The Mac OS X internationalisation appears to cause GCC some grief, so I'm just going to have to read American English for a while (shock horror). Using the various Fink and DarwinPorts tools lying about, and after a painless binutils v2.16.1 installation, the following worked for me:

% tar xfj gcc-3.3.6.tar.bz2
% mkdir build-gcc
% cd build-gcc
% ../gcc-3.3.6/configure --target=h8300-hitachi-hms
    --prefix=/opt/local/crossgcc
    --exec-prefix=/opt/local/crossgcc/h8300-hitachi-hms --enable-target-optspace
    --enable-languages="c" --disable-nls
% make

You can change that to --enable-languages="c c++" if you like that sort of thing.

My choice of putting everything in /opt/local rather than /usr/local confuses brickOS's (ad-hoc, not autoconfiscated) configure script. The obvious change in that script makes it work.

Next step: build brickOS.