A Native Transterpreter for the LEGO MindStorms RCX CO620 Final Year Research Project Jon Simpson Computing Laboratory, University of Kent [email protected] The Big Three • Who? • Jon Simpson (undergraduate) • What? • A small and maximally concurrent occam-π operating environment for the LEGO MindStorms RCX robotics platform. • Why? • Interested in the use of concurrency for robotics. • Previously explored methodologies for designing concurrent robotics programs with occam-π on a large mobile robot platform. • J. Simpson, C. L. Jacobsen, and M. C. Jadud. Mobile Robot Control: #e Subsumption Architecture and occam-pi. In F. R. M. Barnes, J. M. Kerridge, and P. H. Welch, editors, Communicating Process Architectures 2006, pages 225–236. IOS Press, September 2006. • To gain experience with low-level hardware programming and C. • Get more involved with the Transterpreter project. 2 LEGO MindStorms RCX • 16 MHz, 16-bit Hitachi H8/300 CPU • 16kB of ROM • 32kB of RAM • RCX ‘executive’ loads into RAM from ROM at power on. • Once uploaded, programs and executive share space in RAM. • 3 input ports with A/D conversion • 3 output ports • Speaker • Timers • Infra-red port (used for program upload) 3 The Transterpreter (TVM) • A portable interpreter for the extended Transputer instruction set (occam-π) written in ANSI C. [1] • Support for: • Mac OS X (PowerPC, Intel) • Linux (x86, MIPS) • Windows (x86) • LEGO MindStorms (H8/300) • Existing support removed in late 2004, due to growing problems with memory space on the LEGO & keeping feature parity with the main version of the interpreter for all other platforms. • A renewed LEGO port of the TVM that solves these problems would facilitate continued concurrent robotics explorations with occam-π. 4 Space, the final frontier ROM 2k (RCX executive) ROM (16k) RAM (32k) 5 Space, the final frontier ROM ROM 2k use (RCX executive) (4k) ROM (16k) RAM (32k) 6 Space, the final frontier ROM ROM BrickOS 2k use (RCX executive) (12k) (4k) ROM (16k) RAM (32k) 7 Space, the final frontier ROM ROM BrickOS TVM 2k use (RCX executive) (12k) (4k) (8k) ROM (16k) RAM (32k) 8 Space, the final frontier ROM ROM BrickOS TVM Byte 2k use code (RCX executive) (12k) (4k) (8k) (3k) ROM (16k) RAM (32k) 9 Space, the final frontier ROM ROM BrickOS TVM Byte Free 2k use code (RCX executive) (12k) (4k) (8k) (3k) (3k) ROM (16k) RAM (32k) 10 The Problems of Space • #e small amount of available memory restricts the kinds of programs that can be written. • #e original port of the TVM supported occam 2.1, but the dynamism of occam-π [3] is desired. • #e dynamism introduced into occam-π is of limited use given so little free memory. • Free memory is reduced yet further by adding and including support for these extended π features of the language. 11 VM Growth • #e TVM is cross-platform and has many di$erent target applications (from embedded platforms, all the way up to MPI clustering) • As functionality has been added to cater for these applications, and been integrated into the main line of development, the interpreter size has increased. • Having to maintain a separate, limited branch of the VM for the LEGO would not be ideal. • Some of these new features are useful for robotics (e.g. BARRIERs) • From previous experience, space for future growth is important! • If we update the size of the virtual machine on the memory diagram to be current.. 12 VM Growth • TVM (late 2004) ROM BrickOS TVM Byte Free 2k use code (12k) (4k) (8k) (3k) (3k) RAM (32k) 13 VM Growth • TVM (late 2004) ROM BrickOS TVM Byte Free 2k use code (12k) (4k) (8k) (3k) (3k) RAM (32k) • TVM (February 2007) ROM BrickOS TVM Byte 2k use code (12k) (4k) (11k) (3k) RAM (32k) 14 Something’s got to go... • #ere’s absolutely no free space for this stack of so%ware to run. • Can’t do anything about the reserved and ROM function memory. • Need the TVM and bytecode. • BrickOS can go! • But it’s being used to interface with the hardware from the TVM. • We’ll need to create a new set of ‘OS’ services for the TVM to use when interacting with the hardware. 15 A Solution Appears ROM ROM Byte Free TVM code (RCX executive) 2k use (4k) (11k) (3k) (12k) Total ROM (16k) Total RAM (32k) • #e RCX executive in ROM contains &rmware functions for interacting with the hardware at a basic level, and they are available to us already. • #e functions in ROM are wrapped in a C library (librcx[2]), which can be used in the C code of the TVM. • Can access the C functions from occam-π through use of the Foreign Function Interface [4]. • #e RCX’s hardware is memory mapped, so we can PLACE variables at those addresses in occam code to manipulate it directly. 16 On Endianness • #e virtual machine is little-endian, but the RCX is a big-endian architecture. • Calls to C functions require their parameters to be byte-swapped in and out, if the values are to be read and written correctly on both ends. • #e values of memory addresses read or written directly from occam (via PLACEd variables) will need to be swapped. • #ere are some complications with arithmetic shi%s and possibly other operations. 17 New Requirements • BrickOS will no longer bring up and initialise the hardware, the TVM must now do it. • Including memory, the timers and any interrupts. • #e ROM &rmware functions provide much lower level functionality than BrickOS previously did to the TVM. • Interfaces to the Sensors, Motors, LCD, Buttons, Sound and Power status are required, for programming the RCX. • #e RCX Executive loads at power on, and will accept an initial &rmware image (the TVM, in this case) over IR. • Transputer bytecode can be compiled directly into the VM, and uploaded with the initial &rmware image. • Subsequent code uploading will have to be done in the TVM, as BrickOS no longer provides this functionality. 18 Maximally Concurrent • Using the FFI and PLACEd variables, we can write almost all of the the now missing functionality in occam, running inside the TVM. • A minimal initialisation in C brings up the VM, then the processes containing the operating environment are loaded & run. • Bene"ts • Uni&ed scheduler (as much processing inside the VM as possible). • Safe concurrency down to the hardware level, for writing these system level processes. • Makes it more straightforward to expose natural process and/ or channel interfaces for the hardware to the programmer. 19 The debug.man 20 Ground Up Concurrency: Advantage • Whilst writing small test programs, it was hard to see when the VM was running, or if it had crashed or deadlocked. • Ideally it would be good to signal to the user that the program is running. • #e RCX has a &gure on the display in the shape of a person, which can be either walking or standing. • Initially, a small test process (debug.man) which used this &gure had been written when debugging the timer. • Running this process in parallel with any other code that is running gives us an instant indicator that the VM is running, and scheduling processes correctly. • Doing this with C threads would have been prohibitively complex for this purpose. 21 Parallelism as a Debug Aid ... -- Display a running man with the segments of the display PROC debug.man () TIMER tim: INT t: SEQ tim ? t WHILE TRUE SEQ lcd.set.segment (LCD.STANDING) tim ? AFTER t PLUS (500 * MILLIS) tim ? t lcd.set.segment (LCD.WALKING) tim ? AFTER t PLUS (500 * MILLIS) tim ? t : -- Main PROC, must have the three top level channels PROC my.test.program (CHAN BYTE kyb?, scr!, err!) PAR debug.man() foo() -- Could be any number of processes being tested. : 22 Difficulties • Working through issues of endianness between the virtual machine and the hardware. • Blind debugging, no printf, just a 4 digit LCD display. • #ere are also many ways the RCX can crash that will leave no way to put debug output to the screen. 23 The High-level View FFI Here be occam-π dragons C 24 Endianness (C FFI) void ffi_function (int *w) { int value.location; value.location = SwapTwoBytes(w[0]); /* do something to value.location */ *(int *)SwapTwoBytes(w[3]) = SwapTwoBytes (value.location); } Getting this swapping right is HARD for complex functions, which may have any combination of arrays, VAL TYPE or TYPE parameters 25 Problems • If address values are swapped (or not) incorrectly, the resulting memory accesses will very likely cause crashes (hard to debug!). • Variables that go through the FFI to C and back multiple times (say, in a loop) must be properly returned to the occam environment each time. • Some values go into the FFI and are not returned, so they do not have to be swapped back. • #e solution to these problems would be a big endian interpreter for this platform, avoiding swapping. • One exists, but there are problems with the big endian bytecode generation. 26 Results • A working virtual machine port that runs without ROM ROM Byte Free any underlying support OSTVM, and prcodeovides a large (RCX executive) 2k use amount of free spac(4k)e for pr(1o1k)grams.(3k) (12k) Total ROM (16k) Total RAM (32k) • High-level occam processes for interfacing to all of the major hardware functionality (Sensors, Motors, LCD, Buttons, Sound) 27 Future Work (>1 Month) • Bytecode uploading to the running VM and execution along with operating system processes in a single virtual machine instance. • Design of the embedded OS network, and its process API for programmers. • Sample robot programs, OS and API documentation. prefix delta to.lcd lcd.out.int (n) upload.handler succ numbers TVM 28 Future Work • Introduction of subsumption architecture primitives.