RC5mX |
|
|---|---|
| RC5mx is no longer being developed or maintained,
because I no longer use a Psion (it broke, and is no longer
manufactured). This page is still here for interest, in case it helps anyone. Also, the contents of my development directory last time I backed it up are available in a zip file here. If it's helpful, you're welcome to it. If it makes you a fortune, well done. | |
|
|
RC5mX lets a Psion Series 5mx palmtop computer talk to a Lego Mindstorms RCX programmable brick. It will transfer firmware onto the brick and lets you send and receive ASCII text (either direct from the keyboard or from text files). This isn't all that useful for the standard mindstorms setup, but is very handy if your firmware of choice is pbFORTH. It does not use the psion's IR capability. I don't know of a way to send arbitrary binary data out the port - there's very little control of the IR port on a series 5 machine. You need to connect the lego serial tower to your psion via. the standard serial cable. It might work for a Series 5, too, but I don't have one, so can't test it. (If anyone wants to give me one, it'd help me support it ... no, I thought not.) RC5mX is currently free. When it's good enough that I'd pay for it, it might change to shareware or some such. Till then, all I ask for is feedback. RC5mX is developmental software. I confidently expect it to contain more 'undocumented features' than Microsoft Office. Proceed at your own risk. |
RC5mX was written so that a Psion 5mx could talk to a Lego RCX. The main
reason I want to do this is so that I can program the RCX in a
hammock. While a laptop PC would be a partial solution, they're quite
bulky and weighty and not suited (in my experience) to prolonged
hammock operation. The psion, however, can be operated while lying on
your back, holding the
unit above your head with one hand while typing with the other.
By putting pbFORTH on the RCX, in principle all that is needed to program it is a terminal emulator, and the psion has a terminal emulator ('Comms') built in.
However, the built-in Comms app doesn't like pbFORTH. It doesn't like the way pbFORTH does software handshaking for some reason, leading to frequent hangs. It's quite happy with handshaking turned off entirely, until you try and transmit a text file, at which point the RCX can't keep up, and the Comms app doesn't have the option to add end-of-line pauses in the data stream.
Furthermore, if your FORTH programming is a bit flaky (like mine), you frequently want to pull the batteries from the RCX, completely wiping its memory, and start again. At this point, you have to leave the hammock and find a PC that can transfer the firmware back into the brick.
RC5mX will transfer firmware to the brick, will let you interact with it by typing at the psion keyboard and will transfer plain text files (created on the psion with either the text editor or the Word application. Thus, you can remain in the hammock!
The current feature list includes:
These are all developmental. That means I'd like to know how you broke it and what you'd like it to do next, but I don't guarantee that it will do anything.
If you do download it, I'd quite like to know:
From the following table, you should get the latest numbered version, unless the description gives you a very good reason for going for an older one. Download the .zip file and unzip it to get a .sis. From Windows, while your psion is hooked up to your PC double-clicking on the .sis file should install the program.
Versionclick to download |
Dateof release |
DescriptionChanges, notes, intentions and speculation |
| 0.02.4 | 9 March 2002 | Wrote it and released it on an unsuspecting world. Currently it will transfer firmware, send typed input and transfer text files. |
| 0.03.1 | 16 March 2002 |
Superficially, no new features beyond what 2.1 does. However, I've
recoded the main activity loop so it now does proper asynchronous
reading of both keyboard and serial port. This means you miss fewer of
the RCX's responses (2.x versions are prone to missing responses
from the RCX which do not immediately follow transmissions).
Major change: it now has an icon! |
| 0.03.2 | 24 March 2002 | This improves the file transmission. Transferring from a text file to the RCX is now about 3 times faster, and does not rely on clumsy timeouts, which will hopefully make it more reliable too. |
| next | who knows | I don't anticipate anything further in the immediate future, since it now does all I currently want it to. However, if you have any suggestions, I'll be glad to hear them! |
When connected to a RCX, the program has four windows on screen.
Of the two large windows, the one on the left shows anything which has been sent out the serial port. For example, anything you type, or the contents of any text file transmitted. The window to the right shows anything coming into the serial port. The lego transmitter tower returns a copy of everything it gets from the psion, so this includes what you've sent. It acts as a manual check that what you wanted to send got received by the tower. The program tries to distinguish between tower responses and RCX responses, and uses a bold font for what it thinks are RCX responses. (Sometimes, however, it gets it wrong - but it's normally obvious when that's happened.)
The two smaller windows at the bottom of the screen show anything currently being typed or prepared but not yet sent anywhere, and some miscalaneous running commentary. In the shot above the user has typed "8 CUBED", but not yet hit enter to transmit it. The commentary tells you that the last key press was that with character code 68 - vital information! Some of this commentary is logged to a file, and this gives rise to the main 'gotcha':
Since the program is developmental, it generates lots of logging, to help mne if it doesn't work as expected. The activities logged are under user control, as shown in the above shot. Don't enable logging of all bytes if you're transferring firmware!
'All bytes' means every single one, including packet headers, and the interleaved inverse bytes in the standard lego packets. At the time of writing, pbFORTH firmware is around 9K. 9000 bytes of firmware translate to about 18700 bytes sent out the serial port, because of the packet format used by the RCX. Each byte gets echoed by the tower, so that's 37400 bytes. The RCX has something to say about each packet - that's another 300 or so bytes. There are some packets setting up the transmission, so say 38000 bytes logged.
The log format looks like this (you can find the log in C:/System/Apps/RC5mX/log.txt, it's just a plain text file):
13:53:59 - Send message to RCX 13:53:59 - "2 2 +" 13:53:59 - write 6 bytes to serial port 13:53:59 - Message sent: 13:53:59 - byte 1 of 6 = 0x32 = "2" 13:53:59 - byte 2 of 6 = 0x20 = " " 13:53:59 - byte 3 of 6 = 0x32 = "2" 13:53:59 - byte 4 of 6 = 0x20 = " " 13:53:59 - byte 5 of 6 = 0x2B = "+" 13:53:59 - byte 6 of 6 = 0x0D = [CR]
That is, there is at least 40 bytes of log for every byte sent or
received. For the firmware packets, it's 42 bytes minimum. That's a
grand
total of about 1600000 bytes to the logs for
9000 bytes sent to the RCX. Enabling 'all bytes' logging puts over 1.5 MB
into the log file for 9 kB into the RCX. It takes up lots of space
on the psion, and it also slows the transfer dramatically. You
probably don't want this.
back to Ian's contents page
back to www.astounding.org.uk top contents page
To comment on anything (please do) email ian@astounding.org.uk