You can ask Tk to run a specified routine periodically: $widget->repeat(milliseconds, callback);, like perhaps: $widget->repeat(500, \&update_serial_info); This will cause Tk to call update_serial_info() every 1/2 second - the Tk code continues executing immediately after this "request".

In the update_serial_info routine, you should use non-blocking calls to the serial port S/W. If the Tk display is not ready to be updated, then don't do anything. If the data is "ready" perhaps you just put the data into some $text_variable that the GUI knows about. If the info received so far warrants a display update like a text window pane, then do that being aware that updating the GUI is very "expensive" compute wise. You probably don't want to do that for every single individual character received! This Serial Port code may run just fine without being in a separate thread if you call it every 200ms or so (maybe less, maybe more).

A key is to call the non-blocking serial port methods. If there is nothing to be read, then just don't do anything. That will happen most of the time, so make that path fast.

You can ask Tk to run a specified routine periodically: $widget->repeat(milliseconds, callback);, like perhaps: $widget->repeat(500, \&update_serial_info); This will cause Tk to call update_serial_info() every 1/2 second - the Tk code continues executing immediately after this "request".

Following your advice I wrote a simple module which uses POSIX and sends time stamps to the GUI window:

my @localtime=localtime; 
my $hour=strftime ("%d.%m.%Y  %H:%M:%S", @localtime);
our $receive_T->insert('end',$hour."\n");
[download]

I define a text widget in another module where it calls the above module and writes time stamps into the text widget:

$receive_T = $receive_Tk->ROText(-relief=>'groove',-width=>72,-height=
+>20,-font=>'Courier 8 bold')->pack(); 
$receive_T->repeat(5000,\&Receive2);
[download]

In the update_serial_info routine, you should use non-blocking calls to  the serial port S/W. If the Tk display is not ready to be updated, then  don't do anything. If the data is "ready" perhaps you just put the data  into some $text_variable that the GUI knows about. If the info received  so far warrants a display update like a text window pane, then do that  being aware that updating the GUI is very "expensive" compute wise. You  probably don't want to do that for every single individual character  received! This Serial Port code may run just fine without being in a  separate thread if you call it every 200ms or so (maybe less, maybe  more).

A key is to call the non-blocking serial port methods. If there is  nothing to be read, then just don't do anything. That will happen most  of the time, so make that path fast.

I took one of rare examples for serial communication  I could find and which actually worked without GUI.

Since there are no more laptops with RS232 port I use a USB adapter and one of my modules uses mode from DOS which detects COM port and sets parameters, then opens the COM port.

I admit I'm not capable to implement the non-blocking calls  in the below lines - maybe it's because of the fact I'm not a programmer or the Win32::SerialPort documetation is too short - so I'm asking for some additional help.

#!/usr/bin/perl
use strict;
use Pod::Usage;
use Getopt::Std;

our $RECEIVED;
our $PORT;
my $x;
our $receive_T;
our $ob;
my $timeout;

sub Receive{
        
    while(1){
        $RECEIVED = ReadPort($PORT, 5);
        if($RECEIVED ne ""){
            print "\t$x\tRX>\t$RECEIVED\n";
            $receive_T->insert('end',"\t$x\tRX>".$RECEIVED."\n");
            $x++;
        }
    }  
}

sub ReadPort{
    
    # Store timeout time in millisecond tic    $timeout = $ob->get_tic
+k_count + (1000 * $timeout);
    $ob->lookclear;  # Clear lookfor buffers
        while(1) {
    
         # polls until we have a line of data
        # return unless ( defined ($gotit = $ob->streamline) );
        if ($RECEIVED ne "") {
            my ($found, $end, $obattern, $instead) = $ob->lastlook;
            
            return "$RECEIVED";
        }
        # or an error
        return if ($ob->reset_error);
        if ($ob->get_tick_count > $timeout) {
            my ($match, $after, $obattern, $instead) = $ob->lastlook;
            return ;
        }
    } 
}
[download]

Thanks in advance for your help.

Marjacktablet

Yes, these simple USB to pseudo RS-232 devices can work well. It depends upon what you are talking to. The typical limitation is that voltage swing is only +-5 volts where "real" RS-232 requires +-12 volts. Sometimes cheap devices don't go sufficiently negative (<-3V) for a valid "mark" level and some devices allow invalid voltage ranges to be "counted". I have seen cases where that wasn't good enough, but usually it is. There can be other issues between manufacturer's in how close the device comes to actually performing like a "real" RS-232 I/F chip would, but I think at this stage, you are just trying to get the basics working and that your particular USB->serial gizmo is "good enough".

Update: The incompatibility issue with voltage levels is complicated. see next post for more discussion of this.

I haven't ever used Perl to talk to a RS-232 device on Windows, but have done it in other languages and other O/S'es.
Yes, you are correct that the documentation does leave a lot to be desired! I hope that further explaining things on the conceptual level will be helpful to you and enable you to experiment further.

The reason to use non-blocking calls is that you don't want your GUI to "freeze" and become unresponsive to mouse clicks. If the processor is off in serial port la-la land, then it won't be processing GUI events. I will allow that perhaps you get a version working with blocking calls and then come back later and refine that so that the GUI doesn't "Freeze". However a lot of applications have some kind of "Stop", "Restart", "Abort" button and you want that button to "work" when needed!

I presume that you got the timed routine to display something every 1/2 second? $receive_T->repeat(5000,\&Receive2); While the processor is running Receive2(), it is not processing GUI events. As long as Receive2() runs fast enough, the user won't notice any difference in the GUI at all. In this case, Receive2() does some simple job and then returns way faster than a human is even physically capable of fully pushing a mouse button. We want the same thing (really fast return to GUI business) to happen with the serial port polling routine.

From the documentation:


$gotit = $PortObj->streamline;        # poll until data ready
$gotit = $PortObj->streamline($count);# block until $count chars recei
+ved
    # fast alternatives to lookfor with no character processing
[download]

If you use the 2nd call which specifies a $count, the processor will stay inside of the streamline() method until that number of characters are received. If the thing you are talking to is not particularly chatty, that could be an entire day! 9600 baud is about 1 char/ms. By comparison it takes maybe 50ms for you to blink your eyes. If I am stitching together voice prompts and there is more than about a 20ms variation between segments, you can hear the difference quite easily. So if your application is a stimulus/response situation, say you send a 6 byte command and get back a 10 byte fixed length response, the blocking I/F could still work out ok, because xmit,rcv and processing is less than 20ms and that is so fast the human won't know that the GUI wasn't working during that 20ms interval. Note: there does appear to be a mechanism to abort blocking calls after a specified timeout.

Now if you are listening to be asked to do some command, you might wait for days before a 6 byte command shows up. The user will definitely know that the GUI has gone "bye-bye" while it is waiting for this command to arrive via the serial port.

The first of these reading methods, $gotit = $PortObj->streamline; works differently. The documentation is poor, but my guess is that you either get: undef, "" (null string) or some number of characters in the string, "abc". In this case, streamline() will return its result right away without any "waiting". I suspect (without any documentation) that undef means that some kind of error occurred. I presume most of the time you will get "", null string, no character received and then there is nothing to do. If you are polling every second, there could be 1,000 characters there.

So for Receive3(), untested of course,

at the top of your code, put: $|=1: # turns off buffering for print()
sub Receive3
{
    my $gotit = $ob->streamline;
    die "got undef from streamline! $!" if (!defined ($gotit));
    return if ($gotit eq "");  # nothing to do - no chars received
    print "$gotit";            # blocking call, but "fast enough"
                               # actual code would do something with $
+gotit
                               # put it in a buffer and decide if it i
+s enough for
                               # a complete command or whatever...
}
[download]

So when using non-blocking I/O polling, there will not be any while(1){} loop. That is an infinite loop and you could be in there for a long time! I think undef means an error that shouldn't be ignored? This code will find out whether that is true or not. I just printed to the console. You know how to update the GUI and I leave that part to you with the guidance that updating the GUI is a very "expensive" operation - meaning consumes lots of MIPS. Maybe you don't want to update the GUI on a per character basis? However, here it could very well be that it is just fine to do an update per character. Just making you aware that the GUI is "expensive". I've seen programs that spend fully 1/2 of the computer power updating a progress bar too often. When updating the display only when it will change dramatically increases performance.

Ok, now call Receive3() at some interval (which I think you know how to do now) and see what happens.

The serial port package has all sorts of tricky "wait for X to happen" features. Those are blocking calls. You may wind up having to do some of these functions yourself. I have no idea what my ($found, $end, $obattern, $instead) = $ob->lastlook; does.

Update: I don't think that you need to use threads. If you used a separate thread for the serial port, then you could put in blocking calls because even if that thread "blocked", it would not freeze the main GUI thread. But you would still need the paradigm of a non-blocking call to ask the serial port thread whether it had some result to report or not. I think you will be fine with a single thread as long as you don't have any while(1){} loops.

Update2: I am not sure what your moniker of "Marjacktablet" means, but I suggest that you register as Monk - that process is free and non-fattening. There are a lot of advantages to being a "registered user". When you post as just "anonymous Monk", it is hard for me to see perhaps other perhaps related questions and responses that you have had. When I post a direct response to your question, you will be able to see that you have a new reply without having to find the exact thread from x days ago. So there are advantages and I recommend you do it.

Loosely related example:

SDR Scanner(aka Threaded wxPerl Example)

James