![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
Malakof
Joined: 24 Jul 2015 Posts: 3
|
Serial port buffering and timing issues on PIC- Raspberry Pi |
Posted: Wed Jul 29, 2015 7:40 am |
|
|
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.
Code: |
#include <16F877A.h>
#device ADC=16
#FUSES NOWDT //No Watch Dog Timer
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#use delay(crystal=20000000)
#use rs232(baud=115200,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8)
#ZERO_RAM
void main()
{
delay_ms(500);
// enable_interrupts(INT_RDA);
// enable_interrupts(GLOBAL);
while(true) {
delay_ms(1000); // Without this, it's not working, why ?
printf("Blah Blah Blah....Blah Blah Blah....Blah Blah Blah....Blah Blah Blah....Blah Blah Blah....Blah Blah Blah....Blah Blah Blah....Blah Blah Blah....Blah Blah Blah....Blah Blah Blah....Blah Blah Blah....Blah Blah Blah....");
printf("\r"); // reading line by line on the other side
}
}
|
|
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19367
|
|
Posted: Wed Jul 29, 2015 8:13 am |
|
|
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). |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Wed Jul 29, 2015 8:13 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19367
|
|
Posted: Wed Jul 29, 2015 8:36 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Malakof
Joined: 24 Jul 2015 Posts: 3
|
|
Posted: Wed Jul 29, 2015 10:32 am |
|
|
Thanks for your input ! I ll dig into this, and let you know how it goes. |
|
![](templates/subSilver/images/spacer.gif) |
Malakof
Joined: 24 Jul 2015 Posts: 3
|
|
Posted: Wed Aug 05, 2015 3:14 pm |
|
|
Ok, thanks, now working with a similar buffer code that is in ex_sisr.c. |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|