High Speed Serial Comm PC - PIC and PIC - PIC

[manumenzella]

Hi Steve. Thanks again for all your time.
I forgot to add int the first post that the PIC that is having to do some foregroud task is the one that is receiving the data. (sorry )
As for what I understood from the datasheet, and please correct me if I'm wrong, the USART can receive two full bytes berore you have to read them using the register. But that is only 140 us, not even enough for a single loop to be processed in the program im using. Is this correct???
By the way, what I am trying to do is a LED cube, with the LEDs multiplexed, so if the transmission takes long enough, there will be flickering in the leds.
Thanks a looooooot!!!
Manuel

[skimask]

Hi Steve. Thanks again for all your time.
I forgot to add int the first post that the PIC that is having to do some foregroud task is the one that is receiving the data. (sorry )
As for what I understood from the datasheet, and please correct me if I'm wrong, the USART can receive two full bytes berore you have to read them using the register. But that is only 140 us, not even enough for a single loop to be processed in the program im using. Is this correct???
By the way, what I am trying to do is a LED cube, with the LEDs multiplexed, so if the transmission takes long enough, there will be flickering in the leds.
Thanks a looooooot!!!
Manuel

...which is why you use the hardware UART and some interrupts and write your own buffer routine to pull out the data received when you can spare the time to do it. I'm multiplexing & PWM'ing 306 RGB LEDs (918 total) on a 921.6kbps serial line while at the same time receiving 9600 bps control data over an RF link...all using a bunch of 16F628A's and a master 18F2620. I don't see any flickering.
Don't count on that 'receive 2 full bytes before you have to read them' thing, because it WILL bite you later on when you least expect it.

[manumenzella]

Hi. Thanks for the input. That must be a great project!!! What is it about???
Can I see a picture???
About the USART, i think I will do what you told me. I didnt undersatand the part where you say that I shouldnt count on that "two full bytes" thingy
Do I have to read the data every byet??? Thanks again.
Manuel

[skimask]

Hi. Thanks for the input. That must be a great project!!! What is it about???
Can I see a picture???
About the USART, i think I will do what you told me. I didnt undersatand the part where you say that I shouldnt count on that "two full bytes" thingy
Do I have to read the data every byet??? Thanks again.
Manuel

The 2 bytes - I'm just saying that PBP might get busy doing something else and you think you might have enough time to grab that 2nd byte and BAM! in comes the 3rd one and now you've lost data.

The LEDs - I've got pictures of them on my site, no movies yet, and the pic's are actually pic's of the old LEDs all running in sync with each other. I'll have a good movie up there eventually.

[SteveB]

The 2 bytes - I'm just saying that PBP might get busy doing something else and you think you might have enough time to grab that 2nd byte and BAM! in comes the 3rd one and now you've lost data.

Another way to think about this is that the 2nd byte capability is short term overrun protection. This way, the first byte can be read while the second byte is being recieved. As skimask says, if a third byte shows up, and the recieve register has not be read (the 1st byte), on overrun will occur and data will be lost.

Steve B

[sougata]

Hi Manuel,

Whenever a byte is received by the USART it is made available in the receive buffer while the other byte (2byte buffer) still gets stuffed. You must read the byte before your another byte is full. If not, your USART faces a buffer underrun condition and an error is raised.

The USART supports interrupts and it is fired as soon as a byte is ready. You might be in middle of something but still can grab the data in your own buffer and resume. Later you can check for newly available data and modify your display. If you are doing multiplexing then you might be needing interrupts anyway to get good timings and display stabilty.

It is better if you have some sort of hardware block diagram.

[HenrikOlsson]

Hi,

Whenever a byte is received by the USART it is made available in the receive buffer while the other byte (2byte buffer) still gets stuffed. You must read the byte before your another byte is full. If not, your USART faces a buffer underrun condition and an error is raised.

I don't mean to be picky here but the 'buffer' is actually two bytes so a third byte can be 'on its way in' without buffer over run. As soon as the third byte is clocked in, though, you'll get a buffer over run error.

There's a document on the Microchip website called Usart.pdf (no document number or anything) that explains the operation in asynchronous mode. The following is an extract from it:

The use of a separate receive shift register and a FIFO buffer allows time for the software running on the PICmicro MCU to read out the received data before an overrun error occurs. It is possible to have received two bytes and be busy receiving a third byte before the data in the RCREG register is read.

Hope it helps.

/Henrik Olsson.