PDA

View Full Version : Struggling with first byte received



cncmachineguy
- 25th April 2011, 14:43
Hello everyone. Quick question here.

I am playing with my first real hardware serial program. All I am doing is receiving 16 bytes and putting them into an array. It is all interrupt based, and works. The issue is the first byte seems to always be 00h. Now I know the first sent byte is 03h as seen with Logic (awesome cheap analyzer). So before I go all out and just post the code and ask for help, I am wondering if the RCREG gets the byte from the UART on the first interrupt, or if it is not actually shifted until the second byte is received.

Thanks for your thoughts on this.

HenrikOlsson
- 25th April 2011, 16:41
Hi Bert,
The byte is transfered from the input shift register to the FIFO buffer once all its bits (including the stop bit) are received proplerly - this is also the instant at which the interrupt flag gets set.

RCREG then "gets" the byte from the FIFO buffer at the instant you actually read RCREG. If there's nothing in the FIFO you'll get nothing (0). Reading RCREG removes the oldest byte from the FIFO.

Is it only the very first byte after boot up that is wrong or is it the first byte of every packet?

/Henrik.

PS. I love my LOGIC as well, it's just perfect for stuff like this!

cncmachineguy
- 25th April 2011, 16:57
Thanks Henrik.

Lets see if I understand-

If I am receiving 16 byte packets, To get them in order, I need to:

Read first byte
Throw it away
read next 16 bytes.

but to get the last byte, do I need to an extra read to get the last from FIFO to RCREG?

Because I don't want the last byte as the next packet first byte.

Logic is Walter's (scalerobotics) fault. He turned me on to it. Best diagnostic tool yet for this stuff. Don't leave home without it :)

HenrikOlsson
- 25th April 2011, 17:26
Hi Bert,
No, if you expect 16 bytes you should read RCREG 16 times - one for each byte received. Obviously you have to wait for each byte to actually come in (signalled by the interrupt flag beeing set) but I know you knew that.

As the sending device is sending a byte the USART recevies it by shifting it into the input shiftregister (you can't access this register). Once all bits of the byte are properly received the byte is automatically transfered to the FIFO and the interruptflag is set. When you read RCREG you'll automatically get the byte from the FIFO.

Receiving 16 bytes is no different really, you just need to retreive the bytes one by one and put them in your software buffer/array/whatever.

There should not be any need to throw anything away but apparently there's something strange going on in your case which is why I asked if it is the very first byte after startup or the first byte in every packet that gets read as 0.

Hard to say what's going on really without seeing the code....I'd probably take a step back and just send a single byte and make sure that the it gets received properly.

/Henrik.

cncmachineguy
- 25th April 2011, 18:16
Sorry Henrik,

I Ment to say I wasn't sure if it was only the first byte. I don't think I looked past it last night to see the rest.

I will tinker with it some more tonight.

I am sure if I posted the code, You or someone else would point out the error directly. But that is my fallback position. First I must be sure I have tried all I can to locate the trouble. Just my nature. I like solving these things, and I remember better if I do vs. if someone else points it out to me.

So I start with making sure I fully understand what it should be doing, then I have things to compare it to.

The sending device is a DSM2 Rx, so no stopping the data or sending 1 at a time. I can however, connect another pic and simulate the Rx. that may be worth a go
if I can't get to the bottom of this.

cncmachineguy
- 26th April 2011, 03:07
Well as it turns out, it seems to be just the first byte after startup. Now this I can deal with using a flag or 2. :)

See, not looking past the first packet is the kind of things I do when it's too leate and I should be sleeping.