[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