| View previous topic :: View next topic |
| Author |
Message |
xiantg
Joined: 21 Jan 2011
Posts: 9
|
| Problem with serial Communication using two PICs |
 Posted: Fri Jan 21, 2011 11:43 pm |
 |
|
Sir,
Problem: 1) I am using PCWH 3.242 CCS compiler. I want to know that what time this instruction takes: [ Reset_CPU( ) ; ] and what type of this reset is ? Due to avoid error percent error in serial communication of PIC, I want to reset PIC after receiving specific number of bytes during continuous serial communication. I want to know that because of this reset, PIC will lose data or not during continuous serial communication at baud rate 9600?
Problem: 2) Another problem is this that I am sending a file of size 100 KB from serial port of one PC to serial port of another PC through two PICs ( PIC16F877A). One PC sends data serially to first PIC then this PIC sends this data to second pic trough PORT D. The Second PC receiving this data through its PORT D and send this data to second PC serially.
After receiving 10KB HyperTerminal shows Message " Bad Data value". and this message is repeated five to 10 time during receiving of file of size 100KB. Some times HyperTerminal shows message "Connection timed out"
Problem: 1 and Problem: are interrelated. Due to avoid message "Bad value data " from HyperTerminal I want to reset PIC because I think this problem is due to percent error in serial communication of PIC.
Specification:
1) Oscillator used: 20MHZ
2) HyperTerminal is used for sending and receiving data from PIC.
3) Baud Rate is 9600.
4) File transfer protocol used in HyperTerminal is Zmodem.
5) Connections of serial cable that connects PIC with PC are null Modem connections.
It is requested that please give me detailed reply of above mentioned problems
Thank You
Last edited by xiantg on Sat Jan 22, 2011 6:28 am; edited 1 time in total |
|
 |
SherpaDoug
Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA
|
|
| Posted: Sat Jan 22, 2011 6:23 am |
|
|
"Due to avoid error percent error in serial communication of PIC, I want to reset PIC after receiving specific number of bytes during continuous serial communication."
This does not make sense to me. What type of serial error are you hoping to solve with a Reset_CPU()? It won't have any effect on a speed error. There are better ways to deal with parity and framing errors.
RS232 comms should resync itself every byte with the Start and Stop bits. Are you using hardware or software UARTs on the PICs? What are you using for a clock? The internal oscillators are usually poor for serial comms.
_________________
The search for better is endless. Instead simply find very good and get the job done. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario
|
|
| Posted: Sat Jan 22, 2011 6:33 am |
|
|
You'll have to read the datasheets about the specific PIC that you are using to get specific timings, which are dependent on the 'master clock' you use(20MHz).Also read the sections on reset as well as the instruction set details.
Print a copy of the dotLST file for your program.It will show you everything you need to calculate the timings you say you need.
Be aware that Hyperterminal is not 'bullitproof', and that you may have problems with it.There are other 'terminal programs' that work better.
I'd try a PC to PC link first to see it Hyperterminal or the PCs are causing errors.By eliminating the PICs, their hardware and software you will greatly reduce your time to fix your problem.
As far as hardware goes, be sure to use proper RS232 interface chips and good wiring practices.
With respect to the PIC code, be sure to use the 'errors' option in the use rs232() function !, Also use a buffer for both xmt and rcv data in both PICs.PICs with the right program will easily transfer your data without problems at even faster speeds than the 9600 baud you're using.
Once you have the PC1-->PC2 working 100%, then try
PC1-->PIC1-->PC2 and get it working 100%
finally PC1-->PIC1-->PIC2-->PC2
It'll be the fastest way to debug your overall project |
|
|
xiantg
Joined: 21 Jan 2011
Posts: 9
|
|
| Posted: Sat Jan 22, 2011 6:35 am |
|
|
| SherpaDoug wrote: | "Due to avoid error percent error in serial communication of PIC, I want to reset PIC after receiving specific number of bytes during continuous serial communication."
This does not make sense to me. What type of serial error are you hoping to solve with a Reset_CPU()? It won't have any effect on a speed error. There are better ways to deal with parity and framing errors.
RS232 comms should resync itself every byte with the Start and Stop bits. Are you using hardware or software UARTs on the PICs? What are you using for a clock? The internal oscillators are usually poor for serial comms. |
In datasheet of PIC16F877, it is mentioned that if baud rate is 9600, crystal frequecy 20MHZ and BRGH = 1 then percentage error in communication .If communication lasts for a long time then this error may produce accumulative effect on communication.
I am using 20MHZ External crystal. |
|
|
xiantg
Joined: 21 Jan 2011
Posts: 9
|
|
| Posted: Sat Jan 22, 2011 6:39 am |
|
|
| SherpaDoug wrote: | "Due to avoid error percent error in serial communication of PIC, I want to reset PIC after receiving specific number of bytes during continuous serial communication."
This does not make sense to me. What type of serial error are you hoping to solve with a Reset_CPU()? It won't have any effect on a speed error. There are better ways to deal with parity and framing errors.
RS232 comms should resync itself every byte with the Start and Stop bits. Are you using hardware or software UARTs on the PICs? What are you using for a clock? The internal oscillators are usually poor for serial comms. |
In datasheet of PIC16F877, it is mentioned that if baud rate is 9600, crystal frequecy 20MHZ and BRGH = 1 then percentage error in communication .If communication lasts for a long time then this error may produce accumulative effect on communication.
I am using 20MHZ External crystal. |
|
|
xiantg
Joined: 21 Jan 2011
Posts: 9
|
|
| Posted: Sat Jan 22, 2011 6:42 am |
|
|
| temtronic wrote: | You'll have to read the datasheets about the specific PIC that you are using to get specific timings, which are dependent on the 'master clock' you use(20MHz).Also read the sections on reset as well as the instruction set details.
Print a copy of the dotLST file for your program.It will show you everything you need to calculate the timings you say you need.
Be aware that Hyperterminal is not 'bullitproof', and that you may have problems with it.There are other 'terminal programs' that work better.
I'd try a PC to PC link first to see it Hyperterminal or the PCs are causing errors.By eliminating the PICs, their hardware and software you will greatly reduce your time to fix your problem.
As far as hardware goes, be sure to use proper RS232 interface chips and good wiring practices.
With respect to the PIC code, be sure to use the 'errors' option in the use rs232() function !, Also use a buffer for both xmt and rcv data in both PICs.PICs with the right program will easily transfer your data without problems at even faster speeds than the 9600 baud you're using.
Once you have the PC1-->PC2 working 100%, then try
PC1-->PIC1-->PC2 and get it working 100%
finally PC1-->PIC1-->PIC2-->PC2
It'll be the fastest way to debug your overall project |
Thank you temtronic for your detailed reply, I will follow your prescribed prcedure. |
|
|
xiantg
Joined: 21 Jan 2011
Posts: 9
|
|
| Posted: Sat Jan 22, 2011 6:43 am |
|
|
| xiantg wrote: | | SherpaDoug wrote: | "Due to avoid error percent error in serial communication of PIC, I want to reset PIC after receiving specific number of bytes during continuous serial communication."
This does not make sense to me. What type of serial error are you hoping to solve with a Reset_CPU()? It won't have any effect on a speed error. There are better ways to deal with parity and framing errors.
RS232 comms should resync itself every byte with the Start and Stop bits. Are you using hardware or software UARTs on the PICs? What are you using for a clock? The internal oscillators are usually poor for serial comms. |
In datasheet of PIC16F877, it is mentioned that if baud rate is 9600, crystal frequecy 20MHZ and BRGH = 1 then percentage error in communication .If communication lasts for a long time then this error may produce accumulative effect on communication.
I am using 20MHZ External crystal.and hardware UART |
|
|
|
xiantg
Joined: 21 Jan 2011
Posts: 9
|
|
| Posted: Sat Jan 22, 2011 6:46 am |
|
|
In datasheet of PIC16F877, it is mentioned that if baud rate is 9600, crystal frequecy 20MHZ and BRGH = 1 then percentage error in communication is 0.16 .If communication lasts for a long period of time then this error may produce accumulative effect on communication.
I am using 20MHZ External crystal.and hardware UART |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario
|
|
| Posted: Sat Jan 22, 2011 7:06 am |
|
|
Well, in the 25 years of programming PICS I've never seen "If communication lasts for a long period of time then this error may produce accumulative effect on communication." That happen and some of my PICs have been running 24/7/365 for 6 years at 19,200 Baud!
The keyword is MAY ! 1000's of 'what-if' things can happen.
That statement also doesn't consider temperature effects on the xtal or caps either ! You can stay up all night calculating the math to see what happens when the temperature shift 20*C in a few hours.
You can also lose a lot of sleep over designing the power supply to NOT 'dip' during a brownout condition, or the PICs resetting due to a MIG welder badly arcing 3 doors down on rusty metal.
Then there's the 'Windows' problems. Simply stated, since Windows and HyperTerminal are not running in 'realtime', you're prone to problems. Things as simple as your antivirus program looking for the latest download will cause HT to produce errors!
You're focussing on the wrong area! As I said earlier, get the PC-PC link 100% right first, then PC-pic-PC 100% right, then PC-PIC-PIC-PC, in that order.
Build up from a known good start, then you'll have an idea where the next problem is coming from. |
|
|
dyeatman
Joined: 06 Sep 2003
Posts: 1934
Location: Norman, OK
|
|
| Posted: Sat Jan 22, 2011 9:59 am |
|
|
I can't agree with the "cumulative effect". In RS232 you have Start
(synchronization) bits and stop bits. The timing of each character
transmission is an independent transmission. One character will not affect
the next. In addition, using the hardware UART, the UART will handle most
bit and framing errors. If a software UART is used there is much more of a chance for problems.
_________________
Google and Forum Search are some of your best tools!!!! |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario
|
|
| Posted: Sat Jan 22, 2011 3:55 pm |
|
|
Actually you can get it, IF the baud rate is low and the distance is far and you use R/C circuit for the clock circuit AND the data is sent continuously.
What happens is a 'stretchout' of the bits due to distance v. capacitance of the lines.
In my case it was 24 Baud (yes, 24 bits per second), distance was up to 21 miles(yes, MILES), R/C oscillator using LM324 Op Amp.
First 'cure' was to use higher quality R/Cs (tempco killed that idea), finally used xtal with divider chain, has worked flawlessly for the past 20+ years(24/7/365).
It is very, very unlikely to occur 'in the lab', except at very high baud rates(over 900K baud), sloppy wiring, etc. |
|
|
SherpaDoug
Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA
|
|
| Posted: Sat Jan 22, 2011 5:03 pm |
|
|
Another problem could be if the first PC is sending data at say 9600.1 baud non-stop, and the second PIC is sending at 9599.9 baud. After a long time the 0.2 baud difference will cause bytes to back up in the PICs at a rate of an extra byte every 5 seconds. Eventually the PICs will run out of buffer space and bytes will be lost or corrupted. Depending on the exact size of the baud rate errors, which could change with temperature or supply voltage, this effect could take hours or days to appear.
_________________
The search for better is endless. Instead simply find very good and get the job done. |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sun Jan 23, 2011 3:35 am |
|
|
| Quote: | | Eventually the PICs will run out of buffer space and bytes will be lost or corrupted. |
Yes, if the application won't utilize ZMODEM flow control to pause the sender in this case. But the original
poster didn't tell about the application details and we can't know if this problem exists. |
|
|
xiantg
Joined: 21 Jan 2011
Posts: 9
|
|
| Posted: Mon Jan 24, 2011 7:56 am |
|
|
I have tested PC----->PC link with hyperterminal, Vb and another datalogger software. It is perfect. I have also tested PC1--->PIC1---->PIC2----->PC2 with other datalogger but problem is that PICs are losing data whether using hyperterminal, Vb or other datalogger software.
I have made shematic of this circuit in Orcade but I do not know how to convert it into image so that I could be able to post it.
| Code: |
#include <16f877A.h>
#fuses HS,NOPROTECT,NOLVP,NOWDT
#use delay(clock=11059200)
#use rs232(baud=9600,parity=E,xmit=PIN_C6,rcv=PIN_C7,bits=7)
#define Interrupt_INT0 PIN_E0
#define Test4 PIN_B4 //pin37
#define Test5 PIN_B5 //pin38
#use Fast _IO(D)
unsigned Char RecChar;
//*************************************************
#int_rda
void serial_isr()
{
RecChar = getch();
Set_tris_D(0x00);
output_D(RecChar);
output_high(Interrupt_INT0);
output_LOW(Interrupt_INT0);
Set_tris_D(0xFF);
}
//*************************************************
#int_EXT
void External_Interrupt_isr()
{
unsigned char Data;
Data = input_D();
putc(Data);
}
//*************************************************
void main()
{
int A = 0, B = 1, C;
Set_tris_D(0xFF);
Set_tris_E(0x00);
output_LOW(Interrupt_INT0);
enable_interrupts(int_EXT);
ext_int_edge(L_TO_H);
enable_interrupts(int_rda);
enable_interrupts(global);
while(TRUE)
{
}
Reset_CPU();
}
|
Vb code is same on both PC
| Code: | Dim comdata As Integer
Dim rxState As Integer
Private Sub cmdSend_Click()
Dim a As String
Dim B As String
Dim c As String
Dim d As String
Dim intotal As Integer
Open App.Path & "\123.txt" For Input As #1
Input #1, a
Input #1, B
Input #1, c
For p = 0 To 10000
MSComm1.Output = Chr$(2) & a & vbCrLf & Chr$(13) & Chr$(3)
MSComm1.Output = Chr$(2) & B & vbCrLf & Chr$(13) & Chr$(3)
MSComm1.Output = Chr$(2) & c & vbCrLf & Chr$(13) & Chr$(3)
Next p
Close #1
End Sub
Private Sub CmdExit_Click()
MSComm1.PortOpen = False
Close #3
End
End Sub
Private Sub Form_Load()
MSComm1.CommPort = 1
MSComm1.Settings = "9600,E,7,1"
MSComm1.InputLen = 1
MSComm1.RThreshold = 1
MSComm1.PortOpen = True
Open "TransLog.txt" For Output As #3
rxState = 0
End Sub
Private Sub MSComm1_OnComm()
comdata = Asc(MSComm1.Input)
Print #3, Chr$(comdata);
End Sub
|
Last edited by xiantg on Tue Jan 25, 2011 11:47 pm; edited 1 time in total |
|
|
xiantg
Joined: 21 Jan 2011
Posts: 9
|
|
| Posted: Mon Jan 24, 2011 9:19 am |
|
|
| Quote: | Are you using hardware or software UARTs on the PICs? What are you using for a clock? The internal oscillators are usually poor for serial comms."
|
I am using hardware UART and external crystal oscillator of two pins | Quote: | | But the original poster didn't tell about the application details and we can't know if this problem exists. |
Problem: 2) Another problem is this that I am sending a file of size 100 KB from serial port of one PC to serial port of another PC through two PICs ( PIC16F877A). One PC sends data serially to first PIC then this PIC sends this data to second pic trough PORT D. The Second PC receiving this data through its PORT D and send this data to second PC serially.
After receiving 10KB HyperTerminal shows Message " Bad Data value". and this message is repeated five to 10 time during receiving of file of size 100KB. Some times HyperTerminal shows message "Connection timed out" |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
