rs232? Again....

Hello,

I have had success doing rs232 where my cpu can read from my PC. I am now
trying to get my PC to read from my cpu. I had success on this also, 2 months
ago at reading 8 bytes into the PC end. Everything was fine, however, today I
had the uncontrollable urge to try to read 9 bytes!!!!!! Well guess what?
back to the drawing board I am!

:-)


I want to ask a very simple question and go step by step! Because I though I
understood what I was doing 2 months ago after extensive research on the
subject, but I am obviously wrong!

On my cpu end, I am sending a string like this:

///////////////////////////////////////////////////////////////

char RS232_1_ExtOut[] = "ABCDEFGH";

for(i=0;i<7;i++)
fputc(RS232_1_ExtOut[i],COM_1);
/////////////////////////////////////////////////////////////

As you can guess, this sends a string of eight characters out on com 1 of
the cpu!

Now, on the PC side (VC++) I have:

///////////////////////////////////////////////////////////////////

static DWORD dwBytesRead = 8;
static BYTE abBuffer[9];
int TEMP;

MySerial.Read(abBuffer,sizeof(abBuffer),&dwBytesRead);
TEMP++;

//////////////////////////////////////////////////////////////////

Okay, I have a break point on the "TEMP++;" line!

For starters, ain't I supposed to read 8 bytes max, hence the variable
dwBytesRead?

And, abBuffer has enough room to hold the total amount of bytes read plus a
null termination character. Right!

So why, at this particular moment at breakpoint time! , abBuffer contains,

"ABCDEFGÃ?Ã?"

2 Months ago when I got this to work, in the cpu code, I used to send a null
character "\0" after my string. I stopped doing this, because I realized it
didin't have any effect.

I have been told before by news groups fellows that rs232 returns many
bytes, but isn't the purpose of the:

MySerial.Read(abBuffer,sizeof(abBuffer),&dwBytesRead);

function, supposed to limit the amount of bytes read to the value passed in
the 3rd parameter?

All suggestions and help is very appreciated!

P.S. Does anyone know where I can get documentation describing all of the
Serial class.... I tried to ask this to the author, but got no response!!!

--
Best regards
Robert

Stuart
Thu Sep 21 02:18:24 CDT 2006

Robby wrote:

[snipped rather confusing explanation of problem that OP wants to
communicate with some other PC]
>
> On my cpu end, I am sending a string like this:
>
> ///////////////////////////////////////////////////////////////
>
> char RS232_1_ExtOut[] = "ABCDEFGH";
>
> for(i=0;i<7;i++)
> fputc(RS232_1_ExtOut[i],COM_1);
> /////////////////////////////////////////////////////////////
> As you can guess, this sends a string of eight characters out on com 1 of
> the cpu!
>
> Now, on the PC side (VC++) I have:
>
> ///////////////////////////////////////////////////////////////////
>
> static DWORD dwBytesRead = 8;
> static BYTE abBuffer[9];
> int TEMP;
>
> MySerial.Read(abBuffer,sizeof(abBuffer),&dwBytesRead);
> TEMP++;
>
> Okay, I have a break point on the "TEMP++;" line!
>
> For starters, ain't I supposed to read 8 bytes max, hence the variable
> dwBytesRead?

Nope. This parameter tells you how many bytes could have been read from
the communication port within the given time limits. If you try to read
from a device you don't know how many bytes you are going to get, thus
you use this variable.

> And, abBuffer has enough room to hold the total amount of bytes read plus a
> null termination character. Right!

Wrong again. Reading from the serial port means reading a stream of
bytes, not a string. Thus you don't get a Null terminator that is
usually used in C++ to delimit strings, but only the raw bytes that
represent the characters of your string. To determine the length of the
string you have to use the third parameter of the call. If you want to
use the buffer as if it were a string, you have to insert the null
delimiter _yourself_!

> So why, at this particular moment at breakpoint time! , abBuffer contains,
>
> "ABCDEFGÃ?Ã?"

See above, no automatic C string delimiter.

> 2 Months ago when I got this to work, in the cpu code, I used to send a null
> character "\0" after my string. I stopped doing this, because I realized it
> didin't have any effect.

Yes, thats funny. Since you send strings, you tell the communication
handler to send an empty string, IOW nothing at all. Note that you send
strings, but receive byte arrays that must be converted to strings by hand.

> I have been told before by news groups fellows that rs232 returns many
> bytes, but isn't the purpose of the:
>
> MySerial.Read(abBuffer,sizeof(abBuffer),&dwBytesRead);
>
> function, supposed to limit the amount of bytes read to the value passed in
> the 3rd parameter?

Nope.

> All suggestions and help is very appreciated!
>
> P.S. Does anyone know where I can get documentation describing all of the
> Serial class.... I tried to ask this to the author, but got no response!!!

Most of these classes are just very, very thin wrappers around the
standard way of communicating with serial ports via the Win32 API
functions CreateFile, WriteFile, ReadFile, and CloseHandle. I'd suggest
to read the documentation of these functions, specifically the function
SetCommTimeout. I have downloaded a wrapper class from
www.codeproject.com/system/cserialcom.asp. This class contains the
implementation as well, which would be a good point for you to start
reading how to commincate with serial ports.

Regards,
Stuart

Scott
Thu Sep 21 08:06:03 CDT 2006

Robby wrote:
> So why, at this particular moment at breakpoint time! , abBuffer contains,
>
> "ABCDEFGÃ?Ã?"
>
> 2 Months ago when I got this to work, in the cpu code, I used to send a null
> character "\0" after my string. I stopped doing this, because I realized it
> didin't have any effect.
>
> I have been told before by news groups fellows that rs232 returns many
> bytes, but isn't the purpose of the:
>
> MySerial.Read(abBuffer,sizeof(abBuffer),&dwBytesRead);
>
> function, supposed to limit the amount of bytes read to the value passed in
> the 3rd parameter?

No. The third parameter is for the reader to tell you how many it read.
There won't be any nul terminator in the array unless you put one
there, either by sending and receiving it, or by a line of code
immediately after the read.

--
Scott McPhillips [VC++ MVP]

Robby
Thu Sep 21 12:29:01 CDT 2006

Hi,

Thankyou guys for answering my post.

From what I understood:

-The third parameter of the MySerial.Read() function is to tell me how many
bytes were read. Okay!

-No null terminator is included in my transmission, so I must append one,
either by sending and receiving it, or by a line of code immediately after
the read. Okay!

-In Byte abBuffer[], I won't be appending a null character here, since I am
just reading bytes into it. Right! Okay! So in other words I will just use
it to read in the bytes.

Unfortunately, I just keep getting unwanted data into abBuffer[] ???

Here is what I have reduced the code to:

On the cpu side:
///////////////////////////////////////////////////////////////////////////////
int yyy;
char RS232_1_ExtOut[] = "ABCDEFGH";
fputc(RS232_1_ExtOut[0],COM_1); //Outputing *just* the 'A'
yyy++; //<<<<<Brreakpoint here!
////////////////////////////////////////////////////////////////////////////////

At the PC side (VC++):
/////////////////////////////////////////////////////////////////////////////////////
int xxx;
static DWORD dwBytesRead = 0; //Set to 0 as default value!
static BYTE abBuffer[1]; //Just want to read the 'A' right?
//static char abBuffer[1]; //Test

MySerial.Read(abBuffer,sizeof(abBuffer),&dwBytesRead);
xxx++; //<<<<<Brreakpoint here!

////////////////////////////////////////////////////////////////////////////////////

At the break point, why do I read a 'â?¡' in abBuffer instead of 'A' ???
Also, at this point, dwBytesRead, indicates 1 ! So this means it did read
*one* byte, however not the one I sent. right?

And since my buffer is of byte type ex: A = (01000001), Should I see a 'A'
in abBuffer or the ascii code of 65?

In any case I read the bizzard 'â?¡' symbol!

I am not too familiar with the time outs of rs232, maybe, its a time out
issue, I tried the:

CSerialWnd::EReadTimeoutNonblocking;

and also, from the Code Project documentation... I also tried:

MySerial.SetupReadTimeouts(CSerialWnd::EReadTimeoutNonblocking);

to not have any time out or not to block anything, but no luck!

I sincerely would appreciate any other suggestions, on this issue!

Thanking you guys for your continuous support! Hell I know I need it! :)

--
Best regards
Robert


"Scott McPhillips [MVP]" wrote:

> Robby wrote:
> > So why, at this particular moment at breakpoint time! , abBuffer contains,
> >
> > "ABCDEFGÃ?Ã?"
> >
> > 2 Months ago when I got this to work, in the cpu code, I used to send a null
> > character "\0" after my string. I stopped doing this, because I realized it
> > didin't have any effect.
> >
> > I have been told before by news groups fellows that rs232 returns many
> > bytes, but isn't the purpose of the:
> >
> > MySerial.Read(abBuffer,sizeof(abBuffer),&dwBytesRead);
> >
> > function, supposed to limit the amount of bytes read to the value passed in
> > the 3rd parameter?
>
> No. The third parameter is for the reader to tell you how many it read.
> There won't be any nul terminator in the array unless you put one
> there, either by sending and receiving it, or by a line of code
> immediately after the read.
>
> --
> Scott McPhillips [VC++ MVP]
>
>

Scott
Thu Sep 21 14:06:18 CDT 2006

Robby wrote:
> And since my buffer is of byte type ex: A = (01000001), Should I see a 'A'
> in abBuffer or the ascii code of 65?
>
> In any case I read the bizzard 'â?¡' symbol!

I would guess that this is just one more case of confusing yourself and
the debugger by not terminating the buffer, and/or attempting to
interpret it in a UNICODE app. What do you mean by "see"?

Since it is not a nul terminated string you can't just use the debugger
mouse hover to "see" it. It misleads the debugger. What is in the byte
in hexadecimal? Hexadecimal is absolute truth. 'â?¡' is the debugger's
interpretation, using rules we don't know, to convert the byte into
something else.

--
Scott McPhillips [VC++ MVP]

Robby
Thu Sep 21 15:10:02 CDT 2006

Hi Scott,

OKAY!

If I send an A from the cpu, which is equal to an ascii BYTE of 65, what do
I need to do to see the the 'A' or the 65 in VC++. In the passed, I have seen
the characteters of abBuffer by just hovering the cursor over abBuffer...
anyways... whatever! However, I would of never expected to see an off the
wall character like this: 'â?¡' representing the byte I sent? I don't know
anymore!

The code Project documentation confused me more than anything, The sample
was very vague and is really intended for programmers with quite a bit of
experience. But that's Okay!

As for the part of the null termination, here it is, I hope this is what you
were referoing to!

On the cpu side:
///////////////////////////////////////////////////////////////////////////////
int yyy;
char RS232_1_ExtOut[] = "ABCDEFGH";
fputc(RS232_1_ExtOut[0],COM_1); //Outputing *just* the 'A'
yyy++; //<<<<<Brreakpoint here!
////////////////////////////////////////////////////////////////////////////////

At the PC side (VC++):
/////////////////////////////////////////////////////////////////////////////////////
int xxx;
static DWORD dwBytesRead; //Set to 0 as default value!
static BYTE abBuffer[2]; //Just want to read the 'A' right?

MySerial.Read(abBuffer,sizeof(abBuffer),&dwBytesRead);
abBuffer[1] = '\0'; //Buffer null
terminated! <<<<
xxx++; //<<<<<Brreakpoint here!

////////////////////////////////////////////////////////////////////////////////////

When I say "see" I mean when putting the cursor over abBuffer where the
contents of abBuffer are displayed.

But as you posted, since its not a null terminated string, I can't see the
character, but we see only whatever the byte means to the debugger!

I don't know if you have gotten rs232 to function, and you probably have
successfully, But, with all the mind rattling I have gone through, I think if
you or anyone else for this matter knows of an example that would make this
work, I think it would help me comprehend what I have been doing wrong with
Characters, strings, nulls, arrays and so forth. In the cpu I am using, I am
coding allot in C, and like it or not, I am touching this stuff daily, but
yet this rs232, nada!

Anyways, I know you mean well by not presenting the solution straight out to
me!
At this point I don't know what else to do!

Thanks for your post!

--
Best regards
Robert


"Scott McPhillips [MVP]" wrote:

> Robby wrote:
> > And since my buffer is of byte type ex: A = (01000001), Should I see a 'A'
> > in abBuffer or the ascii code of 65?
> >
> > In any case I read the bizzard 'â?¡' symbol!
>
> I would guess that this is just one more case of confusing yourself and
> the debugger by not terminating the buffer, and/or attempting to
> interpret it in a UNICODE app. What do you mean by "see"?
>
> Since it is not a nul terminated string you can't just use the debugger
> mouse hover to "see" it. It misleads the debugger. What is in the byte
> in hexadecimal? Hexadecimal is absolute truth. 'â?¡' is the debugger's
> interpretation, using rules we don't know, to convert the byte into
> something else.
>
> --
> Scott McPhillips [VC++ MVP]
>
>

Scott
Thu Sep 21 16:19:09 CDT 2006

Robby wrote:
> int xxx;
> static DWORD dwBytesRead; //Set to 0 as default value!
> static BYTE abBuffer[2]; //Just want to read the 'A' right?
>
> MySerial.Read(abBuffer,sizeof(abBuffer),&dwBytesRead);
> abBuffer[1] = '\0'; //Buffer null
> terminated! <<<<
> xxx++; //<<<<<Brreakpoint here!
>
> ////////////////////////////////////////////////////////////////////////////////////
>
> When I say "see" I mean when putting the cursor over abBuffer where the
> contents of abBuffer are displayed.

...and you keep doing that despite multiple explanations that it may not
be meaningful, depending on circumstances. That doesn't work if the
buffer is not nul terminated. That doesn't work if the buffer is ASCII
and the app is UNICODE. You can use quick view or the memory window to
see the hexadecimal truth.

Incidentally, you have now asked Read for 2 bytes - probably not what
you intended.


> But as you posted, since its not a null terminated string, I can't see the
> character, but we see only whatever the byte means to the debugger!
>
> I don't know if you have gotten rs232 to function, and you probably have
> successfully, But, with all the mind rattling I have gone through, I think if
> you or anyone else for this matter knows of an example that would make this
> work, I think it would help me comprehend what I have been doing wrong with
> Characters, strings, nulls, arrays and so forth. In the cpu I am using, I am
> coding allot in C, and like it or not, I am touching this stuff daily, but
> yet this rs232, nada!
>
> Anyways, I know you mean well by not presenting the solution straight out to
> me!
> At this point I don't know what else to do!
>
> Thanks for your post!
>

Yes, I have gotten rs232 to function on numerous projects. Most of your
problems are simple lack of knowledge and experience. Standard for a
beginner. A complete rs232 solution would be too big for a newsgroup.
But surely you have reviewed the MSDN serial communication article and
sample program named MTTTY? It does it all!

--
Scott McPhillips [VC++ MVP]

Robby
Thu Sep 21 18:25:23 CDT 2006

Hey Scott!

Okay, I read your last post and you have said alot that I was not aware
about!!!

Meanwhile, Finally, I have stumbled on some success, I am working on it
right now! I wil get back to you later!

I think I got some statbility on the bytes read.... I will share this on a
completely new post named "rs232..." so not to clutter this one.... see ya
later!

Thanks for your reply... I much appreciate it!

--
Best regards
Robert


"Scott McPhillips [MVP]" wrote:

> Robby wrote:
> > int xxx;
> > static DWORD dwBytesRead; //Set to 0 as default value!
> > static BYTE abBuffer[2]; //Just want to read the 'A' right?
> >
> > MySerial.Read(abBuffer,sizeof(abBuffer),&dwBytesRead);
> > abBuffer[1] = '\0'; //Buffer null
> > terminated! <<<<
> > xxx++; //<<<<<Brreakpoint here!
> >
> > ////////////////////////////////////////////////////////////////////////////////////
> >
> > When I say "see" I mean when putting the cursor over abBuffer where the
> > contents of abBuffer are displayed.
>
> ....and you keep doing that despite multiple explanations that it may not
> be meaningful, depending on circumstances. That doesn't work if the
> buffer is not nul terminated. That doesn't work if the buffer is ASCII
> and the app is UNICODE. You can use quick view or the memory window to
> see the hexadecimal truth.
>
> Incidentally, you have now asked Read for 2 bytes - probably not what
> you intended.
>
>
> > But as you posted, since its not a null terminated string, I can't see the
> > character, but we see only whatever the byte means to the debugger!
> >
> > I don't know if you have gotten rs232 to function, and you probably have
> > successfully, But, with all the mind rattling I have gone through, I think if
> > you or anyone else for this matter knows of an example that would make this
> > work, I think it would help me comprehend what I have been doing wrong with
> > Characters, strings, nulls, arrays and so forth. In the cpu I am using, I am
> > coding allot in C, and like it or not, I am touching this stuff daily, but
> > yet this rs232, nada!
> >
> > Anyways, I know you mean well by not presenting the solution straight out to
> > me!
> > At this point I don't know what else to do!
> >
> > Thanks for your post!
> >
>
> Yes, I have gotten rs232 to function on numerous projects. Most of your
> problems are simple lack of knowledge and experience. Standard for a
> beginner. A complete rs232 solution would be too big for a newsgroup.
> But surely you have reviewed the MSDN serial communication article and
> sample program named MTTTY? It does it all!
>
> --
> Scott McPhillips [VC++ MVP]
>
>