Re: [XForms] Xforms & threads-functions & others

[Sergey Klimkin]

Hi Alessandro,

> Probably I don't see the full picture but I don't understand why you
need multithreading.

Fuller picture looks so:
The program is intended for geodesists working in the fields. After
debugging at a workstation it will be transferred on the mobile device
(for example HP iPAQ-214 under control of OS Linux) therefore I am
guided in advance by "slow" processors). 
Absence in the program of the menu and very big buttons also are
connected with small display HHPC and work in field conditions.

My weak representation of details of work with external devices through
a serial port and almost full misunderstanding of a multithreading speak
very simply:
1. I not the programmer, I am a geodesist,
2. The previous my programs are written under OS Windows, and there is
only COM1, COM2..., COMn. I didn't reflect on multithreading, as the
environment of working out of the program (Pelles-C) without my
participation has given this possibility.
3. I use only 6 months Linux and only 3 months I try to master
programming (With without pluses) in Linux.

Probably multithreading not the most correct decision, but it that I
have found in examples for libraries GTK+ in Linux.
This method is quite efficient in the program which I have made in
Code-Block with use of libraries GTK+
Now (after very exact remarks Jens) multithreading also works in the
program with libraries xforms.
Program construction in style "server-client communication over the TCP
stack" represents for me interest. But I do not know as it should look.
Therefore, if it does not complicate you, some lines of a code on C-lang
(can be with lines of comments) will be the most clear help.

After connection with the external device (receiver or navigaror) is
established, the program accepts from it and writes down in a file the
continuous binary data flow with a reception interval in 1 second. For
this second it is necessary to execute parsing the accepted data and
still some mathematical transformations and to have time to write down
results in in 3 files (on an accessory of the data).

Practically all GNSS-receivers are arranged so that form the block of
messages and send this block through the fixed interval of time -
usually 1 second. To read from port on 1 byte too slowly. The program
should "see" that the called messages having headings and the
terminations are received. It considerably accelerates the subsequent
data processing.

At this time the user will be switched between program windows that:
1. To establish start and stop for record of each point chosen on
district,
2. To change if it is necessary height of the aerial of the receiver,
3. To look level of signals from visible satellities in a firmament,
4. To look an arrangement of satellities in a firmament.

I represent it as 2 independent problems. Thus an exchange of the
program with the receiver it is desirable anything both not to interrupt
in any way and not to stop at all.

08-10-2011 Terminal-log - example
---------------------------------
address@hidden:~/projects/fdesign/surveyfd$ ./survey
pixmap_file = /home/sklimkin/projects/fdesign/surveyfd/Garmin_iPAQ.xpm
Function comport() in separated thread is running...

PORTNAME=/dev/ttyS0

USER PORTSPEED=9600

WARNING! Press Ctrl+C to stop program!
16 bytes written to COM-port
Binary file: /home/sklimkin/projects/fdesign/surveyfd/fileout.bin
Bytes readed 537, found Garmin Message 0x33

2 Garmin commands is written!
605 bytes written in file
311 bytes written in file
311 bytes written in file
... ... ...
312 bytes written in file
Segmentation fault
address@hidden:~/projects/fdesign/surveyfd$ 

Depending on the receiver and from quantity of observable satellities,
these lines can be from 300 to 2000 bytes of the binary data.

605 bytes in the first line are 2 packages in the buffer serial-port.
The program has begun dialogue with the receiver in the line:
   sleep (2);  // in Sec
   BytesRead = read(fd, bRead, BUFSIZE);
For a confident finding of the message on that what receiver is
connected to port.

> You can use fl_add_timeout() or fl_add_timer() to invoke the state
machine if the comm. is very lengthy
If it does not complicate you, some lines of a code on C-lang (can be
with lines of comments) will be the most clear help.

> http://www.easysw.com/~mike/serial/serial.html#2_1
Yes it is the good document, thanks.

Sergey Klimkin.