Re: SerialPort.Open [Polling]?

[Claus Dietrich <claus.dietrich@xxxxxxxxxx>]

Am 06.06.24 um 10:49 schrieb BB:
> 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

To me it seems that there are misunderstandings about the function of 
serial interfaces. The application doesn't have to poll for change 
events. A change event is raised instantly when things happen. Hardware 
handshake lines are hardwired and used between two UARTs. However, there 
are handshake events which are useful for an application. But they must 
be available instantly and not be subject to a polling cycle. I use 
hardware handshake lines in most of my practical applications and even 
my simple demo app in the Gambas-Buch supports it. So low level 
handshake lines are not meaningless at all. RTS/CTS handshake lines are 
also not used to detect whether a counter station is dead. This is done 
by the DTR/DSR handshake lines. RTS/CTS handshake lines are used to 
avoid communication buffer overflows and are very important.

The change event handler also doesn't "enable" low level control. It is 
enabled by the property SerialPort.Handshake.

To be more clear: If Gambas really checks hardware handshake lines by 
polling, I would have a serious problem.

Regards

Claus