home | lewin's resume | contact lewin | larwe.com
capabilities & pricing | projects | about zws.com
|
home | lewin's resume | contact lewin | larwe.com |
This document contains proprietary technical specifications for the hardware and software components of the EPROMr 3.1 project. These details are provided for informational purposes only and are subject to change without notice. If you are a third party planning to develop hardware or software which works with this information, you are strongly encouraged to register as a developer. For more information, please email the EPROMr support contact. Keep reading or jump back to the index... Electrical Interface Specifications The EPROMr 3 is fitted with a standard DB9S serial connector wired as DCE, with pin assignments as follows:
The signal level is -10V to +10V and is RS232C compatible. With the correct cable, it can also be connected to RS422 serial ports such as those on Macintosh and compatible computers. If you are using an IBM-PC with 9-pin PC/AT-style serial ports, you can use any DB9S (computer) to DB9P (EPROMr) cable which has at least pins 2, 3 and 5 wired straight through. If you are using an IBM-PC with 25-pin serial ports, you can use a regular straight-through DB25S to DB25P modem cable in conjunction with a DB25S to DB9P adapter. If you are using a Macintosh or compatible computer, you can use a standard mini-DIN-8 to DB25P modem cable in conjunction with a DB25S to DB9P adapter. Keep reading or jump back to the index... The EPROMr is controlled over a serial link operated at 57600bps with 8 data bits, no parity, and one stop bit. Because sufficient flow control is implicit in the protocol specification, neither hardware nor software handshaking are required. The EPROMr hardware ties CTS to RTS, but CTS state (and the state of all other handshaking signals) should not be assumed because end-users may have only three signals connected (TxD, RxD and ground). For cross-product standardization reasons, the EPROMr implements two levels of control commands. The lower-level command set, termed GPSI3, provides simple functionality to allow the host machine to control the state of all lines to the personality module. The GPSI3 command set is common to the EPROMr 3 and all other devices based around the same interface module. The higher-level command set is referred to as E3P. It provides more complex functionality which is specific to the EPROMr. Although it is physically implemented in the microcontroller in the GPSI portion of the circuit, the E3P extension is functionally part of the EPROMr personality module. E3P instructions are essentially macros which invoke multiple sequenced GPSI3 instructions. This reduces the amount of data transmission required to accomplish certain important or time-critical tasks. Important Note: If you develop your own personality modules for this product, the control software you write should use only GPSI3 instructions. E3P functionality WILL CHANGE SUBSTANTIALLY between product firmware revisions. If you use only GPSI3 instructions, your software may not operate at the maximum achievable speed, but you are much less likely to encounter compatibility problems with future versions of the EPROMr firmware. Both command sets use the same basic protocol. Packets from the host to the GPSI are formatted thus:
Once the GPSI receives a valid packet, it acts on the received command synchronously. While the GPSI is processing a command, any bytes transmitted by the host will be discarded. (This is unavoidable; since many GPSI features require precise timing, the microcontroller's interrupt mechanism needs to be disabled). Once the command has been processed, the GPSI responds with a similarly formatted packet:
Protocol crash recovery is implemented as follows: If the GPSI receives an incorrectly formatted packet, it will halt normal execution and switch to crash-recovery mode. In this mode, the GPSI waits for 128 consecutive NULL (00h) bytes from the host. Once a suitably long string of NULL bytes is detected in the input stream, the GPSI sends a single NULL byte in reply to indicate to the host that the crash condition is ended and any partially queued packet in either direction is discarded. Any third-party control software must implement this crash-recovery system because spurious bytes are frequently sent by a UART during powerup and powerdown. Without crash recovery, this garbage data might confuse the GPSI. NULL commands which are sent by the host outside the context of a valid packet capsule are ignored by the GPSI when not in crash-recovery mode. Note: A special-case packet containing only a checksum with no command byte (i.e. 01 01) can be used to check that the GPSI is ready to accept commands. The GPSI responds with a standard "no error" packet, ie. 02 00 02. If the host receives a response packet with a bad checksum and/or framing error, or it times out waiting for a packet to complete, it should flush its receive and transmit buffers and send 256 consecutive NULL bytes. The receive buffer should then be flushed again, and the last command packet sent can now safely be resent to the GPSI. Keep reading or jump back to the index... GPSI3 opcodes not finalized. Keep reading or jump back to the index... E3P opcodes not finalized. Keep reading or jump back to the index... Result codes not finalized. Keep reading or jump back to the index... |
