Serial Port Communication White Paper

[Ian W.]

bah, that doesn't work, but i have one idea. is there a way that i can say that if getch () is 0, then virtually press the enter key? i know you can do the keyboard part, not sure how though. but if i had it constantly 'press' enter, unless i hit a button, in which case it stops. i think that would work, not sure though.

[rbayer]

What's not working? Have you tried the code I posted earlier? Make sure to check kbdhit() before you call getch(). That seems to work on my computer.

[Ian W.]

yeah, i'm going to go and smack myself. i forgot kbhit (), so it kinda doesn't work . i feel so stupid now...

oh well, at least i know what i'm doing now.

[Ian W.]

ok, i have my serial communications program working, or at least i think so. there's one part i'm not sure of, which is as follows...

if(!ReadFile(hSerial, szBuff, 26, &dwBytesRead, NULL))	{
           //error reading serial port. Process appropriately.
	cout << "Uh oh" << endl;
}

the little 'uh oh' was just a phrase i spat out to test where the program was failing. it seems to be able to get up to this statement, and then it freezes. i'm assuming this is because i don't have the robot hooked up to it, but i just want to be sure. i'm going to be testing it tomorrow, i think, so i can be sure about whether or not it works, but i just want to make sure that this line of code (or lines) will work correctly, which it should. if this code works, i think i have the basic program all done, and all i need to do is 'customize' the dashboard, so i can change the numbers to reflect this year's robot program. but i want to make sure the actual basic program works first.

[Ian W.]

most interesting, as i was trying out the different COM ports (when you initially open the port, the "COM#" line), and when i did COM3, it worked as it should. i'm assuming that means that my computer is set to COM3 and COM4, but i have no idea how that works. so, it appears that my program is working as it's supposed to after all...

one thing though. does a COM port without a incoming signal transmit '-52' out, cause that seems to be what i'm reading... :/

[rbayer]

In theory, you shouldn't read anything without a device connected; the ReadFile should hang the thread. The easiest way to figure out what COM ports you have is to open up your device manager and look under the Ports category.

[Matt Leese]

It seems very strange that your computer is setup to use COM3 and 4. I've never seen that. Normally a computer is setup so that the serial port is COM1 and the modem as COM2 (or vice-versa; modems have hardware, called a UART, so that they are treated exactly the same as a serial port). I would suspect that for whatever reason windows is actually letting you open COM3 even though it's not really connected to anything (the open command should fail at that point). I'd also check to make sure that your modem isn't on COM3 (as you should be able to open that). Just as an fyi, 51 is 0x33 and -51 would then be 0xCD which isn't any sort of code that I know. Anyone know any different?

Matt

[Ian W.]

ok, i figured it out. sorry for the confusion, but i was rather confused last night too .

anyways, i realized after that the reason it worked when i opened it on COM3 or 4, was that everything just failed, and because my program is bare basics, it would still continue (yeah, i have to fix that part ). anyways, it would just jump into the loop, and get stuck. of course, i didn't realize it, but now it all makes sense. so, that problem is fixed.

the other part, about it not working on 1 and 2, is exactly what rbayer said. the read file thread hung up the program, cause there was nothing hooked up (this was at home). today in school, i tried to run the program, but realized i had completely screwed up the array that collected the data, because i'm stupid . so, i fixed that, and waiting till tomorrow to test it.

also, in a stroke of luck, i'm taking the robot home for the summer, so i can keep working on it . looks like i'm not going to die if rbayer doesn't get that PBASIC emulator thing out right away . keep working on it though, cause it's a really good idea, especially for at competition, when you usually want to test the code before you use it.

[rbayer]

Originally posted by Ian W.
looks like i'm not going to die if rbayer doesn't get that PBASIC emulator thing out right away . keep working on it though, cause it's a really good idea, especially for at competition, when you usually want to test the code before you use it.

Have no fear! School is out and I have nothing better to do for the next month. It will be done, I just don't know when.

[Ian W.]

heh, one more day of classes for me...then a week of regents . but, i'll have plenty of time after to make some good flash/c++ program, and to fix up the robot. can't wait...

[Ian W.]

hmm, quick question...

when i had my buggy C++ dashboard port reader running today, i had accedentally set it only to fout (file out) the first byte (yes, very stupid mistake on my part ). anyways, in Dan's little 'byteviewer' flash program, it came up as various numbers, like 80, 40, -52, etc. i was under the impression that the first two bytes were 0xff, or 255. what's the deal with this?

[rbayer]

The problem is, there is nothing to guarantee that you will start reading at the beginning of a packet. That is why you have to read in 26 bytes, find the beginning, and then start processing from there.

[Ian W.]

ah, ok that makes sense. so, i do a first read, finding the double 255/0xff, and then once i find that, start the main loop? i think i know how that should work, although not completely sure.

[DanL]

Okay, so this part sure is the painful part... after about an hour discussing it, Ian and I decided to do something, just we wanna know if this is the 'correct' way of doing it...

Basically we're going to read in one byte at a time to a fixed queue of 28 positions. When the first two items and last two items are equal to 255, then we know that we have a full packet, and we read the queue for the appropriate information. If all four items aren't equal to 255, then we know we don't have a full packet, and we just continue adding to the queue.

For a visualization (they're easier to understand), I made a simple visualized version of what we're going to do... http://24.186.144.31:81/queue-visual/moo.html

I believe this is going to work, but if it doesn't, how are you supposed to parse the bytes, or, determine where a packet begins?

[rbayer]

I'd avoid reading one byte at a time if possible. It is inefficient and means your program will loop more often. And if you miss a byte, the output could appear sluggish or delayed. If you want to do something similar to this, I'd recommend that that you just discard data until you find a 255,255 and then copy the next 24 bytes into your data structure.

Originally posted by Ian W.
ah, ok that makes sense. so, i do a first read, finding the double 255/0xff, and then once i find that, start the main loop? i think i know how that should work, although not completely sure.

Everytime through the loop you should resort the data. Otherwise, if you miss even a single bit, the whole packet will be off and the data won't make any sense. My advice is to read the data into a temporary storage space and then sort it into a final one. That's the way I did it in my dashboard program, and it works fairly well. If you want to take a look, the source is at http://FIRSTprograms.tripod.com under the name gDash. Or, I can send you just the relevant portion of code if you would prefer.