High Speed Serial Comm PC - PIC and PIC - PIC

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

[manumenzella]

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

[skimask]

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