Serial comms: Error 57 due to GUI activity??

[Ketil Krumm]

I've been working on a serial comms data capture program for quite some time, and it is very near completion. The only issue left has me struggling, though:

The program can read data at different baud rates, 19,200 and 57,600 being the most common speeds. At 19,200 everything works fine, but at 57,600 I keep getting runtime error 57 whenever I move another app window, or the dialog of the app itself!!??!

To make things more interesting, apps like Notepad etc result in this problem - opening Notepad is fine, but if I start moving the Notepad window around I get error 57 while reading the serial port in my app. Other, expectedly heavier, apps like Word, Excel etc don't result in this problem, nor does any of the Windows "core" apps (Explorer, Control Panel etc).

It seems to me it might have something to do with how my dialog is defined (hParent is 0, equivalent of %HWND_DESKTOP) or opened (modeless), but I can't for the life of me figure this one out.

Any clues, anyone?? It sure would be appreciated... Just ask if you need more info - I just don't know what else would be relevant.

Thanks,
Ketil

[Scott Turchin]

I haven't done serial comm for a long long time, but I do have one question/suggestion.

57600 is not your data rate, ti's the baud rate, that's how fast you talk to the modem.
What brand of modem is it?
I don't know that you would experience that with a USR, and I'd be happy to test on my USR for you...
Lower it to 38400 and retest and see if the same issue occurs.

I've resolved quite a few issues doing this in the past....
57 is basically the modem choking...


Scott

------------------
Scott
mailto:[email protected][email protected]</A>
MCSE, MCP+Internet

[Ketil Krumm]

Scott,

Thanks for the suggestion, but this isn't a modem. It's a data concentrator of sorts, so 57,600 itself isn't a problem.

Anyway, I just got of the phone with the client, and their programmer solved it. She figured that since it was obviously GUI related, she'd try changing some of the GUI parameters. The first thing she tried was lowering the color depth from 16 to 8 bit (32K colors to 256 colors). That did the trick - the problem went away. Go figure...

Thanks again for your thoughts, though!

Ketil


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

[Eric Pearson]

Ketil --

Disclaimer: This is all based on speculation.

My serial comm programs used to have problems on DOS computers when the system got too busy. For example, I could create an error 57 at will, by performing a BLOAD operation while data was coming in at high speed. The explanation was that DOS (not my program or the compiler) was pre-occupied with performing a time-consuming single operation (the BLOAD) and in the meantime, a character got lost because the serial port was not being "serviced" often enough by DOS. The serial port actually receives data in a single byte, and if the operating system does not remove the byte and place it in the buffer before another byte comes in, that's an error 57. (Or at least one cause of a 57.)

So I would speculate that the same thing can happen on Windows systems. In spite of appearances, a single-CPU system can only do one thing at a time. While CPUs are much, much faster than they used to be, the operating system uses a large portion of that reserve power.

If you're using NT, start the Task Manager's "Performance Monitor" and minimize it to the System Tray. (I leave it there, full time.) It is a tiny "bar" indicator that tells you how busy the CPU is once per second. Drag a window -- any window -- around the screen for a few seconds and the indicator will rise. The larger the window, and the faster you drag it, the closer to 100% it will get.

I would also speculate that by reducing the color depth, various screen operations were simplified so Windows didn't have to load the CPU as much. On a slower CPU the problem might reappear.

You might consider doing something to "lock" the window while high-speed data is coming in.

-- Eric


------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Chris Boss]

Ketil;

Windows (95 and up) can have bottle necks for tasks like yours. This is why "Threading" is critical to tasks like yours. You have to prevent external activity from other apps from causing problems for yours.

I am not an expert on threading, but this much I know. Not only can Windows Thread processes, but it has a Priority scheme built in. You can define the priority level for a thread in your app, so it supercedes other threads.

Likely, you not only need to thread your code, but you need to create a thread with a higher priority level (lower number I think) than is used by most GUI code in other apps.

If there are any experts out there on Threading, you might want to pick up where I leave off !


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

[Eric Pearson]

Chris --

(Same disclaimer as above. I have not studied this topic since my DOS days.)

I may be mistaken, but I do not believe that using threads or changing the thread priorities in Ketil's program would have an effect on this problem. If I understand the way the system works, the program (Ketil's source code, the compiler, etc.) are not responsible for placing incoming characters into the serial port buffer. That is strictly a Windows "operating system" function that is handled in the background at a very low level. I could be wrong, but we are talking about a process that is very "close to the metal" here. It's probably the serial port driver that is generating the error, and it is being passed to Ketil's program. The driver is not actually part of Ketil's "process" or "thread", so he cannot change its priority.

Of course, somebody who is more current with this stuff may step in and tell me that I'm full of bits.

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Tom Hanlin]

The serial handlers in some versions of Windows are not very good. Commercial replacements are available. No, I don't remember from whom.

It might help to adjust the comm settings. Windows lets you adjust the low-level send and receive buffers. You could try higher and lower values than the defaults. These settings can be reached from Control Panel, depending on your Windows version-- try looking in the comm device and/or modem settings.

You may also wish to increase the size of the program's comm buffers. The buffering done through the Windows API is second-level buffering, distinct from the low-level buffering that is controlled through Control Panel. It rarely hurts to increase the size of the receive buffer. Note that various versions of Windows seem to have various undocumented restrictions on the maximum size of the receive buffer and whether the size must be a power of two. It will pay to get the buffer sizes from Windows after you set them, to make sure that the settings actually "took".

57,600 can push older hardware, which may be part of the problem?

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

[Scott Turchin]

I agree with Tom, and you should still be able to go to the properties of theserial port in Device Manager and adjust the communications rate down to 38400, try this one, then try 115200, both extremes but one will error more than the other and may give an indication of how to adjust this.
From there, if that changes it, you can programmatically change it through the registry and force a reboot if necessary to set the change.
I believe the key may be :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Serial

This is NT, may be the same in 95.

Anyway, just a thought, it's worth looking at but don't spend too much time there.

Is this just going through the serial port on the computer?

Scott

------------------
Scott
mailto:[email protected][email protected]</A>
MCSE, MCP+Internet