one way Serial DasiyChain

Just have your Rx ISR put the received character straight into its Tx queue

Would you consider an alternative design that uses some sort of multi-drop bus? It would be a lot easier. I guess that you want to use simple controllers and not have to worry about any extra UARTS.

You could have 256 slave controllers all talking bi-directionally with a single master controller. One final exta controller is required, it will have a 'special address' on the multi-drop bus and its function is only to receive data from the master and transmit it to the PC.

Otherwise, you need to establish a protocol that will allow the system to maintain the integrity of each 8-byte packet. At a minimum each packet will need to start with a start_of_packet character followed by a source_byte to indicate the controller that originated the packet.

If there is a possibility that the start_of_packet charcter can appear in the data, you will need a mechanism to deal with this. If the data is, for example, all ASCII, simply choose a non ASCII character for start_of_packet.

Some form of checksum, or better yet a CRC on the end of the packet would be a good idea. If an error is detected, you may need to signal back to the source to ask for a repeat of the packet. This sort of thing is much easier with a multi-drop bus. An alternative is forward error correction. Look for Hamming Codes on the internet. Otherwise, you are going to have to discard bad packets.

Each controller will have to receive data into a buffer and detect when a complete packet has been received.

Each controller has two sources of data packets, the controller from which it receives and itself. When a controller has a complete packet from either source an sufficient room in the ouptut buffer, then a complete packet from either source shall be placed into the controller's output buffer.

Thanks for the suggestions.

How about the following method.

Each controller packs its 8 bytes data and the data received from previous controllers between 8 header bytes (all zeros) and 8 tailer bytes (all ones).

The first controller waits for X msec and then TX a header of eight zero bytes, then 8 data bytes and then 8 tailer bytes. Its RX-FIFO will be empty all the time.

The second controller waits for X msec and then TX a header of eight zeros, then the eight data bytes of previous controller from its RX-FIFO , then its own eight data bytes , and then 8 ones at the tail.

so on for all the controllers upstream.

Does this sounds like workable solution ?? Any reference code to implement this logic would be highly appreciated .

Thankzz && Bye
-Rocknmoon

Any sample code to implement a RX queue and a TX queue on a low end controller would be great.

I suggest that you look at:

http://www.keil.com/forum/docs/thread1352.asp

You will probably find other sources on the W.W.W.

As your packets are of fixed length, you don't need a start and end marker. If you can, use ASCII for your communications and perhaps choose line feed and carriage return for your start and end markers respectively. ASCII may seem inefficient, but it can make debugging a lot easier!

I suggest that your design should try to avoid using delay timers in the way that you suggest. Use timers to collect your data in real time and on time, but buffer everything else and receive/transmit when you must/can.

Good luck.

Keil interrupt-driver serial IO example also has ring buffers.
See the downloads area.

If you take CAN as back-bone for data exchange and 1 CAN to RS232 BRIDGE interface, you should be able to connect just anything to anything without breaking your mind for timing and speed ....


And to make things a little bit cheaper, you could perhaps convert all RS232 to RS485 and interface this to your PC.