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

[Denniston, Todd A CIV NAVSURFWARCENDIV Crane]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
> On Behalf Of Sergey Klimkin
> Sent: Monday, October 10, 2011 15:06
> To: address@hidden
> Subject: Re: [XForms] Xforms & threads-functions & others
> 
> 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.
> 

There are two things I would suggest you look at for the work you are doing, as 
they *MAY* make your work easier. 

1) fl_add_io_callback, which allows you to get input from io devices, *when* 
the devices have input to give. 
 http://xforms-toolkit.org/doc/xforms_6.html#SEC35

2) gpsd, which will take input from several kinds of gps/AIS/navigation devices 
and output it in one consistent format, plus at the same time keep your Network 
Time Protocol in sync.
  http://www.catb.org/gpsd/
  http://gpsd.berlios.de/
  https://savannah.nongnu.org/projects/gpsd



<SNIP>
> 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.
> 
<SNIP>