views:

299

answers:

1

I am designing software around an existing hardware product. I have full control of the communication protocol but I'm not sure how to facilitate device detection.

A device could have a range of possible configurations (i.e. baud rate, data bits, parity bits, stop bits) that must be detected at runtime. What is the easiest, most reliable way for the software to figure out what configuration it is using? Again, I have full control of the communication protocol so I can define any mechanism I wish.

+2  A: 

Is this a full-duplex or half-duplex device? Can you control request-to-send and monitor clear-to-send on both ends of the serial line? Is the serial line point-to-point (like RS-232) or multi-drop (like RS-485)? It will make a (albeit small) difference if you are going to interfere with other already connected devices while negotiating with a newly connected one.

If you think of the handshake process like a modem negotiating a link layer protocol, it uses a standard set of messages to describe the type of communications it would like to have and waits for an "ack" from the other end. In your case I recommend having a "let's talk" standard message that your head end generates with the range of bit rates and waits for the ack from the device.

I also recommend reducing the number of configuration options for the device. Forget about variable data bits, parity bits, and stop bits. The serial communications world is no longer as unstable as it was back in the 70's. Just use 8 data bits, no parity, one stop bit and vary the bit rate. A CRC on the end of messages provides plenty of error-checking.

Joel
Right now I'm looking at full-duplex RS-232 but RS-485 looks interesting. What difference does the duplex and controlling request/clear-to-send on both ends make? Can I start communications using a required configuration and change to the preferred configuration on-the-fly without disconnecting?
Gili
Full duplex is about simultaneously sending and receiving protocol data units (messages). RTS/CTS are simple ways of signaling message exchange start/continue signals, like a one bit msg. You can absolutely start slow and ramp up to what the link can handle before the error rate gets too high.
Joel