Serial Com problems after upgrading to XP Pro from Win2000.

Maj.Slayer

·· Hello, I wrote a program using DJGPP to go along with a stamp project I'm building. The program runs prefectly on ever other version of windows but runs very slow in Windows XP Pro(kinda goes fast one second, then slow the next very jerky performance). I'm using a BS2-p40(if that matters), I'm running at 9600 buad inverted. I'm
using CRC-16 for error correction, but bad data is still comming in somehow. The program or com data flow runs slow, almost as if something is starting·and stopping the data during transmission and receiving.·Thus causing te data to end up corrupt somehow.
·· I've checked my C++ program over·and cant seem to find anything wrong with the source·code. Its pretty simple code for the comms.· I'm not sure what to do, I've spent hours checking source code and it looks fine. Should I try a lower com port speed? Is there some sort of COM DLL I need for XP Pro? I'm lost as to what the problem is. Its wierd because the program works on every other version of windows. I know DOS is emulated in XP pro & Win 2000, so maybe thats the problem. Please if anyone has ran into the same problem and fixed it? Please let me know.. Also and "ideas" would be wonderful. Thanks.

································································ Sean T. Pinkerton

Jakob Selbing

That sounds a bit like the direct port access restriction in later version of windows. How do you access the ports in your software? I know there are drivers that allows software to directly access ports, e.g. giveio.sys and similar. Maybe you should try using one of those.

Also, I think running DOS software·under windows (especially later versions) probably can cause this kind of problems.

Other than that, I can only recommend that you make a very simple program that e.g. transmits and/or receives one byte without any error correction, simplest mode possible, and see if it works.

Maj.Slayer

Well I figured it out. I never considered flow control. My program was sending data to the serial buffer at such a high speed on my new computer, I think its filling up the buffer. I'm loosing data and thus causing the requested network packets from the stamp to return incorrect SRAM data from the wrong locations. I'm rewriting my DOS program to check the RTS pin before sending and adding the FCpin option to my SERIN commands in my stamp program. I pretty sure this is what is going on because I add a simple delay in the transmit a char function ( for(x=0;x<DEBOUNCE_SPEED_1;x++); printf(" \b"); ) this delayed the outgoing data and alerted me to the location of the problem. I'd like to thank you for your help. What an over sight ehh? thanx again,

Sean T. Pinkerton
(aka Maj.Slayer)