Re: SerialPort.Open [Polling]?

[BB <adamnt42@xxxxxxxxx>]

On 6/6/24 5:04 pm, Claus Dietrich wrote:
> Hi Lee and Benoít
>
> I can't agree with the current editing and assume that there is still 
> a misunderstanding.
>
> The polling of handshake lines doesn't make any sense to me. These 
> lines have to be handled on the spot and can't be subject to polling 
> cycles. All handshake lines must be treated immediately upon the 
> occurance of an interrupt provided by the UART.
>
> I rather believed, that your first assumption was correct. That means 
> that the presence of received data is indeed checked in a cycle 
> defined by the polling parameter. Since Benoit didn't reply to my 
> question about the detection criteria I am assuming that data are 
> always received byte by byte and put into the buffer.
>
> I also wouldn't say, that "polling is not used when xxxChange events 
> are handled". The use of change events only make sense, if the 
> FlowControl property is set accordingly.
>
> Please apologize that I don't have the competence to fully understand 
> the c-code behind the SerialPort class and I might be entirely wrong, 
> but based on my assumption I would rather have amended the follow to 
> the documentation:
>
> "The optional polling parameter is used to adjust the polling rate for 
> received data in ms. If no parameter is used the default polling rate 
> of 50ms applies. If data are received during the polling cycle they 
> are made available in the Read event handler. Take note that polling 
> is not used when the property Flowcontrol is set to Hardware."
>
> Take this as a counter proposal. Any comment/ correction would be very 
> welcome. We just should try to get it right (also for the Gambas-Buch 
> ;-)).
>
> Regards
>
> Claus
I think the confusion here is what "polling" means. In this case it 
means "intervals between looking at the hardware flow control values in 
the local UART". It has nothing to do with the actual data flows which 
are entirely handled by the local and distant UARTs themselves. That is 
true whether hardware or software flow control is used.

a) when hardware flow control is being used ...

You are probably correct that the hardware flow control interrupts, if 
they are being used, have to be handled on the spot and they probably 
are, inside the low level handlers. But how often do we, at the upper 
level want to look at whether these control lines have changed? 
Continually, now-and-then, never? It seems to me that Gambas is offering 
these choices. You can implement XXX_Change event handlers which then 
"enable" the low level code to raise events when the respective control 
line value changes. Alternatively you can "poll" the (logical) UART now 
and then using the polling interval to see if one or more of the control 
line values has changed. Finally you could do nothing and let the lower 
level parts (software and hardware) worry about the whole thing themselves.

So why bother about these asynch flow control lines anyway? The most 
obvious reason is to check that the distant device is still there. Say 
the distant device is disconnected, the distant CTS line voltage drops 
to zero and thus the local RTS is dropped.... and stays dropped for a 
significant time... we can thus deduce that the "patient" has died and 
there is no more need to send anything to it or indeed try and see if it 
has sent any data to us. Other reasons exist.

b) when software flow control (XOn/XOff) is being used ...

None of the flow control lines are being used. There will be no flow 
control events. So asking the low level things about the state of these 
lines is meaningless. Thus the polling parameter is useless and need not 
be set.

regards

b