[Gambas-user] Serial Port Change Events Not Working after Upgrade to Karmic

[Tony]

   Thanks Benoit and all for your speedy replies..
   I'm using the serial port in a timing application with 3 laser through beam
   sensors feeding into the CTS, RI and DSR lines of the serial port. In this
   mode I don't pass any data, don't really care about flow control and am only
   interested in the raw status change events. Working this way I haven't
   noticed gross CPU utilisation after opening the port.  The application also
   uses the UDPsocket to communicate remotely and what I have noticed is that
   if the serial port does not open correctly e.g. "/dev/tty" wrong and the
   UDPsocket is open, then there is a large amount of CPU used. Both open
   correctly and CPU normal.
   Can you tell me the polling frequency in Gambas2 2.8 ?
   I would assume that there ore other users of Gambas2 who are using the
   serial  port  as  a  convenient  way of passing external events to the
   application, so maybe some input from them would also be in order. As long
   as there is a mechanism to replicate the Gambas2 2.8 functionality that I
   currently use, I'll leave the implementation up to those who know a lot more
   than myself. If going back to polling, a property to define the frequency
   would be nice.
   Thanks again,
   Tony.
   Benoît Minisini wrote:

   Thanks for the suggestion Ricardo.
   I have already compiled G2.18 from source onto Ubuntu 9.04. The
 application was working fine on Ubuntu 9.04 with G2.8 but fails with
 G2.18, so this makes  me think that there is a problem which may have been
 introduced between G2.8 and G2.13 (the binary on Ubuntu 9.10 which doesn't
 work). Regards,
   Tony..
    

You are right, and I think I understand what happens:

I have noticed that SerialPort callback took too much CPU, because it was 
using polling on the serial port file descriptor. 

So I fixed it by awaken it only when there is some data to read... Mistake! 

I didn't understand that all DTRChange, DSRChange... events are not detected 
by the kernel. So Daniel (who wrote the code) had to use polling to be able to 
detect the changes.

By removing the polling, I was able to raise the Read event without burning 
CPU, but all *Change events were not raised anymore!

Now I have to find a good fix, but I have never used a serial port, so I need 
some enlightenment (no, I won't run E17...)

- Why do you need detecting DTR,DSR... changes?
- How are these events related to flow control and the FlowControl property?

The last question is not innocent. the FlowControl property takes three 
different values: Hardware, Software, Both. 

I'm thinking adding a fourth value, "None", that means the user does not care. 
In that specific case, I will not poll, and *Change events won't be raised.

So you will be able to decide:

- Setting FlowControl to None. You will get the Read event only, but you won't 
burn CPU power.

- Setting FlowControl to any other value. You will get all events, but you 
will have to poll.

This change would be compatible with the current SerialPort interface.

Otherwise, for Gambas 3, maybe I will add a new property to define how much 
polling is needed.

What do serial port people think about that?