How to receive stream of bytes using PIC USART

[unifoxz]

I am sorry for the confusion. Actually, the following code is to wait for the PC to send the request before PIC read in the data from the SpO2 module.

'request from PC, 9600 baud rate
standby:
SerIn PORTC.7,6,["P",ID_2, ID_1, ID_0]

Once PIC get the matching ID from PC, the PIC will read the data from SpO2 module to extract the SpO2 byte and pulse rate byte from the SpO2 module. Since PC and SpO2 module are using different baud rate (which PC is 9600 baud rate and SpO2 module is 4800 baud rate), I can't put them in the suggested code line.

The PIC need to capture 2 bytes from a stream of bytes sent by the SpO2 module. The SpO2 module sends the bytes in sequence and continuously. I get the wrong data but I think there is nothing wrong with my algorithm to capture the intended data, by referring to the manual of the SpO2 module.

My guess is that the PIC's receiver buffer has overflowed and causing the data clash. How should I avoid the buffer overflow so that I could retrieve the correct data byte from the byte stream of the SpO2 module?

[mackrackit]

Sorry, but this is confusing..

How does the PC know when to tell the PIC that the time is right to receive data?

Why not have the PC work at 4800 baud also?

Seems like by the time the PC some how decides the time is right and sends this to the PIC the time would have passed for the data?

[unifoxz]

How does the PC know when to tell the PIC that the time is right to receive data?

The data from SpO2 module is sent out continuously. The updated data is sent out from the module all the time. The PC just send request whenever it wants to and the PIC will responsible to grab a few current data bytes from the SpO2 module and extract out the targeted bytes, which are SpO2 data byte and pulse rate data byte.

Why not have the PC work at 4800 baud also?

I need to send the data through a wireless transceiver module which works at 9600 baud rate eventually. For testing purpose, I am connecting the PIC directly to the PC UART instead of the transceiver.

[unifoxz]

I have tried with sending out data bytes that received from the modules to PC immediately but the data displayed on the PC is different from the data that I connected the module directly to PC. It seems like the data of the bytes stream corrupts when it passes through the PIC.

This is the testing code:

INCLUDE "modedefs.bas"
DEFINE LOADER_USED 1    	
DEFINE OSC 20 
B0 VAR BYTE

'PB.7 = Rx, PB.6 = Tx
TRISB = %10000000 

loop:
'4800 baud rate
'read byte from SpO2 module
SerIn2 PORTB.7,16572,[B0]
'send byte to PC
SerOut2 PORTB.6,16572,[B0]
GoTo loop
End

What should I do to avoid the data from crashing in Rx buffer of PIC UART, provided I cannot control over the stream of bytes received?

[ScaleRobotics]

Are you sure it's not just an inverted vs true problem? If it is a buffer problem, you could switch to the hardware uart and use something like they do for reading gps strings:

MAXDATA      CON 70       'The buffer Size for GPS Data  was 70  
gpsdata         VAR BYTE[MAXDATA]    '  70 byte array.
HSerin 200, Main, [WAIT("$GPRM"), STR gpsdata\MAXDATA\13]

[unifoxz]

I was thinking it could be inverted vs true problem too. However my assumption was found to be fault after I receive unknown characters on the screen of PC.
I also have tried similar method as suggested but the problem remains. The PIC reading is not the supposed data.

[mackrackit]

Here are several examples of serial in and out.
http://www.melabs.com/resources/samples/pbp/ser2mod.bas

Now for the

What should I do to avoid the data from crashing in Rx buffer of PIC UART, provided I cannot control over the stream of bytes received?

You are using software for serial so the only time anything gets into the PIC is when you ask for it. If you were using hardware then the buffers would need to be cleared.

'send byte to PC
SerOut2 PORTB.6,16572,[B0]

Earlier you said the PC was running the port at 9600? Did you change it for the above test to 4800?

And modifiers. The examples on the above link talks about DEC and such VS ASC||. You might need one.

[unifoxz]

Yes, I tried to set up a simple test to check what is actually happening on the bytes I receive. I use 4800 baud rate for both module and PC this time.

You are using software for serial so the only time anything gets into the PIC is when you ask for it. If you were using hardware then the buffers would need to be cleared.

I tried with PIC hardware UART to receive the bytes from module too but the result is the same. The data is not the one it should be.

May I know how to clear hardware UART buffer? I tried to reset CREN and read in the data after the reset, it is not working as well. I am not sure whether it is the way to clear the buffer.