Serial Port Communication White Paper

[DanL]

Originally posted by 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.

Hmm, well what happens if you loose one of those 24 bytes... it'll be that your 24th byte will actually be the first byte of the new packet... how does your way protect against this?

[rbayer]

Originally posted by SuperDanman


Hmm, well what happens if you loose one of those 24 bytes... it'll be that your 24th byte will actually be the first byte of the new packet... how does your way protect against this?

You won't. PC serial ports use buffers to store data in. Once you begin the read, you will get 26 continuous bytes. On the other hand, if the buffers overflow between read operations, you might loose a byte or two. Even if you do, by some mysterious fluke of Windows, loose a byte from the middle of a 24-byte read, checking for the start of the packet on each loop will make sure it corrects itself.

[DanL]

Hmm, well thats a bit more simple than I thought... however, I was more concerned about no information coming over because of a radio failure between the robot and the oi or some interfereance...

Originally posted by rbayer

Even if you do, by some mysterious fluke of Windows, loose a byte from the middle of a 24-byte read, checking for the start of the packet on each loop will make sure it corrects itself.

Well, suppose the check fails... what if the first two bytes aren't 255's... I suppose you have to switch to a read-1-byte-at-a-time loop until you DO get two consequetive 255's?

[Ian W.]

actually dan, before you even posted that, or at least before i read that last post, that's what i just did. hopefully it will work...

[rbayer]

I'd think so...

If not, here's the code I used. It takes the cross between two consecutive packets, but it really doesn't matter since the refresh rate is much higher than the eye could ever detect.

int i;
int start;
unsigned char info[26];
for(int i=0; i <=24; i++){
  if(readBuff[i]==255 && readBuff[i+1]==255){  //packets start with 255,255
  start=i;
  break;
  }
}

for(int i=start; i<=25; i++){
  info[i-start]=readBuff[i];
}
for(int i=0; i<start; i++){
  info[i+(26-start)]=readBuff[i];
}

[DanL]

ahhhh, now I see what you were talking about all along!

Just I don't like the fact that you overlap 2 packets into one... yeah it's too high to pick up, but just so I know I have an understanding of packets, this code would make it get the full packet, right?

int i;
int start;
unsigned char info[26];
for(int i=0; i <=24; i++){
  if(readBuff[i]==255 && readBuff[i+1]==255){  //packets start with 255,255
  start=i;
  break;
  }
}

for(int i=start; i<=25; i++){
  info[i-start]=readBuff[i];
}

unsigned char remainingBuffer[start];
ReadFile (hSerial, remainingBuffer, start, &read, 0);
for (int j=0; j<start; j++) {
  info[26-start+j]=remainingBuffer[j];
}

[rbayer]

Looks good. It should also align the data for all subsequent reads, making it a little bit faster. Just make sure start isn't equal to 0 before you go into that last block of code, as I don't know how VC++ deals with arrays of size 0 or how ReadFile deals with requests of length 0. Might be OK, might cause page faults; you never know 'til you try.

I definately agree that overlapping two packets isn't ideal, but I was too lazy to change it after I realized that was what it was doing (I wrote the algorithim around 3am last year in Florida and wasn't quite thinking right).

[Matt Leese]

When I wrote my dashboard viewer, I took a bit different take on how to read in the data. I did read in everything one byte at a time. Once I received two 255's, I then started a count. Given the value of the count, I determined what data I was actually reading in. Given that, I processed the data into a structure (ie the structure was updated everytime through the loop which means everytime a byte was read). Then, once the count reached the end of data, I updated the display.

As far as speed issues go, there is no problem reading in a byte at a time. Remember, the data will only be coming at you 20 times per second (20 Hz) which is something a computer can easily process.

Matt

[Ian W.]

one quick problem/question...

is it in anyway possible to loose a byte or two between reads? i'm doubting that, because of what i've heard, but it's something that's probably useful to know .

[rbayer]

theoretically, yes. Probably, no. The only way you could loose a byte is if the PC's buffers overflow, and the only way I can imagine this happening is if you do a lot of time-consuming work between reads.

[DanL]

What about if there's a break or interfereance in the radios between the robot and the oi?

[Matt Leese]

The OI should continue sending data even if there's a break between radios. It will only stall in between packets (ie all 26 bytes); that's because it doesn't have all the data to send.

Matt

[Ian W.]

so, theoretically, the OI will only send a complete packet, so the only way to get a partial packet is to unhook the cable from the dashboard port? that seems to make the most sense to me, so i'll go with that. also, that would mean we don't need to elaborate on some huge thing to crack down on missing packets and ignore them so they don't screw up the computer. makes everything a bit easier .