CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Problem with serial Communication using two PICs
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
xiantg



Joined: 21 Jan 2011
Posts: 9

View user's profile Send private message

Problem with serial Communication using two PICs
PostPosted: Fri Jan 21, 2011 11:43 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Sat Jan 22, 2011 6:23 am     Reply with quote

"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: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Jan 22, 2011 6:33 am     Reply with quote

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

View user's profile Send private message

PostPosted: Sat Jan 22, 2011 6:35 am     Reply with quote

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

View user's profile Send private message

PostPosted: Sat Jan 22, 2011 6:39 am     Reply with quote

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

View user's profile Send private message

PostPosted: Sat Jan 22, 2011 6:42 am     Reply with quote

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

View user's profile Send private message

PostPosted: Sat Jan 22, 2011 6:43 am     Reply with quote

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

View user's profile Send private message

PostPosted: Sat Jan 22, 2011 6:46 am     Reply with quote

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: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Jan 22, 2011 7:06 am     Reply with quote

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: 1910
Location: Norman, OK

View user's profile Send private message

PostPosted: Sat Jan 22, 2011 9:59 am     Reply with quote

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: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Jan 22, 2011 3:55 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Sat Jan 22, 2011 5:03 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Sun Jan 23, 2011 3:35 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Jan 24, 2011 7:56 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Jan 24, 2011 9:19 am     Reply with quote

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"
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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