I have created a Windows program with a dedicated thread that transfers data between FSUIPC and the serial port. This thread yields to other processes (e.g. FS) whenever the serial port is busy transmitting or receiving a block of data (synchronous, non-overlapped I/O).
Currently, I'm updating FSUIPC variables at a rate between 2 and 20 Hz using C code that looks like this (the program is based on the BCB example in the FSUIPC SDK and I'm using FS2002):
FSUIPC_Write(0x3ae8, 8, &throttle_L, &dwResult);
FSUIPC_Write(0x3a28, 8, &throttle_R, &dwResult);
FSUIPC_Write(0x3af0, 8, &mixture_L, &dwResult);
...
[Another 10 R/W requests]
...
FSUIPC_Read(0x0574, 4, &alt, &dwResult);
FSUIPC_Read(0x02c8, 4, &vsi, &dwResult);
I noticed that the FSUIPC_Process() function takes a while to complete. On the other hand, it seems to return almost instantaneously when FS stops processing (when e.g. the FS menu bar is popped up using ).
What is the typical request completion time ? Does it strongly depend on the number of requests in the transfer frame ? Should I consolidate a few variables in a larger block ? I'm planning on posting FSUIPC requests in a more intelligent way, omitting FSUIPC_Write()s with (nearly) the same values. Is this worth the while, given the fact that data copying shouldn't take more than a usec on Pentium IV ? Perhaps some synchronization mechanism with FS is executed for each request in the frame ?
Finally, I must congratulate the creator of FSUIPC for developing an excellent piece of software. It's stable as a rock and very easy to program with. If you need to read or write FS data, I wouldn't even consider the option of writing a DirectInput driver or module .dll anymore.
Thanks for your support,
Jeroen.