| View previous topic :: View next topic |
| Author |
Message |
mat72
Joined: 19 Jan 2006
Posts: 11
|
| Incorrect Serial Communications |
 Posted: Thu Jan 19, 2006 4:46 pm |
 |
|
I've written a simple program for a 18F4550 chip. I have a MAX323 chip properly connected for serial communications. When I receive the bytes on the computer, they are incorrect. I've sent the following:
0xfc
0xfd
0xfe
0xff
then recieve
F8
FB
FC
FF
When I reverse the order, I get the same output but reversed. Using prinf("Hello World") also sends an incorrect string(this is why Im sending the hex values). I've tried 2 pics and replaced an old max232 with a brand new one. I've double checked all connections. I've also used the correct port settings on each side.
Here is my code
| Code: | #include <18F4550.h>
#include <ctype.h>
//#fuses HS,WDT128,NOPROTECT,NOLVP
#use delay(clock=20000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7) // Jumpers: 8 to 11, 7 to 12
//#build(reset=0x1, interrupt=0x5) // Necessary for Bootloader
#org 0x082a,0x7fff // Necessary for Bootloader
//#opt 9
void main() {
set_tris_d(0); // port c as output;
set_tris_b(0xff); // port b as uinput;
//output_high(PIN_D0);
//output_high(PIN_D1);
output_d(0xff);
delay_ms(20);
//printf("Hello World\n\r");
putc(0xfc);
putc(0xfd);
putc(0xfe);
putc(0xff);
//putc('A');
while(true){
if(input(PIN_B0)){
output_high(PIN_D0);
}else{
output_low(PIN_D0);
//printf("Test\n\r");
}
}
}
|
Thanks,
Matt |
|
 |
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Thu Jan 19, 2006 7:03 pm |
|
|
Interesting. You appear to be losing the most significant bit. Is the device the PIC is talking to a PC? If so are you sure you have configured it for 8 data bits, 1 stop bit and no parity?
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
mat72
Joined: 19 Jan 2006
Posts: 11
|
|
| Posted: Thu Jan 19, 2006 9:01 pm |
|
|
| asmallri wrote: | | Interesting. You appear to be losing the most significant bit. Is the device the PIC is talking to a PC? If so are you sure you have configured it for 8 data bits, 1 stop bit and no parity? |
Yep... All of the above.
Matt |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Jan 19, 2006 9:22 pm |
|
|
Your program is way too complicated to debug this problem. You should
use a much more simple program, such as the one shown below.
This program will send "UUUUUUUU" to the terminal program.
If you have an oscilloscope, measure the duration of one bit,
as sent out by the program below.
| Code: | #include <18F452.H>
#fuses XT,NOWDT,NOPROTECT,BROWNOUT,PUT,NOLVP
#use delay (clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
//==============================
void main()
{
while(1)
{
putc(0x55);
delay_ms(1);
}
} |
|
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Thu Jan 19, 2006 9:33 pm |
|
|
If the serial format is correct then there is a mismatch between the bit clocks of the PC and the PIC. Because the data is close to being correct, if it had been a PIC18F452 type processor, I would have suggested checking you have a correctly loaded crystal.
The PIC you are using has a far more complex clocking system and this is where I think your problem lies. Because you are using a bootloader I suggest looking at the fuses configured for the bootloader and the loading of the crystal.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
mat72
Joined: 19 Jan 2006
Posts: 11
|
|
| Posted: Fri Jan 20, 2006 3:08 pm |
|
|
| asmallri wrote: | If the serial format is correct then there is a mismatch between the bit clocks of the PC and the PIC. Because the data is close to being correct, if it had been a PIC18F452 type processor, I would have suggested checking you have a correctly loaded crystal.
The PIC you are using has a far more complex clocking system and this is where I think your problem lies. Because you are using a bootloader I suggest looking at the fuses configured for the bootloader and the loading of the crystal. |
I have a 20 Mhz Crystal. I'm not using the boot loader anymore. here are my Configuration bits
Clock src from 96Mhz PLL/2
[OSC1/OSC2 Src: /4] [96Mhz PLL Src: /6]
Divide by 5 (20Mhz input)
HS: HS+PLL, USB-HS
Thanks,
Matt |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Fri Jan 20, 2006 3:31 pm |
|
|
| Is there a common ground for the PC and the PIC board? Try that. |
|
|
mat72
Joined: 19 Jan 2006
Posts: 11
|
|
| Posted: Fri Jan 20, 2006 3:59 pm |
|
|
| yep |
|
|
Eugeneo
Joined: 30 Aug 2005
Posts: 155
Location: Calgary, AB
|
|
| Posted: Fri Jan 20, 2006 9:01 pm |
|
|
| pulse a pin using the delay command and check it on the scope. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Sat Jan 21, 2006 1:16 am |
|
|
| mat72 wrote: | | asmallri wrote: | If the serial format is correct then there is a mismatch between the bit clocks of the PC and the PIC. Because the data is close to being correct, if it had been a PIC18F452 type processor, I would have suggested checking you have a correctly loaded crystal.
The PIC you are using has a far more complex clocking system and this is where I think your problem lies. Because you are using a bootloader I suggest looking at the fuses configured for the bootloader and the loading of the crystal. |
I have a 20 Mhz Crystal. I'm not using the boot loader anymore. here are my Configuration bits
Clock src from 96Mhz PLL/2
[OSC1/OSC2 Src: /4] [96Mhz PLL Src: /6]
Divide by 5 (20Mhz input)
HS: HS+PLL, USB-HS
Thanks,
Matt |
Post the actual code for setting the fuses and the clock. I think the problem is the clock configuration.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Ttelmah
Guest
|
|
| Posted: Sat Jan 21, 2006 4:20 am |
|
|
Looking at this, it sounds like master clock=20MHz. /5, to give 4Mhz for USBPLL. PLL gives 96MHz then using /6, gives a processor clock of 16Mhz, not 20MHz. The fact that /6 is mentioned, suggests this may be what is happening.
Best Wishes |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
