High Speed Serial Comm PC - PIC and PIC - PIC


+ Reply to Thread
Results 1 to 24 of 24
  1. #1
    Join Date
    Jan 2007
    Posts
    44

    Question High Speed Serial Comm PC - PIC and PIC - PIC

    Hi. I am 15, and I quite a newby in PICs.
    I am working on a LED cube project, and need to send 32, 64, or 96 bytes through serial communication. Which is the higher speed I can get running at 20 Mhz??? And running at 40 MHz???
    Also, is it better to use the USART module??? How does it work???
    I hope you cal help me!!! This is a great forum!!!!
    Thanks
    Manuel

    PS I hope i posted this thread in the right place!

  2. #2
    Join Date
    Oct 2004
    Location
    Hangover, Germany
    Posts
    289

    Default

    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!
    PBP 2.50C, MCS+ 3.0.0.5, MPLAB 8, MPASM 5.14, ASIX Presto, PoScope, mE mikroBasic V7.2, PICKIT2

  3. #3
    Join Date
    Jan 2007
    Posts
    44

    Default ---

    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

  4. #4
    skimask's Avatar
    skimask Guest

    Default

    Quote Originally Posted by manumenzella View Post
    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.

  5. #5
    Join Date
    Jan 2007
    Posts
    44

    Default

    Quote Originally Posted by skimask View Post
    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

  6. #6
    skimask's Avatar
    skimask Guest

    Default

    Quote Originally Posted by manumenzella View Post
    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...

  7. #7
    Join Date
    May 2006
    Location
    Del Rio, TX, USA
    Posts
    343

    Default

    Quote Originally Posted by manumenzella View Post
    ... 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:
    Code:
    '	'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!
    Last edited by SteveB; - 15th January 2007 at 02:53. Reason: Skimask beat me to the punch!

  8. #8
    Join Date
    Jan 2007
    Posts
    44

    Default

    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

  9. #9
    Join Date
    May 2006
    Location
    Del Rio, TX, USA
    Posts
    343

    Default

    Quote Originally Posted by manumenzella View Post
    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
    Last edited by SteveB; - 15th January 2007 at 06:53.

  10. #10
    Join Date
    Jan 2007
    Posts
    44

    Default

    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

  11. #11
    skimask's Avatar
    skimask Guest

    Default

    Quote Originally Posted by manumenzella View Post
    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.

  12. #12
    Join Date
    Jan 2007
    Posts
    44

    Default

    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

  13. #13
    skimask's Avatar
    skimask Guest

    Default

    Quote Originally Posted by manumenzella View Post
    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.

  14. #14
    Join Date
    May 2006
    Location
    Del Rio, TX, USA
    Posts
    343

    Default

    Quote Originally Posted by skimask View Post
    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

  15. #15
    Join Date
    Feb 2005
    Location
    Kolkata-India
    Posts
    563

    Default Start using Interrupts if you haven't done yet.

    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.
    Regards

    Sougata

  16. #16
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,386

    Default

    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.

  17. #17
    Join Date
    Jan 2007
    Posts
    44

    Default

    Hi. Thanks once again for all your help!!! With all the info you gave me, I was able to compile some program to transfer 8 bytes using USART, to another PIC and perform PWM to them (not multiplexing yet)
    I have not been able to try the code out yet, because I do not have two 16F877A right now. Anyway here are the TX and RX codes. Im sure they have quite a lot of errors, but a start is a start, isnt it??
    (Please check also the regs at the beginning, I wasnt sure of some bits...

    This is the TX code:

    DEVICE 16F877A
    ALL_DIGITAL = TRUE
    XTAL = 20

    DIM PWMDATA[8] AS BYTE 'VARIABLES FOR DATA TRANSMISSION

    'LOAD PWMDATA FROM SOMEWHERE ELSE...

    DIM INDEX AS BYTE 'INDEX FOR DATA RECEPTION FOR PWMDATA
    DIM X AS BYTE

    TXSTA = %00100110 'ASYNCHRONUS, HIGH SPEED, TRANSMISSION ENABLED.
    RCSTA = %10010000 'USART ON, 8-BIT, NO ADRESS DETECTION, CONTINOUS RECEIVE
    SPBRG = %00001010 'SET BAUDSPEED TO 113200 (HOW DO YOU CALCULATE THE ERROR?)

    MAIN:
    FOR INDEX = 0 TO 7
    TXREG = PWMDATA[INDEX]
    WHILE TXIF = 0 : WEND
    NEXT INDEX
    GOTO MAIN

    /////////////////////////////////////////////////////////////////////////////

    And this is the RC code:

    DEVICE 16F877A
    ALL_DIGITAL = TRUE
    XTAL = 20
    TRISD = $00

    DIM PWMDATA[8] AS BYTE
    DIM INDEX AS BYTE
    DIM X AS BYTE

    FOR X = 0 TO 7 'INITIATE PWMDATA
    PWMDATA[X] 0 = 255
    NEXT X
    INDEX = 0

    TXSTA = %00100110 'ASYNCHRONUS, HIGH SPEED, TRANSMISSION ENABLED.
    RCSTA = %10010000 'USART ON, 8-BIT, NO ADRESS DETECTION, CONTINOUS RECEIVE
    SPBRG = %00001010 'SET BAUDSPEED TO 113200 (HOW DO YOU CALCULATE THE ERROR?)

    MAIN:
    PORTD = $FF
    FOR X = 0 TO 255
    IF X = PWMDATA[0] THEN CLEAR PORTD.0
    IF X = PWMDATA[1] THEN CLEAR PORTD.1
    IF X = PWMDATA[2] THEN CLEAR PORTD.2
    IF X = PWMDATA[3] THEN CLEAR PORTD.3
    IF X = PWMDATA[4] THEN CLEAR PORTD.4
    IF X = PWMDATA[5] THEN CLEAR PORTD.5
    IF X = PWMDATA[6] THEN CLEAR PORTD.6
    IF X = PWMDATA[7] THEN CLEAR PORTD.7
    IF RCIF = 1 THEN GOSUB RECEIVE
    NEXT X
    GOTO MAIN

    RECEIVE:
    IF INDEX = 8 THEN INDEX = 0
    PWMDATA[INDEX] = RCREG
    INDEX = INDEX + 1
    RETURN



    Thanks for all your help!!!
    Manuel

  18. #18
    skimask's Avatar
    skimask Guest

    Default

    Quote Originally Posted by manumenzella View Post

    DEVICE 16F877A
    ALL_DIGITAL = TRUE
    XTAL = 20

    DIM PWMDATA[8] AS BYTE 'VARIABLES FOR DATA TRANSMISSION

    DIM INDEX AS BYTE 'INDEX FOR DATA RECEPTION FOR PWMDATA
    DIM X AS BYTE

    DEVICE 16F877A
    ALL_DIGITAL = TRUE
    XTAL = 20

    DIM PWMDATA[8] AS BYTE
    DIM INDEX AS BYTE
    DIM X AS BYTE

    PWMDATA[X] 0 = 255

    Manuel
    That's some of the strangest PBP I've seen in awhile...must be that new version...

  19. #19
    Join Date
    Jan 2007
    Posts
    44

    Default

    Hi. Yes I know. I don't know why my compiles uses those commands. A relative of mine taught me basic and he tought to me like that. Is it at least readable by you guys??? I hope so!!!
    Manuel

  20. #20
    Join Date
    Jan 2007
    Posts
    44

    Default

    Hey by the way, in the RC code, there is an extra 0 that should be there.
    Instead of :

    FOR X = 0 TO 7 'INITIATE PWMDATA
    PWMDATA[X] 0 = 255
    NEXT X
    INDEX = 0

    It should be:

    FOR X = 0 TO 7 'INITIATE PWMDATA
    PWMDATA[X] = 255
    NEXT X
    INDEX = 0

    Thanks
    Manuel

  21. #21
    skimask's Avatar
    skimask Guest

    Default

    Quote Originally Posted by manumenzella View Post
    Hi. Yes I know. I don't know why my compiles uses those commands. A relative of mine taught me basic and he tought to me like that. Is it at least readable by you guys??? I hope so!!!
    Manuel
    Maybe because it's not PBP?

  22. #22
    Join Date
    Jan 2007
    Posts
    44

    Default

    Ohhh Youre right! This was my uncle computer and he left the compiler installed!!! It says PBP compiler, but in About... it says proton!!!!!!!!!!!!!!!!!
    Its quite similar though. The language, i mean.
    Manuel

  23. #23
    Join Date
    Feb 2005
    Location
    Kolkata-India
    Posts
    563

    Default Thanks Henrik

    Hi,

    Thanks Henrik for correcting me.

    BTW manuel could you please describe your project in a little bit more detail.
    Regards

    Sougata

  24. #24
    Join Date
    Jan 2007
    Posts
    44

    Default

    Hi. Yes of course. Im sorry i didnt before.
    What I want to do is a 4x4x4 RGB LED cube that is commanded, via serial, from a computer. Each color of each RGB LED will be PWMed (4 bits) so I would need to receive 96 bytes (4 bits per LED).
    Right now, instead of using a computer to send the data, I would like to try to do it with another PIC, so as to simplify it for now.
    Thanks again!!!
    Manuel

Similar Threads

  1. Replies: 11
    Last Post: - 12th July 2008, 03:36
  2. Pic to pic interrupt ans serial comm
    By ronjodu in forum mel PIC BASIC Pro
    Replies: 3
    Last Post: - 10th May 2008, 23:43
  3. pc to pic serial comm and i2c eeprom
    By elektroline in forum mel PIC BASIC Pro
    Replies: 3
    Last Post: - 2nd November 2006, 06:51
  4. Replies: 5
    Last Post: - 20th March 2006, 02:34
  5. Serial Pic to Pic using HSER
    By Chadhammer in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 12th March 2005, 00:14

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts