 |
 |
| View previous topic :: View next topic |
| Author |
Message |
progCCSC
Guest
|
| problem of RS232 , thanks for all the help coming... |
 Posted: Fri Apr 06, 2007 1:33 am |
 |
|
I use this program to receive a data and then transmit it for 10 times, and I have this result:
I transmit to PIC18F452 from a terminal PC these datas:
0 1 2 3 4 5 6 7 8 9
I got :
38 39 3A 3B 3C 3D 3E 3F 38 39
and LCD affiche: -56 -55 -54 -53
| Code: | #include <18F452>
#fuses HS, NOPROTECT, NOWDT, NODEBUG, NOLVP, PUT
#use delay(clock=20000000)
#use rs232(baud=115200,xmit=PIN_C6,rcv=PIN_C7,bits=8)
#include <LCD.c>
void main()
{
int8 data[10],i,j;
lcd_init();
for(i=0;i<10;i++)
{
data[i]=getc();
putc(data[i]);
printf(lcd_putc,"%d",data[i]);
delay_ms(500);
}
} |
|
|
 |
progCCSC
Guest
|
| up |
| Posted: Fri Apr 06, 2007 3:19 am |
|
|
| up up!! sos! |
|
|
Ttelmah
Guest
|
|
| Posted: Fri Apr 06, 2007 9:08 am |
|
|
How is the connection to the PC made?. Have you tested a much simple 'Hello world' type transmission only? Does this work?.
Best Wishes |
|
|
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
| Posted: Fri Apr 06, 2007 9:32 am |
|
|
| Code: |
include <18F452>
#fuses HS, NOPROTECT, NOWDT, NODEBUG, NOLVP, PUT
#use delay(clock=20000000)
#use rs232(baud=115200,xmit=PIN_C6,rcv=PIN_C7,bits=8)
#include <LCD.c>
int8 data[10],i;
void main()
{
lcd_init();
while(1)
{
i=0;
do
{
data[i]=getc();
putc(data[i]);
i++;
}while(i<10);
for(i=0;i<10;i++;)
{
printf(lcd_putc,"%d",data[i]);
delay_ms(500);
}
}
}
|
Humberto |
|
|
Ttelmah
Guest
|
|
| Posted: Fri Apr 06, 2007 10:00 am |
|
|
Yes. This avoids the timing problem, but the timing, shouldn't affect the first couple of bytes, hence my feeling that there is a hardware problem as well...
Best Wishes |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Fri Apr 06, 2007 10:26 am |
|
|
ProgCCSC, which compiler version are you using?
How is the PC connected to the PC? Are you using an inverter chip like the MAX232? |
|
|
progCCSC
Guest
|
| .. |
| Posted: Mon Apr 09, 2007 2:16 pm |
|
|
| Ttelmah wrote: | How is the connection to the PC made?. Have you tested a much simple 'Hello world' type transmission only? Does this work?.
Best Wishes |
I used max232 for the connection, and I tested what you said, but it didn't work  |
|
|
progCCSC
Guest
|
| thanks |
| Posted: Mon Apr 09, 2007 2:24 pm |
|
|
to Humberto: thanks very much! I will try it.
to ckielstra: I use version 3.187 with MPLAB v7.41, is there some problem with it?
to every, as terminal PC, what you are using?..... I use "Free Serial Port Monitor." |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Apr 09, 2007 2:28 pm |
|
|
This schematic shows an 18F452 connected to a MAX232A.
You don't need CTS and RTS. You just need Tx, Rx, and Ground.
They show the connections to a DB9F connector. Then just use
a straight-through cable to connect the board to your PC.
(The cable is wired with pin 1 to pin 1, pin 2 to pin 2, etc).
http://www.picbook.com/bookinfo/QwikFlash.pdf
Note that a MAX232 uses 1 uF capacitors. The MAX232A uses .1 uF caps. |
|
|
Ttelmah
Guest
|
|
| Posted: Mon Apr 09, 2007 3:04 pm |
|
|
OK.
Receiving '38', for '30' sent (a ASCII zero, is x30), implies that the incoming signal is being sampled slightly too early. If this was what was being seen, I'd be looking at the timing error. However the display value of -56, corresponds to 0xC8, which doesn't agree with a timing error. Effectively, looking at the bit patterns concerned, organised in the order the UART sees them, you get:
| Code: |
0x30 10000011001
0x38 10000111001
0xC8 10000101011
|
Now you can see that while the second, could potentially 'happen', if the system was just fractionally early when it sampled the sixth bit, it'd have to be at normal times, or latter to still get the next two '1's. The third combination though, just doesn't work, having an extra '0' inserted.
I'd start with a much simpler test. First verify _everything_ (clock frequency - program an output pin to toggle at an interval, and check it with an oscilloscope, or stopwatch), then all the connections - is the ground good etc. etc.. Triple check baud rate settings, word length, etc.. Then do a simple program, to send 0xAA 0x55. The hex value of the bytes seen at the PC, may make it obvious what is going on.
Best Wishes |
|
|
progCCSC
Guest
|
| still... |
| Posted: Tue Apr 10, 2007 2:12 am |
|
|
thank you very much for your help, I haven't resolu my problem and I have also a strange problem , I set baud rate=115200, but if I set also baud rate=115200, there is noting received. I have to set baud rate =9600 for the terminal PC.
| Ttelmah wrote: | OK.
Receiving '38', for '30' sent (a ASCII zero, is x30), implies that the incoming signal is being sampled slightly too early. If this was what was being seen, I'd be looking at the timing error. However the display value of -56, corresponds to 0xC8, which doesn't agree with a timing error. Effectively, looking at the bit patterns concerned, organised in the order the UART sees them, you get:
| Code: |
0x30 10000011001
0x38 10000111001
0xC8 10000101011
|
Now you can see that while the second, could potentially 'happen', if the system was just fractionally early when it sampled the sixth bit, it'd have to be at normal times, or latter to still get the next two '1's. The third combination though, just doesn't work, having an extra '0' inserted.
I'd start with a much simpler test. First verify _everything_ (clock frequency - program an output pin to toggle at an interval, and check it with an oscilloscope, or stopwatch), then all the connections - is the ground good etc. etc.. Triple check baud rate settings, word length, etc.. Then do a simple program, to send 0xAA 0x55. The hex value of the bytes seen at the PC, may make it obvious what is going on.
Best Wishes |
|
|
|
Ttelmah
Guest
|
|
| Posted: Tue Apr 10, 2007 2:37 am |
|
|
Whoa a sec. What you are saying here, disagreed with what you have _posted_ You talk about receiving a particular pattern of data, with code working at 115200bps, but now you arwe saying you are working at 9600bps....
The figures _must_ be the same at both ends. If you need to set the PC to 9600bps to get anything received, then set the PIC code to the same rate. Triple check your crystal. Are you _sure_ this is 20Mhz, and is actually running at 20MHz. Put an LED on a single pin (with a current limiting resistor), and have a program like:
| Code: |
main {
while (TRUE) {
output_toggle(whatever_pin_the_LED_is_on);
delay_ms(1000);
}
}
|
Does the LED flash on for one second, off for one second, etc.. If not, then your crystal is not running at 20Mhz.
One possibility, is that your wiring, is not capable of working at 115200 bps.
Best Wishes |
|
|
progCCSC
Guest
|
|
| Posted: Tue Apr 10, 2007 7:01 am |
|
|
to Ttelmah: thank you for your patience.
Now, Yes, I have done a error, I will expicate it now.
My clock is 12 MHz,--------I'm sure it's right, so 20MHz wasn't right. I have changed it to 12MHz, but it did not use for settle the problem.
What I have said there 1h ago wasn't clear.
Now, I use this programme
| Code: | #include <18F452>
#fuses HS,NOWDT,NOPROTECT,NOPUT,BROWNOUT,NOLVP,CCP2C1,NOSTVREN,NOWRT,NOCPB,NOEBTRB,NODEBUG
#use delay(clock=12000000)
#use rs232(baud=9600,xmit=PIN_C6,rcv=PIN_C7,bits=8)
#include </drivers>
int8 data[10],i;
void main()
{
lcd_init();
while(1)
{
i=0;
do
{
data[i]=getc();
putc(data[i]);
i++;
}while(i<10);
for(i=0;i<10;i++)
{
printf(lcd_putc,"%c",data[i]);
delay_ms(500);
}
}
} |
Pour receive I use a terminal PC, I set 9600 baud rate as the program.
I transmit:
61 62 63 64 30 31 32 33 34 35 36 37 61 62 63 abcd01234567abc
I received:
80 80 80 80 80 80 80 80 80 80 |
|
|
progCCSC
Guest
|
|
| Posted: Tue Apr 10, 2007 7:04 am |
|
|
Pour receive I use a terminal PC, I set 9600 baud rate as the program.
I transmit:
61 62 63 64 30 31 32 33 34 35 36 37 61 62 63
It corresponds: abcd01234567abc
I received:
80 80 80 80 80 80 80 80 80 80
It corresponds: [/quote] |
|
|
progCCSC
Guest
|
|
| Posted: Tue Apr 10, 2007 7:11 am |
|
|
So if I change the clock to 20MHZ and the baud rate to 115200bps | Code: | #include <18F452>
#fuses HS,NOWDT,NOPROTECT,NOPUT,BROWNOUT,NOLVP,CCP2C1,NOSTVREN,NOWRT,NOCPB,NOEBTRB,NODEBUG
#use delay(clock=20000000)
#use rs232(baud=115200,xmit=PIN_C6,rcv=PIN_C7,bits=8)
#include </drivers>
int8 data[10],i;
void main()
{
lcd_init();
while(1)
{
i=0;
do
{
data[i]=getc();
putc(data[i]);
i++;
}while(i<10);
for(i=0;i<10;i++)
{
printf(lcd_putc,"%c",data[i]);
delay_ms(500);
}
}
}
I transmit:
61 62 63 64 65 67 68 30 38 39
It corresponds: abcdegh089
I received:
61 62 63 6C 65 67 60 38 38 39
It corresponds: abcleg`889
It seems that the parameter 20MHZ and 115200bps make the resultat the most close to what I want, its so strange
|
|
|
|
|
|
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
