On 11-03-06 18:35, Arjen de Korte wrote:
Citeren Michal Soltys <[email protected]>:
This delay is meant for multicharacter commands, besides
we always guarantee delay by other means - so do the stuff properly.
[...]
upsdebugx(1, "On-line - forcing OB temporarily");
ser_send_char(upsfd, 'U');
- usleep(UPSDELAY);
Sleeps for 50ms.
+ ser_get_line(upsfd, temp, sizeof(temp), ENDCHAR, IGNCHARS,
SER_WAIT_SEC, SER_WAIT_USEC);
Waits for a newline character to arrive for up to 3 seconds (which is
quite a bit longer).
[...]
- usleep(UPSDELAY);
- ser_flush_in(upsfd, IGNCHARS, nut_debug_level);
Sleep for 50ms and discard any character we have received in the mean time.
+ ser_get_line(upsfd, temp, sizeof(temp), ENDCHAR, IGNCHARS,
SER_WAIT_SEC, SER_WAIT_USEC);
Waits for a newline character to arrive for up to 3 seconds (which is
quite a bit longer).
In comparison for the earlier patch, I opted for switching to "full"
ser_get_line(), as I don't really know if just UPSDELAY (50ms) is enough
in each possible case. UPSDELAY was added (by the original authors) for
send_pace commands only, so I decided my initial patch was a bit too
optimistic.
'U' always [should] responds with 'OK' or 'NA', so I wanted to eat the
reply (disregarding success or failure), before analyzing further reply
from 'S'.
Similary in the latter case - aborted "hack" version of '@' will
generally respond with 'NO'.
Note that if you use a text protocol (which seems to be the case here),
canonical mode input processing may be a huge time saver:
http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#_delays_and_ser_functions
http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#_canonical_input_mode_processing
Using canonical input processing eliminates the need for delays between
sending commands and reading back the reply line (and prevents an
endless amount of selects when not all data is available on the first try).
It's certainly good idea, though I'll have to test it carefully, if it's
really applicable (as, do every command / variable really end with \n).
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
