This is a multi-part message in MIME format. ------=_NextPart_000_02FB_01C9D792.13E324A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit solarwind wrote: > I think that for my purposes, the token bus type works very well > because each node is guaranteed voice every x milliseconds (depending > on the number of nodes on the bus). There are other ways to guarantee this. I think the vast majority of RS-485 networks use a bus master system. This simplifies a lot of stuff. I did one a while back where the master addressed each slave in turn. If the slave had nothing to send, it responded with a NACK so that the master would know to go on to the next slave. In my system, the configuration wasn't known up front, but the maximum number of slaves was limited to 15. The bus master kept track of which slave addresses were in use to avoid the timeout for the unused ones each time thru the list of slaves. If a slave timed out three times in a row, it got crossed off the list. Once per loop, the master would try one unused address. If a slave responded, it would be added to the active list. This allowed hot-swapping and powering slaves up and down, which was important for this particular system. This was done 10 years ago on hardware that was designed before that. The biggest bestest PIC at the time was the 16F877. CAN hardware wasn't that readily available yet. A few years later and I definitely would have argued for using CAN instead. This project is long dead, so I can give more details on it. I have attached the protocol document. As I have said consistantly though, I still think you're better off using CAN and a 18F4580 or similar. ------=_NextPart_000_02FB_01C9D792.13E324A0 Content-Type: text/plain; name="fsim_serbus.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fsim_serbus.txt" FliteSim Embedded System Serial Bus Protocol, Version 4.2 This document gives a brief overview of how the embedded system serial bus fits into the overall architecture, then describes the protocol used on that bus. Revision History Only the latest revision of this specification is valid. This section is provided for convenience only to point out important changes. All revisions are classified as either minor or major. Major revisions change the rules such that a previously compliant master or slave may need to be updated. Major version numbers go up by one for each major revision. Minor revisions do not change any rules such that a previously compliant master or slave would need to be modified. These revisions might clarify ambiguities, provide more background, fix typos or formatting, etc. Minor version numbers start at zero and go up by one within each major version. Version 1.0, 20 Jan 1999 Original version. Checksum algorithm not specified. Version 1.1, 22 Jan 1999 Typo fix. Version 2.0, 3 Feb 1999 Added "Bus Turnaround" section. Specifies wait time after receive to transmit bus interface reversal. Version 2.1, 4 Feb 1999 Checksum algorithm specified. Version 3.0, 5 Feb 1999 Slave device now returns configuration data in HELLO ACK packet. Version 4.0, 9 Feb 1999 Added sender address to packet header. Version 4.1, 27 April 1999 Decreased packet and response timeouts from 10 to 5 milliseconds. Version 4.2, 23 September 1999 Fixed version number in title and typos. No substantive changes. System Overview The overall flight simulator system contains three main computers, called the IOS, visual, and cockpit. The IOS computer is the main system controller. It is a PC running Windows NT. This is where the flight model is computed, and where the instructor interacts with the simulator. The visual computer produces the out-the-window view presented to the pilot. This is a PC running a standalone program on Windows 95 or 98. The visual database is on this computer, and it receives information from the IOS computer that mostly indicates the plane's position and orientation within the visual world. The link to the IOS computer is currently an RS-232 serial line, and may be changed to ethernet in the future. The cockpit computer is where all the cockpit instruments are directly connected. This is an Intel Pentium processor on an STD bus. Most of the cockpit instruments are connected to the STD bus via various digital I/O, A/D, and D/A cards. The main job of the cockpit computer is to drive these devices. Device values are communicated to/from the IOS computer once every flight model frame time, which is currently 20 milliseconds. The link to the IOS computer is 10Mb/Sec ethernet. The cockpit computer also communicates with some devices via an RS-232 port. This is converted, using an external adapter, to an RS-485 serial bus. This is the "embedded system serial bus" referred to above. Serial Bus The main purpose of the serial bus is to reduce the number of individual wires that would otherwise need to be connected to the digital I/O cards on the STD bus. In particular, the serial bus is intended for I/O to the simulated cockpit radios. Each radio (or other clump of devices) is presented as one device on the serial bus. Each serial bus device is implemented with a Microchip PIC processor running custom firmware for this purpose. Each PIC is directly connected to whatever specific devices it drives, and communicates the device values to the cockpit computer via a common protocol over the serial bus. Serial Bus Protocol The RS-485 standard is electrical only, and does not address collision avoidance or flow control. The purpose of this protocol is to provide collision prevention, flow control, and reliability over a serial connection which is assumed to have a small but non-zero bit error rate. Each device on the serial bus is assigned a unique 4 bit address, from 0 to 15. Device 0 is the bus master, and the remaining devices are slaves. All bus activity is initiated by the master. Slaves never write data to the bus without having been told to do so by the master. The cockpit computer is the bus master, and each of the PICs is a separate slave with a separate bus address in the 1-15 range. Packet Format All communication on the serial bus is encapsulated in packets. All packets adhere to the following format: byte 0: opcode and target address byte 1: source address byte 2: N (number of data bytes, 0-255) byte 3: first data byte, if N >= 1 ... byte N + 2: last data byte, if N >= 2 byte N + 3: checksum low byte N + 4: checksum high This format allows all bus devices to know when a packet starts and ends, without having to know the meaning of the data bytes. Each packet therefore has five overhead bytes beyond the raw data bytes being transferred. The following descriptions give more detail on each of the five control bytes. Opcode and Target Address This is the first byte in a packet, and contains two fields. The low nibble is the target device bus address, and the high nibble is an opcode. The opcode describes the overall purpose of the packet. The list of opcodes and their meaning is given later. Only the addressed target device should act on the packet. Other devices on the bus must only determine when the packet has ended. The next byte on the bus is then again interpreted as the first byte of a new packet. Source Address The sender's bus address is in the low 4 bits. The upper 4 bits are reserved and should be set to 0 by senders and ignored by receivers. Number of Data Bytes This indicates the number of data bytes immediately following. Note that this could be zero. Checksum Bytes A 16 bit checksum is computed on all preceding bytes of the packet. The exact method of computing the checksum is decribed later in the section titled "Checksum Algorithm". A packet is only considered valid and possibly acted upon when the received checksum matches the checksum computed by the receiver based on the previous bytes of the packet. IF THE CHECKSUM DOES NOT MATCH, THE PACKET MUST BE COMPLETELY IGNORED. Note that all parts of the packet, including the length byte, are suspect on a checksum error. This means the receivers may be out of sync with the transmitter. The error recovery strategy is discussed in "Error Recovery", later in this document. Opcodes The high nibble of the first byte of each packet is an opcode that describes the overall purpose of the packet. The meaning of each of the opcodes is described below. All opcodes not described here are reserved and should not be sent. Receivers should ignore all packets with unrecognized opcodes. The opcodes are: 0 - HELLO This is always sent by the master to a slave address. The reciever must respond with a HELLO ACK packet to the master. This is used by the master to determine whether a slave exists at that address. The data bytes are not used. 1 - HELLO ACK This is sent by a slave to the master in response to a HELLO packet. The slave sends configuration info as data bytes. These data bytes are: byte 0 - Maximum output bytes slave can possibly accept. byte 1 - Maximum input bytes slave will ever send. byte 2 - Name length. Number of bytes in device name string to follow. bytes 3-N - Device name string. The string length must be exactly the number of bytes as indicated by data byte 2. The slave input and output size is used by the master to reduce unecessary data transfers. A "lazy" slave can simply report 255 for both values without causing any malfunctions. The name string is not required, but may aid in debugging. A lazy slave can just set the name length byte to 0, which requires no following string bytes. 2 - OUT AND REQ Transfers data from the master to the slave, and requests return data. The slave must respond with an IN packet. 3 - IN Transfers data from a slave to the master. This packet must only be sent when requested. Checksum Algorithm A 16 bit checksum is computed on all bytes of a packet except the checksum bytes themselves. The resulting value is then sent as the checksum for outgoing packets, or compared with the packet checksum bytes for incoming packets. All incoming packets must be ignored if the checksum from the packet does not match the expected checksum exactly. Before any packet bytes are processed, the checksum is initialized to 5555h. The following procedure is then applied for each packet byte that is included in the checksum, in packet order: 1) The current accumulated checksum is rotated one bit left. This means bits 14:0 are moved to bits 15:1 and bit 15 is moved to bit 0. 2) The byte value is added to the accumulated checksum. The carry, if any, is lost. 3) The ones compliment of the byte is added to the high byte of the accumulated checksum. The carry, if any, is lost. The accumulated checksum is the packet checksum value once this process is completed for all the applicable packet bytes. Bus Turnaround When there is no bus activity, the master is driving the bus, and the slaves are receiving. When the master tells a slave to send data, both the master and slave must switch their bus interfaces to the opposite transmit/receive mode, and again when the slave has finished transmitting. The new transmitter must not send data until the new receiver has finised reversing its bus interface. To guarantee this, both devices must reverse their bus interfaces as soon as possible, but the new transmitter must delay sending. The transmitter must wait a minimum time after receiving the last input byte before sending the first output byte. This timeout is currently set to 1 millisecond. Error Recovery It is important that bus data errors can be recovered from within a short time. To accomplish this, all receivers on the bus must follow these rules: 1) IGNORE ON ERROR. All packets with checksum errors, unexpected source, or other inconsistancies or errors must be completely ignored. This means an entire packet is either lost or is received whole. Note that the transmitter has no direct way to determine whether a packet was received or not. 2) PACKET TIMEOUT. Any partially transmitted packet must be assumed to have ended when no new characters are recieved for the timeout interval. This interval is currently set to 5 milliseconds. 3) RESPONSE TIMEOUT. If a response was expected from a slave to the master, no valid response packet was received, and no bytes at all are received for the timeout interval, then the master gives up waiting for the response. The master may then retry the request, continue on, or whatever. This prevents a lost packet in a request/response sequence from hanging the bus for a long time. Note that this puts constraints on the slaves for a maximum turnaround time from request to response. This timeout is currently set to 5 milliseconds. Data Organization Each slave maintains up to 255 input and output data bytes, for a total of up to 510 data bytes. "Input" and "output" are from the point of view of the master. Therefore, output data is transferred from master to slave, and input data from slave to master. The meaning of these data bytes is specific to the particular slave implementation and the hardware it is connected to. Data within a packet is transferred starting with byte 0. Output data packets may contain more bytes or less bytes than maintained by the slave. Additional bytes are ignored and unsent bytes retain their old value. For example, suppose a slave maintains 7 output bytes. If the master sends 10, then all 7 bytes are updated and 3 are ignored. If the master sends 5, then only the first 5 bytes are updated and the remaining two are unaltered. Slaves may respond with any number of input bytes. There is no requirement that all maintained input bytes be sent, only that a frame is sent when requested. The master will assume any unsent input bytes have not changed. The cockpit computer will make little or no assumptions about the meaning of any data bytes. It will simply maintain 255 input and output data bytes for each slave. These can be referenced in the FSIMIO.DEV file on the IOS computer by the slave device number (1-15), in or out, and the data byte address (0-254). ------=_NextPart_000_02FB_01C9D792.13E324A0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist ------=_NextPart_000_02FB_01C9D792.13E324A0-- ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.