High Speed Serial Comm PC - PIC and PIC - PIC

[BigWumpus]

Yes, it is better to use the USART-Hardware.
What speed is your PC able to handle on his serial port ?
I think, the PIC will manage it also!

[manumenzella]

Hi. Thank you for your answer. I have no idea what serial speed my serial port can take. I may also end up using a USB - to - Serial adapter just in case i burn everything!!! ahah.
Is it possible to reach speeds like 115200 bits per second with pics???
Sorry for my english!! Spanish is my first languaje!!!! Thanks
Manuel

[skimask]

Hi. Thank you for your answer. I have no idea what serial speed my serial port can take. I may also end up using a USB - to - Serial adapter just in case i burn everything!!! ahah.
Is it possible to reach speeds like 115200 bits per second with pics???
Sorry for my english!! Spanish is my first languaje!!!! Thanks
Manuel

Yes, you can get 115.2kbps from a PIC. You can get all the way up to 2.5Mbps (40mhz clock / 16), but you'll barely have any time left over to move data around and otherwise process it.

[manumenzella]

Yes, you can get 115.2kbps from a PIC. You can get all the way up to 2.5Mbps (40mhz clock / 16), but you'll barely have any time left over to move data around and otherwise process it.

Hi skimask! Thank you for your answer!!! I don't need the data to be receiver all the time. Just about 96 bytes twenty times every second. By the way, I think there is something i don't understand about the USART: is it like the serin/out, in which the pic has to do OLNY the serial transmission, and cannot do anything else, or is it like HPWM, a background process??? (I dont think i made that very clear.. my english is not that good..
Sorry to bother you again!!! And thanks!!!!!!!
Manuel

[skimask]

Hi skimask! Thank you for your answer!!! I don't need the data to be receiver all the time. Just about 96 bytes twenty times every second. By the way, I think there is something i don't understand about the USART: is it like the serin/out, in which the pic has to do OLNY the serial transmission, and cannot do anything else, or is it like HPWM, a background process??? (I dont think i made that very clear.. my english is not that good..
Sorry to bother you again!!! And thanks!!!!!!!
Manuel

Serin/Serout is a 'bit-banged' routine, all bits are checked/timed using software, delays, loops, etc. Once you're in the middle of a Serin/Serout command, that's all you can do, nothing else.

HSerin/HSerout is a mix between software and hardware, done somewhat in the 'background' but not entirely. Hardware handles receiving/transmitting the character, PBP software handles 'getting' or 'sending' it. Again, once you're in the middle of a command, you have to wait until it's finished.

The UART is completely hardware driven. You can either set up a loop and wait for certain bits to change, then act on the sending/receiving registers accordingly. Or you can do use the UART in the 'background' using interrupts to tell you when you need to receive or send characters.

Your PBP manual has a decent explanation of how to use the Serin/Serout/HSerin/HSerout and the PIC datasheets do well explaining the UART. Use them...they are your friend...

[SteveB]

... I think there is something i don't understand about the USART: is it like the serin/out, in which the pic has to do OLNY the serial transmission, and cannot do anything else, or is it like HPWM, a background process???

Manuel,
The harware USART operates in the background, as does the HWPM. However, you do have to "feed" it the data, and that will essentially happen one byte at a time.

You say you need to send 96 bytes at a time, twenty times a second? From your previous mention of 40MHz clock speed, I would deduce you are using an 18F PIC. I don't know how you are "gathering" your 96 bytes of data, but you could feed the USART from an array using interrupts to determine when the USART is able to receive the next byte. You may also be able to poll the TXIF bit frequently vs using interrupts.

Hopefully, this is not sounding too advanced. Start by reading the PBP manual on HSEROUT and the datasheet for you pic (the USART section). Also, MeLabs has some sample programs that can also help.

The basics are:
1) Setup the USART through the approapriate DEFINEs and registers. Here is an example of what I use for a 18F4620:

'	'Setup for 115200 baud 
DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
DEFINE HSER_SPBRG 86  ' 86 = 115200 Baud @ -0.22%
SPBRGH = 0
BAUDCON.3 = 1         ' Enable 16 bit baudrate generator

2) Use either:
a) HSEROUT to send out the data, realizing that it can do some processing of the data before it is sent to the hardware. Also, that sending multiple bytes of data will force the PIC to process all the bytes to be sent out before it moves on to the next statement
b) Send the bytes directly to TXREG. This would allow for the use of interrupts/flag polling to send the data "in the background"

Hope this helps you get started in the right direction.
Steve B

Guess I was a little slow on the draw That's what happens when toddlers need to go to sleep!

[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