.TLStyx-on-a-Brick.AUChris Locke.brchris@vitanuova.com.AIVita Nuova.brJune 2000.SHBackground.LPThe aim of the Vita-Nuova ``styx-on-a-brick'' project wasto demonstrate the simplicity of the Styx protocol and the easewith which a Styx `stub' can be implemented on tiny devices.We also aimed to demonstrate the effectiveness of a protocol based approachto resource management and sharing, whether the resource be a physical deviceor a software service..LPAdopting a protocol-centric view of resource and service management, as opposed toa language-centric approach (as emphasised for instance by Jini™ with Java)greatly eased the software burden on our tiny target device \-implementing a simple protocol in firmware required much less work than trying toimplement a virtual machine. We are confident that if we had adopted a language-centricapproach, we would not have completed the project within our aggressive space and implementation time constraints.†.FS.FA†Indeed, we later discovered that in the application of Jini to load code into an RCX robot no partof Jini was actually on the brick..FE.LPThe project took 2 weeks from start to finish.In this time the firmware was developed and all client softwarewas written: firmware download, IR-link protocol support,clockface application and worldclock application.Two people worked on the project, one full-time, the other (Nigel Roles) part-time..LPThe demo was then taken on a Press Conference tour of the USand later appeared at the Usenix2000 Plan 9/Inferno BOF at the requestof Dennis Ritchie..LPI should stress that the project was a demonstration of the ease ofsupporting Styx on small devices \- it was not a demo of robotics!(Indeed, the design of the IR-link protocol, Styx name space and theservices provided by the firmware would be considerably different forserious robotics.).LPThe project used a standard Lego™ Mindstorms™ robotics kit \-the ``Robotics Invention System''. This consists of the RCX brick,2 motors, 2 button sensors, a light sensor and a whole load oflego pieces \- including wheels, gears and axles; which all adds upto a whole load of fun!.LPThe RCX brick is an Hitachi H8 microcontroller with 32K of RAM anda 16K ROM BIOS. The RCX provides 3 motor outputs and 3 sensor inputs.Communication with the RCX is via IR. An IR tower is supplied with the``Robotics Invention System'' that connects to a PC via a serial port..SHAcknowledgements.LPBefore going any further I must acknowledge the work of Kekoa Proudfoot atStanford and Russ Nelson at Crynwr Software.Without their valiant efforts we would not have been able to pursue this project.Our work relied on the documents and librcx suite provided by Kekoa:.P1http://graphics.stanford.edu/~kekoa/rcx/.P2and on information from Russ Nelson's web site.P1http://www.crynwr.com/lego-robotics/.P2.SHFiles.LPThe files in the.CW legostyx.tarfile are shown in Table 1..KF.TScenter;lf(CW) lfR .llp.h Link level protocol constantsstyx.c The firmware implementationstyx.srec The firmware image (S-record format)styx_abp.srec The firmware with the alternating bit part of the link protocol enabledsend.b Test app \- sends RCX op codes to the brickfirmdl.b Firmware download apprcxsend.m Util module headerrcxsend.b Util module \- supports RCX ROM message format on serial linktimers.m Timer module headertimers.b Util module \- general purpose timerslegolink.b Implements the link protocol via a limbo file2chan()clockface.b The controller app for our Clockface robot.TE.fi.ce 10.I "Table 1.\ "\cFiles in the Styx-on-a-Brick package.ce 0.KE.SHProject details.NH 1Firmware Download.LPThe RCX brick comes supplied with Lego firmware to be downloaded into the RAM viathe IR link. The ROM implements a monitor which provides for the firmware download,as well as other 'op-codes'..LPWe wrote our own firmware in C using the GNU H8 compiler suite on a FreeBSD machine.The code used Kekoa's.CW librcxlibrary for interfacing to the RCX ROM routines.(We should have liked to have done an H8 code generator for our own compiler suite,but time did not permit this!)The.CW gnuh8list is accessible via:.P1http://www.pcserv.demon.co.uk/.P2First up we had to write a Limbo application to communicate with the ROM, viathe IR tower in order that we could get our firmware downloaded onto the RCX.This is the firmdl application. Source files: .CW firmdl.b , .CW rcxsend.band .CW timers.b.NH 1Styx Comms Link.LPHaving got a means of installing our firmware we needed a means of deliveringStyx messages to and from the Brick..LPStyx makes certain demands of its transport media:.TSl l .Reliable messages must not get 'lost'Ordered messages must not get transposed.TEThe RCX ROM provides a couple of functions for IR comms \- a routine to checkfor message reception and a routine for message delivery.The message reception routine receives the data of a RCX "Transfer Data"message (RCX op-code 0x45).LPWe chose to use this facility as a means of delivering Styx messages to our Firmwareon the Brick. But it did not provide the Transport properties that Styx requires.To meet the Styx requirements we implemented a simple 'alternating bit' protocol whosepayload was the Styx messages themselves. These Link protocol messages become thepayload of the RCX "Transfer Data" messages..LPThe IR link is very slow, the baud rate of the IR tower serial link is 2400and the ROM message format requires that every byte of a message be doubled up withits complement. (e.g. the byte 0x7e is transmitted as 0x7e, 0x81)This is because of the simple way that the RCX ROM and hardware handle eliminationof the ambient IR signal level \- all message have the same number of 1s and 0s sothe ambient IR level can be negated by subtracting the average level.All RCX messages are also prefixed by a header and suffixed with a checksum:.P10x55 0xff 0x00 \fID1 ~D1 D2 ~D2 ... Dn ~Dn C ~C\fP.P2where .I D1\&....I Dnare the bytes in the message body and \fIC = D1+D2+ ... Dn\fP..LPTherefore, the effective data rate is considerably less than 1200 baud..LPWe noted that many Styx messages, especially .CW Twstatand .CW Rstat ,contained a highproportion of 0 byte values.†.FS.FAThe protocol has since been revised to reduce that..FEConsequently, we decided to incorporate a 0-run-lengthcompression scheme in our simple link protocol..LPWithin the payload of the link messages:.TSl l .0x88 0x00 represents 0x880x88 n represents n + 2 0'sothers represent themselves.TE.LPAn additional burden is that communication with the Brick via the IR tower has to be strictlysynchronous. The IR tower echoes back all data transmitted to it on the serial linkas well as any data received on the IR link. Therefore the brick must not send IR datawhile the PC is sending serial data to the tower. In order to achieve this a 'ping-pong'communication scheme must be employed. The PC is the master, the brick is the slave.The master sends a request and waits for the reply from the slave.Only the master is allowed to start an exchange..LPThe problem with the master/slave style of communication is that a Styx Serverimplements blocking requests, e.g. reads and writes, by simply not responding to therequest until the operation is completed. This does not fit with the link protocolrequirement that the server (slave) always respond and the requirement that the brickcannot instigate a data exchange.The firmware could simply reply with an empty Link protocol message but it then has noway of giving timely notification of the completion of a pending Styx request as it is notallowed to start a link-protocol message exchange..LPTo get around the pending Styx reply problem, the link protocol header incorporates a flagthat the slave (brick) can set to indicate that it is holding outstanding requests and that themaster (PC) should continue to poll the slave in order to receive their replies in a timelyfashion..LPThe link protocol message format is as follows.Request from Master (PC) to Slave (RCX):.LP.TSl l .0x45/4d RCX Transfer Data op-code (including RCX alternating bit)0 LSB of "Data" block number0 MSB of "Data" block number* LSB of "Data" payload length (lost to ROM firmware)* MSB of "Data" payload length (lost to ROM firmware) (n+2)* LSB of Link protocol payload length* MSB of Link protocol payload length (n+1)* Link protocol header*[n-1] Link protocol payload (0 or 1 Styx messages)* "Transfer Data" cksum (Last byte of Link protocol payload).TE.LPNote that the 0x45 ROM op-code ("Transfer Data") message incorporates a checksum byte at theend, but the ROM doesn't bother to check it so we moved the last byte of the Link protocolpayload (or the link header if the payload is empty) into the checksum position ofthe ROM message..LPReply from Slave to Master:.LP.TSl l .? Junk from ROM* LSB of Link protocol payload length* MSB of Link protocol payload length (n+1)* Link protocol header*[n] Link protocol payload.TE.LPThe Link protocol header has the following flags:.LP.TSl l .bit 0 Alternating bitbit 1 Poll immediate (requested by slave)bit 2 Poll periodic (requested by slave)bit 3 compressed (payload is 0-run-length compressed)bits 4-7 reserved (should be 0).TE.LPThe master flips the .I Alternating.I bitfor every message that it successfully delivers.If a slave reply is lost or corrupted the master will re-send the message using the samealternating bit value. The slave should not act on a repeated message but shouldre-send it's last response. The value of the alternating bit in the slave responseis the same as in the request from the master..LPThe .I Poll.I immediatebit indicates that the slave has more data to send to the master.The master should immediately send another Link-protocol message, even if it has nodata to send, so as the slave can reply with its pending data..LPThe .I Poll.I periodicbit indicates that the slave has pending (blocked) requests thatit will reply to sometime in the future. The master should periodically poll theslave, even if the master has no data to send. The polling period should be smallenough that reply latencies are acceptable..NH 1The name space.LPWe now have a means of getting Styx messages to and from the brick.But what does the name space provided by the firmware on the brick look like?.LPWe wanted a generic name space; one that reflected the functions of the brick, notthe model attached to it, so that the same firmware could be used with manydifferent robots..LPThe brick has 3 motor outputs and 3 sensor inputs.The motors can be run forwards or reverse with 8 different power settings.They can be stalled, also with 8 power levels, and they can be left 'floating'[A stalled motor presents resistance to turning proportional to the stall power level].LPThere are 2 types of sensor \- buttons and light-sensors.[You can also get a 'rotation sensor', but we had not got one in our kit!].LPWe decided on a name space comprised of 2 directories, .CW motorand .CW sensor .We didn't need to use subdirectories for our name space but it was easy, so we did!.LPThe motor directory contains 4 files \- .CW 0 , .CW 1 , .CW 2and .CW 012 .The files .CW 0 , .CW 1and .CW 2represent the individual motor outputs andaccept command messages of the form.I 'XP'where .I Xis a direction and.I Pis the power level..LP.I Xcan be one of.TSl l .f forwardr reverses stallF float.TE.LP.I Pis a digit in the range.CW '0..7'.LPThe file .CW 012takes messages of the form.I 'XPXPXP'enabling the state of all the motors to be modified with a single message.The first .I XPpair affects motor 0, the middle pair affects motor 1 and thelast pair affects motor 2..I XPcan be.CW '--'indicating that the state should remain the same as before..LP.LPThe sensor directory contains three files .CW 0 , .CW 1and .CW 2 ,corresponding to the three sensor inputs on the brick..LPBefore a sensor file can be read it must be configured by writing a configurationmessage to the file. These message take the form.I 'Tv*'where.I Tis the sensor type and .I v*is a threshold value.The idea of the threshold value is that reads of the sensor file wil block untilthe threshold value has been achieved..LPReads of a sensor file return its current value.When a sensor file is configured any pending reads of the sensor arefailed with the error message.CW 'reset' ..LPThe available sensor types are:.LP.TSl l .b buttonl light sensor.TE.LPThe threshold value for a button sensor is a click count.So the control message.CW 'b0'configures a sensor to be a button and subsequent readsof the file will yield the current click count..brThe message.CW 'b20'will cause subsequent reads to block until the click count reaches20 or more..LPThe threshold value for a light sensor is a raw sensor value qualified by.CW '<'or.CW '>' ..LPThe control message.CW 'l>600'configures the input to be a light sensor and subsequentreads will block until the sensor value exceeds 600.If the.CW '<'qualifier is used, reads block until the value drops below the threshold..SHUsing the Styx firmware.NH 1Download the firmware.LPUse the .CW firmdlcommand to download the firmware to the brick.P1% firmdl 0 styx.srec%.P2.LPThe first argument is the number of the inferno serial port (.CW /dev/eia0in this example).The second argument is the file containing the firmware image in s-record format..LPThe firmdl app prints the response code from the ROM.On successful download the ROM reports:.P1Just a bit off the block!.P2.LPOnce the firmware is downloaded it is immediately run.The RCX display should be showing the 'running man' symbol.If at any time the Styx firmware encounters an error, the 'running man'is changed to a 'standing man' and the source code line number of the erroris displayed on the LCD.The firmware doesn't stay resident: it monitors the on/off button andrestarts the ROM monitor when it is pressed..NH 1Start the link protocol.LP.P1% legolink 0%.P2.LPThe legolink argument is the serial port over which to run the link protocol.This will be the same as the first argument to the firmdl command..LPOnce started the legolink command creates the file .CW /net/legolinkin the Infernoname space. Any reads/writes of this file are the payload data of the link protocol..NH 1Mount the brick name space.LP.P1% mount -o -A /net/legolink /n/remote.P2.LPThe .CW -Aflag to mount prevents the command from trying todo authenticationon the link before running the Styx protocol over it.The.CW -ooption uses an older version of Styx.The second argument to mount is the the file over which the Styx protocol will be run.Raw Styx messages are written to and read from this file.The third argument is the directory on which to mount the name space presented by theStyx server on the other end of the link \- the firmware on the Brick..NH 1Explore the name space.LP.P1% cd /n/remote% lsmotorsensor% ls motormotor/0motor/1motor/2motor/012% ls sensorsensor/0sensor/1sensor/2%.P2.LPAttach a motor to the first output and a button sensor to the first inputand then try the following....LPStart motor....P1% cd motor% echo -n f7 > 0%Lines 1–500 of 642. Load more
.TL Styx-on-a-Brick .AU Chris Locke .br chris@vitanuova.com .AI Vita Nuova .br June 2000 .SH Background .LP The aim of the Vita-Nuova ``styx-on-a-brick'' project was to demonstrate the simplicity of the Styx protocol and the ease with which a Styx `stub' can be implemented on tiny devices. We also aimed to demonstrate the effectiveness of a protocol based approach to resource management and sharing, whether the resource be a physical device or a software service. .LP Adopting a protocol-centric view of resource and service management, as opposed to a language-centric approach (as emphasised for instance by Jini™ with Java) greatly eased the software burden on our tiny target device \- implementing a simple protocol in firmware required much less work than trying to implement a virtual machine. We are confident that if we had adopted a language-centric approach, we would not have completed the project within our aggressive space and implementation time constraints.† .FS .FA †Indeed, we later discovered that in the application of Jini to load code into an RCX robot no part of Jini was actually on the brick. .FE .LP The project took 2 weeks from start to finish. In this time the firmware was developed and all client software was written: firmware download, IR-link protocol support, clockface application and worldclock application. Two people worked on the project, one full-time, the other (Nigel Roles) part-time. .LP The demo was then taken on a Press Conference tour of the US and later appeared at the Usenix2000 Plan 9/Inferno BOF at the request of Dennis Ritchie. .LP I should stress that the project was a demonstration of the ease of supporting Styx on small devices \- it was not a demo of robotics! (Indeed, the design of the IR-link protocol, Styx name space and the services provided by the firmware would be considerably different for serious robotics.) .LP The project used a standard Lego™ Mindstorms™ robotics kit \- the ``Robotics Invention System''. This consists of the RCX brick, 2 motors, 2 button sensors, a light sensor and a whole load of lego pieces \- including wheels, gears and axles; which all adds up to a whole load of fun! .LP The RCX brick is an Hitachi H8 microcontroller with 32K of RAM and a 16K ROM BIOS. The RCX provides 3 motor outputs and 3 sensor inputs. Communication with the RCX is via IR. An IR tower is supplied with the ``Robotics Invention System'' that connects to a PC via a serial port. .SH Acknowledgements .LP Before going any further I must acknowledge the work of Kekoa Proudfoot at Stanford and Russ Nelson at Crynwr Software. Without their valiant efforts we would not have been able to pursue this project. Our work relied on the documents and librcx suite provided by Kekoa: .P1 http://graphics.stanford.edu/~kekoa/rcx/ .P2 and on information from Russ Nelson's web site .P1 http://www.crynwr.com/lego-robotics/ .P2 .SH Files .LP The files in the .CW legostyx.tar file are shown in Table 1. .KF .TS center; lf(CW) lfR . llp.h Link level protocol constants styx.c The firmware implementation styx.srec The firmware image (S-record format) styx_abp.srec The firmware with the alternating bit part of the link protocol enabled send.b Test app \- sends RCX op codes to the brick firmdl.b Firmware download app rcxsend.m Util module header rcxsend.b Util module \- supports RCX ROM message format on serial link timers.m Timer module header timers.b Util module \- general purpose timers legolink.b Implements the link protocol via a limbo file2chan() clockface.b The controller app for our Clockface robot .TE .fi .ce 10 .I "Table 1.\ "\c Files in the Styx-on-a-Brick package .ce 0 .KE .SH Project details .NH 1 Firmware Download .LP The RCX brick comes supplied with Lego firmware to be downloaded into the RAM via the IR link. The ROM implements a monitor which provides for the firmware download, as well as other 'op-codes'. .LP We wrote our own firmware in C using the GNU H8 compiler suite on a FreeBSD machine. The code used Kekoa's .CW librcx library for interfacing to the RCX ROM routines. (We should have liked to have done an H8 code generator for our own compiler suite, but time did not permit this!) The .CW gnuh8 list is accessible via: .P1 http://www.pcserv.demon.co.uk/ .P2 First up we had to write a Limbo application to communicate with the ROM, via the IR tower in order that we could get our firmware downloaded onto the RCX. This is the firmdl application. Source files: .CW firmdl.b , .CW rcxsend.b and .CW timers.b .NH 1 Styx Comms Link .LP Having got a means of installing our firmware we needed a means of delivering Styx messages to and from the Brick. .LP Styx makes certain demands of its transport media: .TS l l . Reliable messages must not get 'lost' Ordered messages must not get transposed .TE The RCX ROM provides a couple of functions for IR comms \- a routine to check for message reception and a routine for message delivery. The message reception routine receives the data of a RCX "Transfer Data" message (RCX op-code 0x45) .LP We chose to use this facility as a means of delivering Styx messages to our Firmware on the Brick. But it did not provide the Transport properties that Styx requires. To meet the Styx requirements we implemented a simple 'alternating bit' protocol whose payload was the Styx messages themselves. These Link protocol messages become the payload of the RCX "Transfer Data" messages. .LP The IR link is very slow, the baud rate of the IR tower serial link is 2400 and the ROM message format requires that every byte of a message be doubled up with its complement. (e.g. the byte 0x7e is transmitted as 0x7e, 0x81) This is because of the simple way that the RCX ROM and hardware handle elimination of the ambient IR signal level \- all message have the same number of 1s and 0s so the ambient IR level can be negated by subtracting the average level. All RCX messages are also prefixed by a header and suffixed with a checksum: .P1 0x55 0xff 0x00 \fID1 ~D1 D2 ~D2 ... Dn ~Dn C ~C\fP .P2 where .I D1 \&... .I Dn are the bytes in the message body and \fIC = D1+D2+ ... Dn\fP. .LP Therefore, the effective data rate is considerably less than 1200 baud. .LP We noted that many Styx messages, especially .CW Twstat and .CW Rstat , contained a high proportion of 0 byte values.† .FS .FA The protocol has since been revised to reduce that. .FE Consequently, we decided to incorporate a 0-run-length compression scheme in our simple link protocol. .LP Within the payload of the link messages: .TS l l . 0x88 0x00 represents 0x88 0x88 n represents n + 2 0's others represent themselves .TE .LP An additional burden is that communication with the Brick via the IR tower has to be strictly synchronous. The IR tower echoes back all data transmitted to it on the serial link as well as any data received on the IR link. Therefore the brick must not send IR data while the PC is sending serial data to the tower. In order to achieve this a 'ping-pong' communication scheme must be employed. The PC is the master, the brick is the slave. The master sends a request and waits for the reply from the slave. Only the master is allowed to start an exchange. .LP The problem with the master/slave style of communication is that a Styx Server implements blocking requests, e.g. reads and writes, by simply not responding to the request until the operation is completed. This does not fit with the link protocol requirement that the server (slave) always respond and the requirement that the brick cannot instigate a data exchange. The firmware could simply reply with an empty Link protocol message but it then has no way of giving timely notification of the completion of a pending Styx request as it is not allowed to start a link-protocol message exchange. .LP To get around the pending Styx reply problem, the link protocol header incorporates a flag that the slave (brick) can set to indicate that it is holding outstanding requests and that the master (PC) should continue to poll the slave in order to receive their replies in a timely fashion. .LP The link protocol message format is as follows. Request from Master (PC) to Slave (RCX): .LP .TS l l . 0x45/4d RCX Transfer Data op-code (including RCX alternating bit) 0 LSB of "Data" block number 0 MSB of "Data" block number * LSB of "Data" payload length (lost to ROM firmware) * MSB of "Data" payload length (lost to ROM firmware) (n+2) * LSB of Link protocol payload length * MSB of Link protocol payload length (n+1) * Link protocol header *[n-1] Link protocol payload (0 or 1 Styx messages) * "Transfer Data" cksum (Last byte of Link protocol payload) .TE .LP Note that the 0x45 ROM op-code ("Transfer Data") message incorporates a checksum byte at the end, but the ROM doesn't bother to check it so we moved the last byte of the Link protocol payload (or the link header if the payload is empty) into the checksum position of the ROM message. .LP Reply from Slave to Master: .LP .TS l l . ? Junk from ROM * LSB of Link protocol payload length * MSB of Link protocol payload length (n+1) * Link protocol header *[n] Link protocol payload .TE .LP The Link protocol header has the following flags: .LP .TS l l . bit 0 Alternating bit bit 1 Poll immediate (requested by slave) bit 2 Poll periodic (requested by slave) bit 3 compressed (payload is 0-run-length compressed) bits 4-7 reserved (should be 0) .TE .LP The master flips the .I Alternating .I bit for every message that it successfully delivers. If a slave reply is lost or corrupted the master will re-send the message using the same alternating bit value. The slave should not act on a repeated message but should re-send it's last response. The value of the alternating bit in the slave response is the same as in the request from the master. .LP The .I Poll .I immediate bit indicates that the slave has more data to send to the master. The master should immediately send another Link-protocol message, even if it has no data to send, so as the slave can reply with its pending data. .LP The .I Poll .I periodic bit indicates that the slave has pending (blocked) requests that it will reply to sometime in the future. The master should periodically poll the slave, even if the master has no data to send. The polling period should be small enough that reply latencies are acceptable. .NH 1 The name space .LP We now have a means of getting Styx messages to and from the brick. But what does the name space provided by the firmware on the brick look like? .LP We wanted a generic name space; one that reflected the functions of the brick, not the model attached to it, so that the same firmware could be used with many different robots. .LP The brick has 3 motor outputs and 3 sensor inputs. The motors can be run forwards or reverse with 8 different power settings. They can be stalled, also with 8 power levels, and they can be left 'floating' [A stalled motor presents resistance to turning proportional to the stall power level] .LP There are 2 types of sensor \- buttons and light-sensors. [You can also get a 'rotation sensor', but we had not got one in our kit!] .LP We decided on a name space comprised of 2 directories, .CW motor and .CW sensor . We didn't need to use subdirectories for our name space but it was easy, so we did! .LP The motor directory contains 4 files \- .CW 0 , .CW 1 , .CW 2 and .CW 012 . The files .CW 0 , .CW 1 and .CW 2 represent the individual motor outputs and accept command messages of the form .I 'XP' where .I X is a direction and .I P is the power level. .LP .I X can be one of .TS l l . f forward r reverse s stall F float .TE .LP .I P is a digit in the range .CW '0..7' .LP The file .CW 012 takes messages of the form .I 'XPXPXP' enabling the state of all the motors to be modified with a single message. The first .I XP pair affects motor 0, the middle pair affects motor 1 and the last pair affects motor 2. .I XP can be .CW '--' indicating that the state should remain the same as before. .LP .LP The sensor directory contains three files .CW 0 , .CW 1 and .CW 2 , corresponding to the three sensor inputs on the brick. .LP Before a sensor file can be read it must be configured by writing a configuration message to the file. These message take the form .I 'Tv*' where .I T is the sensor type and .I v* is a threshold value. The idea of the threshold value is that reads of the sensor file wil block until the threshold value has been achieved. .LP Reads of a sensor file return its current value. When a sensor file is configured any pending reads of the sensor are failed with the error message .CW 'reset' . .LP The available sensor types are: .LP .TS l l . b button l light sensor .TE .LP The threshold value for a button sensor is a click count. So the control message .CW 'b0' configures a sensor to be a button and subsequent reads of the file will yield the current click count. .br The message .CW 'b20' will cause subsequent reads to block until the click count reaches 20 or more. .LP The threshold value for a light sensor is a raw sensor value qualified by .CW '<' or .CW '>' . .LP The control message .CW 'l>600' configures the input to be a light sensor and subsequent reads will block until the sensor value exceeds 600. If the .CW '<' qualifier is used, reads block until the value drops below the threshold. .SH Using the Styx firmware .NH 1 Download the firmware .LP Use the .CW firmdl command to download the firmware to the brick .P1 % firmdl 0 styx.srec % .P2 .LP The first argument is the number of the inferno serial port ( .CW /dev/eia0 in this example). The second argument is the file containing the firmware image in s-record format. .LP The firmdl app prints the response code from the ROM. On successful download the ROM reports: .P1 Just a bit off the block! .P2 .LP Once the firmware is downloaded it is immediately run. The RCX display should be showing the 'running man' symbol. If at any time the Styx firmware encounters an error, the 'running man' is changed to a 'standing man' and the source code line number of the error is displayed on the LCD. The firmware doesn't stay resident: it monitors the on/off button and restarts the ROM monitor when it is pressed. .NH 1 Start the link protocol .LP .P1 % legolink 0 % .P2 .LP The legolink argument is the serial port over which to run the link protocol. This will be the same as the first argument to the firmdl command. .LP Once started the legolink command creates the file .CW /net/legolink in the Inferno name space. Any reads/writes of this file are the payload data of the link protocol. .NH 1 Mount the brick name space .LP .P1 % mount -o -A /net/legolink /n/remote .P2 .LP The .CW -A flag to mount prevents the command from trying to do authentication on the link before running the Styx protocol over it. The .CW -o option uses an older version of Styx. The second argument to mount is the the file over which the Styx protocol will be run. Raw Styx messages are written to and read from this file. The third argument is the directory on which to mount the name space presented by the Styx server on the other end of the link \- the firmware on the Brick. .NH 1 Explore the name space .LP .P1 % cd /n/remote % ls motor sensor % ls motor motor/0 motor/1 motor/2 motor/012 % ls sensor sensor/0 sensor/1 sensor/2 % .P2 .LP Attach a motor to the first output and a button sensor to the first input and then try the following... .LP Start motor... .P1 % cd motor % echo -n f7 > 0 %