Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool2.mu.edu!uwm.edu!rutgers!otello!gear!wolf!-=Runaway.Daemon=- From: -=Runaway.Daemon=-@wolf.fidonet.sublink.org (-=Runaway Daemon=-) Newsgroups: comp.sys.handhelds Subject: I/O on the hp48sx Message-ID: <3236.278F9D6C@wolf.fidonet.sublink.org> Date: 12 Jan 91 01:06:03 GMT Organization: Rekursive Labs sdf- Pisa, Italy Lines: 87 the wired UART including checking for framing and overrun errors and using RBR and RBF. As in the serial port, all bit timing is relative to the leading edge of the start bit and has 1/16th bit resolution. Due to the probability that reflections from the transmitter will be received and interpreted by the receiver, the receiver data is ignored (by disabling receiver interrupts) while transmitting. The serial port cannot be used while doing IR I/O. Its RX pin will be ignored by the UART. 4. Kermit File Transfer Kermit file transfer is preferable to unformated I/O since it can detect errors and correct them by re-transferring bad packets. The Kermit you use should be set to use type 3 (CRC) checksums for IR I/O since the error rate is higher than for wired I/O. If you use your Kermit in server mode the HP 48 will use "I" packets to request type checksums. The HP 48 Kermit does not use XON/XOFF handshaking since Kermit packets are small enought that additional handshaking should not be necessary. Your Kermit must have an input buffer which can hold at least 14 bytes in order to receive an "S" or "I" from the HP 48, although a larger buffer is clearly desirable for more efficient transfers. The input buffer must also be large enough to receive the largest "F" (filename) packet that will be sent. - 8 - 5. Non-Kermit I/O 5.1 General Considerations The HP 48 can receive a maximum of 255 bytes in a continuous stream, so to transfer more than this you should use XON/XOFF handshaking or some higher level protocol which breaks the data stream into pieces smaller than this. Data sent to the HP 48 should have inter-frame gaps less than 4 frame times or greater than 4 frame times plus 5 ms. Inter-frame gaps of between 4 frame times and 4 frame times plus 5 ms should be avoided since they may cause UART overruns on the HP 48. Be sure the clock is not ticking in the HP 48 display since clock ticks, alarms coming due, or other timer interrupts extend the 5 ms to a much longer time, so they can cause UART overruns. For the same reason, no keys should be pressed while doing I/O (unless the intent of the key press is to abort the I/O). You must allow enough time for the HP 48 to read data out of its receive buffer (using SRECV) before sending more data or the 255 byte receive buffer will be overflowed. Use of some sort of checksum is recommended, especially for IR I/O which is sensitive to noise. Garbage characters (most commonly FF bytes) can be received between transmissions since a single IR or electrical noise pulse acts as a start bit. 5.2 Special Considerations for IR Since IR from the transmitter can reflect back into the receiver, the receiver should be ignored while transmitting and carefully cleaned up after the transmitting is done. If your IR receive circuit is feeding a UART, you should wait for at least a half bit time after the stop bit from the last transmitted to be sure that reflected byte has been received before clearing the UART's receive buffer as well as any framing or overrun errors. At this point the receive circuit will be ready to receive valid data, although (as noted above) this "valid data" can contain garbage characters due to IR or electrical noise pulses. Be sure to use some reliable error detection technique if data integrity is important! Because IR I/O half duplex (due to reflections), XON/XOFF handshaking is not possible. - 9 - -- WolfNet BBS Pisa (Italy) Tel. +39-50-589050 300-14.4K Baud Matrix 2:332/602.0 -=Runaway Daemon=- - via FidoNet node 2:332/602 UUCP: ...!gear!wolf!-=Runaway.Daemon=- ARPA: -=Runaway.Daemon=-@wolf.fidonet.sublink.org