Communication / timing problem

[Aldo Cavini]

I noticed an error in the serial communication between a PBDOS program I wrote and an external device. Sometimes it seemed as the device didn't receive the polling record. Well, till now I knew there were all kinds of problems while receiving a stream (overruns, etc.), but this is the first time I had a Tx problem.

The problem is the following: I monitored the TX activity with a digital scope, and noticed that sometimes the Tx record duration is longer than usual. The record is 17 bytes, 4800 baud (8 bit no parity 1 stop): the total duration should be about 35ms, but sometimes the overall duration grows up to 50 ms and more. The TX stream is suspended for some 15 ms.

The device the PC is connected to manages a RX timeout: if a character doesn't arrive within 10 ms, the whole record is discarded. Hence, that 15 ms measured interruptions of the TX stream make the communication stops.

Of course for me it is a no-problem, since the program manages its own time-outs, and restarts the communication. I post this topic in case someone has the same kind of problem.

With the newer versions of Windows it is very difficult to run real-time applications... Will it be even worse in the future? The PC is a Pentium 300 MHz, Win NT4.0. Not too fast, but the same program works perfectly on a 486 66 MHz, both under a plain DOS 6.22, or as a Windows 3.11 shell.

------------------

[Tom Hanlin]

Windows wasn't designed as a DOS multitasker. 32-bit versions of Windows,
especially NT-based versions, do considerable work by way of emulating
the old 16-bit DOS environment. Compatibility can't be 100%.

If you want to work better with 32-bit Windows, you'll do better to skip
the middleman, and write actual 32-bit Windows code.

------------------
Tom Hanlin
PowerBASIC Staff

[Aldo Cavini]

Ok, I'm taking into consideration to convert the code to PB/CC plus GraphicTools. When? This is THE very difficult question to answer...

Well, I'm not sure the problem is within the 16 bit DOS emulation only. I tryed the following code (PB/CC 2.0):

FUNCTION PBMAIN
   
  COMM OPEN "COM1" AS 1
  COMM SET 1, BAUD     = 4800
  COMM SET 1, BYTE     =    8
  COMM SET 1, PARITY   =    0
  COMM SET 1, STOP     =    0
  COMM SET 1, CTSFLOW  =    0
  COMM SET 1, RTSFLOW  =    0
  COMM SET 1, XINPFLOW =    0
  COMM SET 1, xoutflow = 4800
   
  DO WHILE INKEY$ = ""
    PRINT ".";
    COMM SEND 1, "12345678901234567"
    SLEEP 200
  LOOP
         
END FUNCTION

and verified the TX stream with the digital scope. All seemed to run properly, until I moved another window in front of the program console. I saw Tx streams up to 10 ms longer than usual. (No other applications running: the test code and a plain 32 bit application window).

I can understand for an OS is not easy to perform real-time tasks. But the initial question remain untouched: with respect to the real-time world, Win 3.11 was worse than plain DOS, and Win 32 bit is worse than Win 3.11. Will be even worse in the future? IMO, no chances to meet real-time requirements below 50-100 milliseconds, whatever programming language you use.

[added later]

The test code was running while I posted this message. Better I don't mention what happened to the TX streams during the Internet communication and the Explorer window refresh...

------------------

[This message has been edited by Aldo Cavini (edited July 26, 2002).]

[Tom Hanlin]

32-bit Windows isn't designed to give individual apps real-time
performance to a high degree of precision. It would cause severe
constraints without any value to most applications. It may be that
you could get there with a device driver, I'm not sure.

It's possible to tweak various priority settings to improve the
performance of your program, or particular parts of it, but that's
not likely to be enough to get you there.

Sounds like what you're looking for is... DOS.

------------------
Tom Hanlin
PowerBASIC Staff