[Nut-upsdev] [RFC apcsmart V3 16/18] drivers/apcsmart.c: don't overuse UPSDELAY
Arjen de Korte
nut+users at de-korte.org
Sun Mar 6 17:35:15 UTC 2011
Citeren Michal Soltys <soltys at ziu.info>:
> 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).
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).
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
More information about the Nut-upsdev
mailing list