Serial port buffering and timing issues on PIC- Raspberry Pi

[Malakof]

Hi guys,

I am implementing a serial communication between PIC16F877 and Raspberry Pi model 2. Actually, i am sending strings from the PIC to the PI but i will have to implement the PI -> PIC as well. The PI side is written in Ruby using serialport gem.

I realized pretty quickly there was some issues. The straightforward method that is printf-ing in a while(true) loop on the PIC cause the stream (buffer?) to be corrupt, especially when i stop and restart the reading process on the PI. After that, the results are completely random, with all king of weird data that i didn't write sometimes mixed with legit data. At this point the only way to get back on my feet is to hard reset the PIC.

After that, as my real time needs is to send a pulse of about 200-300 char every second to the PI, I introduced a 1000ms delay between each series of printf and boom...its working.

So i am getting pretty confused, can somebody explain to me or point me on what's happening ? Seems to me there is a circular buffer that at some point gets overwritten. If any, what size is it and can we have any control on this buffer (emptying it, resetting it etc...) ?

Also is there a way to properly initialize the communication (delays or ?) so we don't have any issues at system startup ?


More generally, any info on what's happening under the hood will be much appreciated, as i need to build something reliable and i don't know if this "delay solution" is indeed a reliable one. I am wondering if this while(true) - delay - write loop in the main is not going to prevent me to read data from the PI in an interrupt (commented in the code below).

The code i use to write is pretty straightforward, thanks for any input you can provide me.

[Ttelmah]

Obviously if the Pi stops receiving, it's internal buffer on it's UART is going to overrun. The PIC can keep sending the data perfectly, but with no pause, there is nothing to re-sync. If characters contain 'lows' but in the wrong place, these will be seen as start bits, so the results will be random garbage.

As a further comment, even a PC would have problems if you send it data continuously at 10000 characters per second.

Just a one character pause in transmission would be enough to allow re-sync (however remember the UART buffer needs to empty - two character times extra).

[temtronic]

quick reply....
That PIC only has a 2-3 byte buffer in the hardware UART so you need to look at the CCS example 'ex_sisr.c' to see how to implement an ISR driven rcv buffer.
There are other examples if you search this forum, too hot for me to do that for you though.

There is also a serial transmit ISR with buffer 'somewhere'. Both xmt and rcv should be used.

Jay

[Ttelmah]

Agreed on the receive (it looks as though he already intends to do that with the remmed out interrupt lines), but currently he is just transmitting continuously. To expect RS232 to reliably re-sync, if the receiving device (the Pi), stops receiving, is where the problem lies. Normally it will, provided there is an occasional break in the data, but he doesn't have this without the delay.....

Separately there is the question of how he is actually connecting the interface?.
The Pi, uses 3.3v. The PIC he is using is a 5v device (4.5v minimum at 20MHz). If he is directly connecting there is a significant risk of damaging the Pi.

[Malakof]

Thanks for your input ! I ll dig into this, and let you know how it goes.

[Malakof]

Ok, thanks, now working with a similar buffer code that is in ex_sisr.c.