High Speed Serial Comm PC - PIC and PIC - PIC

[manumenzella]

Hi SteveB! Thanks so much for your answer!!! It was just what I needed. I was able to understand it right away. The PBP Manual was some help too!!!!
By the way, I would like to know what is the benefit of using the USART module, with hserin or hserout commands, as they cannot be done in the backgroud. The benefit is clear, though, when using the module just like the datasheet says.
Perhaps you can achieve greater speeds using the USART??? Or less error percentage???
Well, thats all for know!!! Thanks again steve for your answer!!!!!
Manuel

[SteveB]

By the way, I would like to know what is the benefit of using the USART module, with hserin or hserout commands, as they cannot be done in the backgroud. The benefit is clear, though, when using the module just like the datasheet says.
Perhaps you can achieve greater speeds using the USART??? Or less error percentage???

Manuel,

The advantage of the PBP HSEROUT command is that it has the flexability to
a) "format" the outgoing data as needed (such as sending the value 65 out as "65", "41", "A", or "01000001") and
b) send multiple bytes in sequence (such as HSEROUT [dec var_a, 10, "X", HEX2 var_b]) and
c) it uses the hardware USART, which speeds things along, since it change run at a higher baud rate and it can send out one byte in the background while the pic is processing the next byte in the foreground.

The disadvantange to the HSEROUT is that it will occuply the PIC if it has a large amout of data to send. Take, for example, the command:
HSEROUT ["This is a long string of data for the PIC to send out the USART!"]
This command, even though it uses the USART, would monopolize the PIC until the last byte was sent to the USART. So, it is very much running in the forground (preprocessing and queing the data), even though it uses the hardware USART in the background to actually send the data.

What about writing directly to the TXREG? If the data did not need any "pre-processing", and in combination with an interrupt driven queing scheme, this would likely be the fastest, most efficient method, leaving more time for foreground processing. The foreground task is only interrupted, when the USART is done sending the last byte, long enough to write the next byte to the TXREG. It then resumes the foreground processing until the USART is done sending out that byte. This is not the "easiest" way to do things, just another alternative.

Now, what you need to determine is how critical timing and processing time are going to be in your application. If your forground tasks are not that demanding, the HSEROUT, sending a burst of 96 bytes would be the easiest. Otherwise, you may need to set up an interrupt based scheme which will take maximum advantage of the USART.

As for percentage of error, since the HSEROUT uses the USART to send the data, the timing error is the same. How it compares to the timing error of PBPs bit-banged serial commands? I haven't got any data on that.

Steve B

[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