| Author |
Topic |
|
|
Patrick
34 Posts |
 Posted - 23 Feb 2004 : 15:22:06
|
I've noticed this problem on and off in the past, but now it's permanent, and I hope someone has seen it, or has an idea about it.
When my code base exceeds some specific size, I begin to get comm port problems. I'm not sure what the measurement is, but I'm at a point now, that every line I add, causes it, no matter what those lines are, and if I remove them, the problem disappears. This only happens when I compile in debug mode, release is fine. Most likely, this is because there are no debug comments in the later case. The culprit line can be anything from a sprintf, to a function call. Doesn't matter, as if it's a line count, or code size issue. Could this be memory boundry related?
My problem is in comm port read code such as ReadFile(hCommPort,&inBuffer,1,&cBytes,0);
Pretty straight forward code, that normally works fine, but suddenly, after this magic point, those reads produce skewed results. All of the values are suddenly 64k higher value, constantly enough to correct for.
Please help, if you can! I'll be glad to try to explain better, if someone wants.
-Patrick
|
|
|
akidder
1519 Posts |
Posted - 25 Feb 2004 : 11:12:50
|
| Hi Patrick This sounds tricky for us to reproduce here. Why don't you give us a call and we can discuss how to move forward. -Drew |
 |
|
|
Patrick
34 Posts |
Posted - 26 Feb 2004 : 16:08:30
|
I ended up spending my day on a new Bitsy Plus issue, so I'll be calling you on that one, as well. Talk to you Friday.
-Patrick
|
|
|
|
Patrick
34 Posts |
Posted - 27 Feb 2004 : 14:19:16
|
Following Drew's advice, I printed the results of the comm reads in hex. When the reads work ok, I get the proper values. An A comes in as 41h, and 1 as 31h. When I am having trouble, they come in as FB41 and FB31. Not exactly 64k difference from the desired values, contrary to what I said in my earlier post.
The data is stored in a TCHAR type, which is really just an unsigned short and can hold 16bits, for Unicode characters.
The strange part, and what makes me think it's compiler related, is that if I put this line DEBUGMSG(TRUE,(_T("Big value!\n"))); after the ReadFile(), then the problem goes away.
Since it doesn't hurt me to have that line in, I intend to leave it there, and go on with my project. If anyone has any ideas, I'd love to hear them.
Thanks,
-Patrick
|
|
|
|
whuh
23 Posts |
Posted - 27 Feb 2004 : 15:02:35
|
Patrick,
By your first posting, the code reads from serial port is "ReadFile(hCommPort,&inBuffer,1,&cBytes,0);".
Is inBuffer declared as TCHAR and local variable?
If then, can you initialized to Zero (inBuffer = 0;) before ReadFile()?
Or, why don't you use 8bit variable (BYTE for instance) to declare inBuffer?
WH |
|
|
|
ctacke
877 Posts |
Posted - 27 Feb 2004 : 15:03:51
|
Patrick,
Your original post says you're doing this:
ReadFile(hCommPort,&inBuffer,1,&cBytes,0);
But your data is a TCHAR, which in CE has a defined size of 2 bytes. When you call ReadFile it is going to only use 1 byte of the 2-byte buffer you're passing in, the other byte's state is likely unpredictable at best. If you initialize it to zero before passing it in that *may* result in it staying zero on output, but you shouldn't count on it.
You should change your code to handle the correct amount of data you're expecting. Either use a BYTE or char ifthe sender is giving you a char or change the size to 2 [sizeof(TCHAR)] if the sender is giving you a wchar. |
|
|
|
Patrick
34 Posts |
Posted - 27 Feb 2004 : 16:44:43
|
Ok, so I modified the ReadFile to
ReadFile(hCommPort,&szText,1,&cBytes,0);
and added this
inBuffer[0]=0;
inBuffer[0]|=szText[0];
To get the single BYTE into a TCHAR. I couldn't see any conversion functions, nor casting that would do the trick, and this is the method they use in the Boling book. Is it overkill? I'm new to the whole multibyte/wide character scene.
It seems to work, but I'd like to be set straight.
Thanks!
-Patrick
|
Edited by - Patrick on 27 Feb 2004 16:48:30 |
|
|
| |
Topic |
|
|
|
All Forums
Microsoft Windows CE
Strange comm problem, may be compiler related
Forum Locked
Send Topic to a Friend
Printer Friendly