[Nut-upsdev] [RFC apcsmart V3 16/18] drivers/apcsmart.c: don't overuse UPSDELAY

[Michal Soltys]

On 11-03-06 18:35, Arjen de Korte wrote:
> 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).
>

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).