| View previous topic :: View next topic |
| Author |
Message |
Watchdog
Joined: 17 Oct 2005
Posts: 2
Location: Asturias (Spain)
|
| Problems when changing from USART to EUSART |
 Posted: Mon Oct 17, 2005 9:58 am |
 |
|
Somebody knows why a program in which the serial communications (USART) worked perfectly with a PIC16F87A (with USART) doesn't do the same in a PIC18F2520 (with EUSART).
Are there incompatible?.
thx
------------
Pues eso, que si alguien sabe por qué las comunicaciones serie que funcionaban perfectamente con la USART de un 16F876A ya no lo hacen si te pasas a un PIC con EUSART (p.ej. 18F2520)
Gracias |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Oct 17, 2005 11:47 am |
|
|
| Quote: |
Somebody knows why a program in which the serial communications
(USART) worked perfectly with a PIC16F87A (with USART) doesn't do
the same in a PIC18F2520 (with EUSART). |
1. Post a very small program that shows the problem. Show all the
#fuses, #use, and #include statements. Make sure the program
is complete and can be compiled. Don't post code fragments.
2. Post your compiler version. This will be a number like 3.191, or
3.236, etc. |
|
|
Watchdog
Joined: 17 Oct 2005
Posts: 2
Location: Asturias (Spain)
|
|
| Posted: Tue Oct 18, 2005 6:20 am |
|
|
Here is the code. We have proved with a wide range of baud rates, so that's not the problem. THe characters are sended right (tested with Hyperterminal), but the receiver PIC corrupts them. We have thought it was a matter of auto baudrate but after reading Microchip datasheets, we think this is a EUART bug. We have tried too with other EUART PICS so like PIC18f2620 and the result ist the same. DOes anybody know how to solve this problem? Thanks.
| Code: |
//Transmitter code
#include <18F2520.h>
#fuses XT, PROTECT, PUT, NOWDT, NOBROWNOUT, NOLVP, NOCPD, NOWRT
#use delay(clock=4000000)
#use rs232(baud=1200,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,ERRORS)
void main( void )
{
while(true){
printf("hello%c",0x0D); //message and carriage return
delay_ms(1000);
}
}
|
| Code: |
//Receiver code
#include <18F2520.h>
#include <string.h>
#include <stdlib.h>
#fuses XT, PROTECT, PUT, NOWDT, NOBROWNOUT, NOLVP, NOCPD, NOWRT
#use delay(clock=4000000)
#use rs232(baud=1200,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,ERRORS)
char txt[10];
char txt2[]="hello";
#int_RDA
void ISR(){
gets(txt);
}
void main( void )
{
output_low(PIN_B7); //pin conected to a LED
enable_interrupts(GLOBAL);
enable_interrupts(INT_RDA);
while(true){
if(strcmp(txt,txt2)==0)
output_high(PIN_B7);
}
}
|
Compiler version: 3.235 |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Tue Oct 18, 2005 10:15 am |
|
|
Inside the Isr for RDA there is a gets(txt)
I believe gets will wait until a null is received.
RDA is called for each char received so you might want to consider using
getc( c) and stuffing c into a receive buffer and incrementing the received buffer index ( in other words write a circular buffer). |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Oct 18, 2005 12:51 pm |
|
|
I looked at the .LST file a little bit, and the setup for the three main
UART registers looked OK. The baud rate value was correct.
As Mr. Kennedy says, I wouldn't normally write code like that, with
a gets() function inside the int_rda. Look at EX_SISR.C in this folder:
c:\Program Files\Picc\Examples
If you think the receiver side is bad, then write a simple test program
that echoes each received character back to the PC.
| Quote: | void main()
{
int8 c;
while(1)
{
c = getc();
putc(c);
}
} |
Run that program and type characters from your PC terminal window.
See if they come back OK. |
|
|
Watchdog
Joined: 17 Oct 2005
Posts: 2
Location: Asturias (Spain)
|
| thx |
| Posted: Wed Oct 19, 2005 6:38 am |
|
|
Thanks for all the replies. Perhaps we have not chosen the best one example code. 
We have already fixed the problem. We think the failure was in the autobauding. When we test with the PC the transmision was OK, but with the RF modules it wasn´t. We fix the problem sending a string before the relevant characters of the transmission because the first characters are corrupted. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Wed Oct 19, 2005 7:54 am |
|
|
I think there is an errata which says to the effect that autobaud is broken
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
