Re^2: pattern detection inside until loop in perl

Replies are listed 'Best First'.
Re^3: pattern detection inside until loop in perl by Marshall (Canon) on Dec 19, 2010 at 06:09 UTC
Communicating 2-way over a serial port in a simple, reliable way is actually a lot more complicated than it sounds! The crux of the matter is that there is no "end-to-end" protocol like TCP/IP. This is low level. You send out bytes. You listen for bytes. There is no guarantee that what you sent is what was received. In either direction it is possible that characters are deleted, inserted or transposed into other characters - this is due to how the hardware works. You don't send "messages" and listen for "messages". You have to deal with streams of raw characters sent and received. For sending, perhaps you send the string: "CMD=save\n" and that gets received as: "CMD=sav@#". If the listener is waiting for "\n", to signal the "end of incoming message", then there is going to be a problem! Probably you have to resend: "CMD=save\n" due to no response within some time out period. The listener maybe then sees the "\n" and parses its incoming command line as: "CMD=sav@#CMD=save\n", well that may not work out so well. Without knowing more about the protocol between the computer and the external device, I can't help more. Most of these communication protocols are fairly "stupid": send one line, get one line. But even that can get complex when the "receiver" doesn't get the "line" that was sent (meaning that the line termination character was missed) and you have to re-send the line.	[reply]

Replies are listed 'Best First'.

Re^3: pattern detection inside until loop in perl
by Marshall (Canon) on Dec 19, 2010 at 06:09 UTC

The crux of the matter is that there is no "end-to-end" protocol like TCP/IP. This is low level.
You send out bytes. You listen for bytes.

There is no guarantee that what you sent is what was received. In either direction it is possible that characters are deleted, inserted or transposed into other characters - this is due to how the hardware works.

You don't send "messages" and listen for "messages". You have to deal with streams of raw characters sent and received.

For sending, perhaps you send the string: "CMD=save\n" and that gets received as: "CMD=sav@#". If the listener is waiting for "\n", to signal the "end of incoming message", then there is going to be a problem! Probably you have to resend: "CMD=save\n" due to no response within some time out period.

The listener maybe then sees the "\n" and parses its incoming command line as: "CMD=sav@#CMD=save\n", well that may not work out so well.

Without knowing more about the protocol between the computer and the external device, I can't help more.

Most of these communication protocols are fairly "stupid": send one line, get one line. But even that can get complex when the "receiver" doesn't get the "line" that was sent (meaning that the line termination character was missed) and you have to re-send the line.

[reply]