> I want to create a network of micro's. So far rs485 seems the go. What my > problem is how to get them all to talk and not have I suppose PACKET > colisions. I've done this by having one master node query all the active slaves in turn to send them the latest outgoing info and request the latest incoming info. Everything went into packets that were checksummed and contained both the sending and receiving address. I've included a section of the documentation file describing the protocol below. Since you are now trying to use PICs for "real" instead of just playing with them, it's time to learn them for real. A Basic compiler/interpreter is a nice kiddy toy, but I would never dream of using something like that for a real project. There is no substitute for actually understanding what is going on at the instruction level, even if you eventually end up using a compiler for most of the code. I'm sure others will object to this, but you did ask for my opinion. Another possibility is to use CAN between the PICs. Collision, address filtering, and a few other goodies are taken care of by the hardware. ---------------------------------------------------------------------------- -- 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. ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, olin@embedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads