 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Arup
Guest
|
| Issue with serial communication between PIC18F6585 and PC |
 Posted: Fri Jun 13, 2008 3:37 am |
 |
|
Dear Sir,
I am having problem in serial communication between PIC18F6585(USART) and PC (RS-232)
Hardware Used :
a) PIC18F6585
b) Crystal : 20 MHz , with external capacitor 15pF
c) MAX232CPE level shifter with capacitors 1uF / 63V
d) Only Rx , Tx , Gnd pins are used for RS-232 comm.
Software :
a) CCS C compiler Ver. 4.065
b) A window based serial port Terminal Application called “Real Term “ is used to send and receive stream of data between PIC and PC.
Test Setup :
A stream of data will be transmitted to PIC from PC and after a delay ,say, 1 sec. PIC will retransmit those received data bytes back to PC.That we can see on “Real Term “
Observation :
Data is getting corrupted . The few observations are given below .
From PC : 5A 32 33 34 35 36 37 38
From Pic : 5A 32 33 34 35 36 37 38
From PC : 5A 32 33 34 35 36 37 38
From Pic : 5A 32 33 34 35 36 37 38
From PC : 5A 32 33 34 35 36 37 38
From Pic : 5A 32 33 34 35 36 13 FE
From PC : 5A 32 33 34 35 36 37 38
From Pic : 5A 32 26 53 93 D3 13 FE
From PC : 5A 32 33 34 35 36 37 38
From Pic : 5A 32 33 34 4D D3 13 FE
From PC : 5A 32 33 34 35 36 37 38
From Pic : 5A 32 33 34 35 36 37 38
Trouble Shoot :
a) Considering for Framing Error I checked the OSC frequency. There is no noticeable deviation .
b) There is no noticeable noise in receive line (both from PC to MAX and MAX to PIC )
Below is C code :
| Code: |
#include <18F6585.h>
#fuses HS,NOWDT,NOPROTECT,NOLVP
#use delay(clock=20000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, BITS = 8 ,ERRORS)
#define BUFFER_SIZE 32
BYTE buffer[BUFFER_SIZE];
BYTE next_in = 0;
BYTE next_out = 0;
#int_rda
void serial_isr() {
int t;
buffer[next_in]=getc();
t=next_in;
next_in=(next_in+1) % BUFFER_SIZE;
if(next_in==next_out)
next_in=t; // Buffer full !!
}
#define bkbhit (next_in!=next_out)
BYTE bgetc() {
BYTE c;
while(!bkbhit);
c=buffer[next_out];
next_out=(next_out+1) % BUFFER_SIZE;
return(c);
}
void main() {
enable_interrupts(int_rda);
enable_interrupts(global);
// The program will delay for 1 seconds and then display
// any data that came in during the 1 second delay
do {
delay_ms(1000);
while(bkbhit)
putc(bgetc());
} while (TRUE);
}
|
Could anyone pls tell me where I am missing out . Pls suggest.
Regards,
Arup |
|
 |
Ttelmah
Guest
|
|
| Posted: Fri Jun 13, 2008 7:33 am |
|
|
A comment (not the problem).
In general, avoid using the % BUFFER_SIZE method of handling the buffer. The problem with this, is that if the buffer is _not_ a nice binary number (yours is), this takes a _lot_ of time. Hence it is 'better' to use:
| Code: |
if (++next_out == BUFFER_SIZE) next_out=0;
|
This only involves an increment and test, and typically codes about 50* faster for non binary buffer sizes!.
CCS use the % form, and with binary buffer sizes, the compiler is 'smart' enough, to not actually perform the % operation, but use a simple binary '&' instead. However it is a 'trap' which will cause poor buffer performance if you latter switch to a different size...
Now, there is nothing wrong with the code.
You do not show, or mention, what values you have setup the PC for, for parity, or have this set on the PIC. Potentially this could cause a framing error, but it'd be repeatable.
You do have a 'noise' problem somewhere!...
With a framing error, if you draw out the binary patterns for the sent, and received values, there will be a pattern. So you will see the highs and lows that should be there, but sampled early/late, transmitted early/late, or sampled more often/less often than they should be. For the '13', versus '37', this could be the case (in the binary sequence, each has three sections that are '0'). However on the next line, you have 26, for a 33. The latter gives the binary sequence:
10110011001
The former gives:
10101001001
Notice that you have more edges in the result, than are in the source. The only way this can happen, is that the there is noise of some sort.
Also, a framing error, will pretty much be repeatable (unless you just happen to be right 'on' a edge). Notice that you have several lines of the same data, giving different results.
Obvious things to look at are that the voltage levels, are high enough to be seen as a '1' by the PIC. The UART input, is normally a ST type input, not a TTL input, and therefore needs a higher drive voltage. A line that was just 'borderline' on going high enough, might give your problem. Also, look very carefully at the grounding between the sections.
Well done by the way, for posting just about everything involved in your problem, without getting too long!...
Best Wishes |
|
|
Lucifix
Guest
|
| Framing error solved |
| Posted: Tue Jun 17, 2008 4:25 am |
|
|
Hello,
I've had the same problem... I use PIC18F6585 with 10 MHz Xtal running at maximum speed (X4_SW oscillator configuration). After some days of searching, the solution (simple as is) comes from Software. My RS-232 communication parameters are: Baud 115200, Harware Flow Control, 8N1 and no line/char delays. The CCS compiler settings regarding RS-232 are all good except SPBRG register. In my case, the "default" CCS value of 86 (decimal) for SPBRG register gives to me at RX only framing errors and a lot of garbage. So, the solution that worked in my case was to manualy change SPBRG register's value from 86 to 85 (decimal) ... and the problem is gone!
I hope this will help!
Lucifix |
|
|
Ttelmah
Guest
|
|
| Posted: Tue Jun 17, 2008 2:57 pm |
|
|
The compilers version, is closer than yours....
The 'correct' counter value (if allowed) value, would be 85.8. The compiler at 86, is closer than you are -0.2% error, versus +0.9%. Neither should give problems. The only reasons that the faster rate would work, are:
1) Your crystal is running significantly slow - remember to allow for the PCB capacitance, and pin capacitance, when calculating the loading capacitors.
2) Your PC is clocking the UART fast (not that unusual - I have commonly seen a couple of percent timing errors on PC comm port timings, especially when 'spread spectrum' is enabled in the BIOS - some chipsets unfortunately modulate the UART clock as well as the processor clock when this is selected...).
The data you had, would not have gained extra clock edges.
Best Wishes |
|
|
arup
Guest
|
| Issue with serial communication between PIC18F6585 and PC |
| Posted: Tue Jun 17, 2008 11:55 pm |
|
|
Thanks Ttelmah for your explaination & quicki response.
i couldn't understand the .......
| Quote: |
For the '13', versus '37', this could be the case (in the binary sequence, each has three sections that are '0'). However on the next line, you have 26, for a 33. The latter gives the binary sequence:
10110011001
The former gives:
10101001001
Notice that you have more edges in the result, than are in the source.
|
'37' & '13' are hex value .How these will give binary sequence "10101001001 " . could you pls explain me in detail.
I did few experiment there after .
setting on PIC as well as PC : 9600 ,8 ,N ,1
1) I have run the same code(modifying only the #include<16f877.h>) with PIC16F877 on PIC demo board and 20MHz crystal (15pF) from the the same lot (from which i have used with PIC18F6585) .
I didn't face any problem sending data to PIC and receiving the same on PC.Absolutely no error .
2) I also did the same as Lucifix did .I ran the same code with PIC18F6585
Compiler generated value for SPBRGH : SPBRG was 0x208(error 0.03%) . Then i have experimented with different valuues (+1/-1) .But i found 0x207 was better. Now problem seems to be vanished some extent . But i should check it's reliability.But see with new value baudrate error has increased (0.16 %).But still it's result is much better .
3) The third experiment i did was changing the baudrate in PIC(18F6585) as well as in PC to 19200 from 9600 . That too helped me. There is no problem.
4) I have tried changing PC from different make.
Now what i can conclude from above experiment .
Same lot crystal( 20Mhz ,15pF) i used with different chip and PCB .And noticed different result. Now PIC18F6585 & PCB capacitance could be factor. What do you suggest ?? And can PCB capacitance be a such amajor factor ??
I can't conclude that crystal is running faster / slower .
Could any one pls tell me what can be done to work @9600 baud based on my above experiment.
Regards,
Arup |
|
|
Ttelmah
Guest
|
|
| Posted: Wed Jun 18, 2008 2:10 am |
|
|
The line always starts high (1). Then the 'start' bit (0), then the byte, sent LSb first, then assuming no parity, the line returns high (stop bit).
The extra 1's at the end, should really be xxxx10bbbbbbbb1xxxxx, where the 'x's are the previous and next bytes, and 'bbbbbbbb' is the bit pattern for the byte. If parity is enabled/selected, this adds an extra bit between the last 'b', and the '1'.
If you take the byte, and put it into (say) the calculator on the PC, in 'hex' mode, then select binary mode, you get the bit pattern for the byte itself, in the opposite order to the way it is sent (and remember you have to 'pad' to 7 or eight bits). The padding bits will all be zeros.
Best Wishes |
|
|
Lucifix
Guest
|
| Framing errors |
| Posted: Sat Jul 05, 2008 11:41 am |
|
|
I must say that I'm Not happy with my solution to framing errors problem. Although it work flawless with 115200 baud, it's definitely useless when I try to implement AutoBaud rutines. Should I try to tweakle the oscillator's external caps? Does anybody have any ideea besides those radical solutions like changing the PCB, changing the chip or the manufacturer  ?
A nice day to all!
Lucifix |
|
|
Ttelmah
Guest
|
|
| Posted: Sat Jul 05, 2008 2:54 pm |
|
|
Before anything else, try changing the MAX232, to a 232A. 115200bps, is borderline for the maximum rate supported by the former. Your real problem may simply be that the slew rate of the chip, is itself distorting the waveform, and changing the clock rate is just fractionally helping....
If you have a DFM, then test your real chip clock rate. Don't attach it to the crystal (doing this, changes the loading on crystal, and gives an erroneous result), program a PWM output pin,and measure the frequency on this.
Yes, for really 'fine' timing, getting the crystal loading capacitors 'right', and allowing for the PCB capacitance in calculating this is vital, _but_ RS232, is not that critical. Normally at over 3% error, will have no noticeable effect.
How long is the wire?. What sort of wire is it?.
I'd suspect you have a line problem at the faster rate.
Best Wishes |
|
|
Lucifix
Guest
|
|
| Posted: Sun Jul 06, 2008 3:57 am |
|
|
Yes, Your assumption is correct! I do have a line problem at any faster data rate (not only at 115200 baud) and I'm saying that because there aren't any issues if I manually send characters using Hyperterminal to the PIC uController. I use a 2 meters DB9(M) -> DB9(F) RS-232 cable.
I've changed the default RS-232 level shifter (ISL3232ECBL -- 3 to 5V) with another one (MAX232 -- 5V) but useless. Though, I didn't try anything with 'A' at the end. I'm thinking to switch to TI chips maybe I'll have some luck with those ICs... I want to mention that PIC18F6585 chip is powered using a 5V linear regulator (78M05).
In the last days I made some experiments with PIC18F452 uC. I keept the PIC18F6585 in reset and wired the '452 to ISL3232ECBL level shifter using the same RS-232 cable, the same Hyperterminal settings and same baud rate (115200) & faster data rate.
Conclusion:
THERE WERE ANY PROBLEMS AT ALL!!! I strongly believe that NOT the RS-232 level shifter, nor the PC or cable but the PIC18F6585's "enhanced" USART module is the source of my problems (or the controller itself). Now, I'll have to search for another one in TQFP 64 package hoping that it will have the '452's "normal" UART module.. if there's any...
A lot of time and energy wasted... 
Kind regards!
Lucifix |
|
|
Ttelmah
Guest
|
|
| Posted: Sun Jul 06, 2008 9:42 am |
|
|
This reinforces the problem being with the line drivers.
The big difference with the EUSART module, is that it performs three point sampling on the incoming data, requiring the signal to be _stable_ at multiple points through the bit, rather than just at the centre of the bit. This is a _good thing_, since it shows problems that _will_otherwise lead to data corruption latter. You have a connection problem, which the EUSART is seeing, and you are 'getting away with' on the USART, _but_ it is unsafe to assume this is the case.
You are probably 'over spec', with 2m of cable at 115200bps...
RS232, has a reducing 'distance supported', with baud rate used, depending on capacitance. The maximum allowed, with normal cable, is already down to just 2.6m at 56000bps - compared to 60m at 2400bps!...
While it is quite common to 'stretch' the spec, and get away with it, I'd suggest that you are borderline in several areas.
The point about the 'A' version, is it is specified to 200Kbps, while the standard MAX232, is only specified to 120Kbps _maximum_, and in some circumstances as little as 64Kbps. It is not the chip to use at the higher rates.
Get a low capacitance cable, shorten it is possible, and switch to drivers rated for the frequency, and you should find the problems dissappear.
Best Wishes |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
