COMMUNICATIONS, HANDY CRICKETS THE CRICKET INTERFACE The communications with the Handy Cricket is via infrared through the Serial-to-IR Cricket. We use IRDa components with our own modulation scheme that produces an effective comms rate of about 50K baud; however, the baud rate between the Serial Interface Cricket and the host computer is 9600 N-8-1. There is a hardware echo between the Serial-IR Interface and the host. Every time the host sends a byte to the Interface, that byte is echoed back to the host. It is necessary to fetch the byte before sending the next one, to keep from transmitting data to the Interface faster than it can handle. You may wish to check the handshake byte for correctness -- the byte you receive should be the same value as the one you last sent. INTERACTION PROTOCOL The Handy Cricket responds to a simple communications protocol. There is a 16-bit address register that specifies the address for read memory, write memory, or execute code from memory operations. Individual serial line transactions either set this register, or perform a read command, write command, or execute command. There is no handshake or return value on commands that do not specifically return a value (other than the handshaking implemented by the Interface Cricket as noted above). Command ASCII code Description set-pointer 131 followed by address: high byte and low byte sets address register to address. read-bytes 132 followed by two bytes of count (high byte first), after which the Cricket will transmit "count" bytes of data. The address register is auto-incremented throughout, so afterward the register is pointing at the byte just beyond the last one read. write-bytes 133 followed by two bytes of count (high byte first), then count bytes of data. Writes the bytes starting at the address indicated by the address register. When finished, the address register will point to the memory location immediately after the last byte written. run 134 starts execution of compiled Cricket Logo code beginning at address indicated by the address register. cricket-check 135 used to address one or multiple Crickets. See "Crickets Have Names," below. cricket-check MUST be performed at least once before engaging in the other operations, in order to enable the Cricket. CRICKETS HAVE NAMES There is a protocol that lets you use several Crickets at the same time. You may check if a Cricket is present, addressing it using an ASCII name. All Crickets in the line of sight of the Interface Cricket, with that name, respond and activate themselves for subsequent commands. Other Crickets ignore commands until a subsequent "cricket check" may enable them. You can use a null name to address all Crickets in sight. To address a cricket, send out the "cricket-check" byte, followed by the name of the cricket as a zero-terminated ASCII string. If that cricket is present, it will respond by sending back an ASCII 55. This cricket and any others with the same name will activate themselves for subsequent operations. (If multiple crickets are turned on, there will be a 55 handshake byte for each cricket that responded.) Any other cricket will "go to sleep," waiting for a subsequent cricket-check sequence that might activate it. A zero-termined null string (i.e., the cricket-check byte followed by just a zero) will activate all crickets in sight. The cricket name is stored as a zero-terminated ASCII string from addresses 0xff4 to 0xffe (11 bytes) in the cricket's memory. ADDITIONAL ECHOING Whenever data are written after the write-bytes opcode, not only is the byte written echoed [the afore-mentioned hardware echo], but the Cricket also sends back the one's complement of the byte [a software echo]. The reason for this software echo is to pace how fast the host computer delivers the bytes to be written to the Cricket. It takes finite time for the Cricket to write each byte. If the host computer simply dumped the bytes as fast at it could over the 9600 baud serial line, it would overrun the Cricket's write-speed. So the host must obtain the software echo byte before sending the next byte to be written. For example, to send the immediate command "beep" (all bytes in hexadecimal): Write: 87 00 [cricket-check] Read: 87 00 37 [87 and 00 are echos; 37 is Cricket's reply] remember, you must retrieve the hardware echo byte before you send a subsequent byte. So the actual sequence to implement the cricket-check per above is: write 87 read 87 write 00 read 00 read 37 Write: 83 0F ED [set-pointer to free area of memory] Read: 83 0F ED Write: 85 00 02 [write-bytes, 2 bytes] Read: 85 00 02 Write: 0C [byte #1: beep] Read: 0C F3 Write: 00 [byte #2: end-of-list] Read: 00 FF Write: 83 0F ED [set-pointer back before executing code] Read: 83 0F ED Write: 86 [run] Read: 86 IR COMMS SIGNAL FORMAT The Handy Cricket IR communications format is a custom bitstream layered on top of IRDa hardware. It is a byte-oriented signal; each serial byte sent from the PC causes an IR byte to be sent to the Cricket, and each IR byte received by the Cricket gets translated to a serial byte to the PC. Here is the signal format: +--+ +--+ +--+ +--+ | | | | | | 6 more | | ---+ +---------------+ +-------+ +-------+----------+ bits + +-------+ 4us ~50us 4us 8us 4us 8us 12us 4us 8us | | | | | | | |<-prestart pulse->| start | '1' bit | '0' bit | | stop | | | bit | LSB data | | | bit | The pulses indicate time periods when the transmitting IR LED should be on. The 8 data bits are sent LSB (least significant bit) first. The 12 usec bit interval is critical; the proportion of 4 usec on and 8 usec off is not. The length of the prestart pulse is not critical, but you should aim for 50 usec of off-time. CHANGE LOG TO THIS DOCUMENT Fri Sep 1 08:33:44 2006 fredm * added section ADDITIONAL ECHOING; thanks to Blake Skinner. Sun Sep 8 09:19:43 2002 fredm * added IR signal format docs from old Yahoo! newsgroup post. Mon Jun 10 13:57:43 2002 fredm * updated description of handshake byte to be correct for Handy Cricket system. Previous description was for MIT Red Dot system. * slight improvements to wording in Interaction Protocol section. Wed Feb 13 14:10:24 2008 fredm * unpacked example of cricket-check explaining that you must read after each write.