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 CCS Technical Support

#use rs232 problem on PIC18F1320

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
ritchie



Joined: 13 Sep 2003
Posts: 87

View user's profile Send private message

#use rs232 problem on PIC18F1320
PostPosted: Thu Mar 04, 2004 9:10 pm     Reply with quote

Hi

I have a problem with my #use rs232 directives, the compiler error says "baud rate out of range".

Any help on this problem, a comments or suggestions will do or a code snippet to resolve this?

My code is listed below:

Code:

#include <18F1320.h>                        // MCU specific library
#device *=16                                // use a 16-bit pointer
#fuses INTRC_IO,NOLVP,NOWDT,NOPROTECT,MCLR  // MCU fuse configuration
#use delay (clock=8000000)                  // 8MHz internal clock speed

#use rs232(baud=115200,parity=N,xmit=PIN_B1,rcv=PIN_B4,bits=8)

main()
{
   delay_ms(3000);
  setup_oscillator(OSC_8MHZ | OSC_INTRC);

   while(1){
    ......
     ......
    ......
   }
}


Thanx
Neutone



Joined: 08 Sep 2003
Posts: 839
Location: Houston

View user's profile Send private message

PostPosted: Thu Mar 04, 2004 10:17 pm     Reply with quote

The baud must be a rate that the hardware can generate from the oscilator. You max baud rate is going to be 38.4Kbps when you use that 8Mhz crystle. Pick a crystle that has one of those funny numbers like 19660800 or 9830400 or 4915200. The crystle should be a multiple of the maximum baud rate or at least close.
SteveS



Joined: 27 Oct 2003
Posts: 126

View user's profile Send private message

PostPosted: Fri Mar 05, 2004 8:19 am     Reply with quote

I had the exact same problem yesterday.

Looks like you want to still use the internal oscillator, and if so you can't do 115200 as Neutone explained. You can do 100000 or some other rate that divides down nicely from 8Mhz, but then it's non-standard.

Too bad they didn't make the internal osc more baud friendly.

- SteveS
Ttelmah
Guest







PostPosted: Fri Mar 05, 2004 11:06 am     Reply with quote

SteveS wrote:
I had the exact same problem yesterday.

Looks like you want to still use the internal oscillator, and if so you can't do 115200 as Neutone explained. You can do 100000 or some other rate that divides down nicely from 8Mhz, but then it's non-standard.

Too bad they didn't make the internal osc more baud friendly.

- SteveS

Actually, I think the problem here is that the compiler is not behaving as though it is aware of all the controls for the BRG on this chip.
If you look at the data sheet, with BRGH set to 0, and BRG16 set to 0, the highest baud rate shown in the table (for an 8MHz clock), is 9600bps, with SPBRG=12. With BRGH set to 1, the highest baud rate shown, rises to 57600, but with 3.5% error, which is uncomfortably high. However is BRG16, and BRGH are both set high, 115200, is shown as available with a 2.12% timing error, and SPBRG=16.
I think the compiler is not aware of the BRG16 bit, since this does not exist on a lot of chips. I'd try the experiment of defining this bit, and asking for a baud rate of 28800bps (which should give SPBRG=16, BRGH=1), and then setting BRG16 to 1.

Best Wishes
SteveS



Joined: 27 Oct 2003
Posts: 126

View user's profile Send private message

PostPosted: Fri Mar 05, 2004 12:20 pm     Reply with quote

I think you are right - I was using a 2320 not a 1320. I thought they were the same except for the number of I/O pins. The 1320 has the EUART which has the extra features you mentioned which should make it work. The 2320 is the older style UART and cannot be set close enough to 115200.

Another fine point I need to remember.....

SteveS
Guest








PostPosted: Fri Mar 05, 2004 5:14 pm     Reply with quote

SteveS wrote:
I think you are right - I was using a 2320 not a 1320. I thought they were the same except for the number of I/O pins. The 1320 has the EUART which has the extra features you mentioned which should make it work. The 2320 is the older style UART and cannot be set close enough to 115200.

Another fine point I need to remember.....

SteveS


I try the extra features of the EUART setting the SPBRG=16., BRGH=1,SYNC=1 and other register in order to have a 115200bps on a 8MHz but to no avail I can't make it work.
SteveS



Joined: 27 Oct 2003
Posts: 126

View user's profile Send private message

PostPosted: Mon Mar 08, 2004 9:18 am     Reply with quote

Does it work with a baud that the compiler accepts (like 9600)?

If it does, that tells us if your oscillator is truly at 8MHz and the basic code is right and then it's something about setting up the registers 'by hand'. Post a short piece of code like you did initially with the extra register setups in there.

If it doesn't work then look at those problems. For instance, set the internal RC to put the clock out on the CLK OUT pin so you can verify you're at 8MHz.

- SteveS
Ttelmah
Guest







PostPosted: Mon Mar 08, 2004 9:56 am     Reply with quote

Anonymous wrote:
SteveS wrote:
I think you are right - I was using a 2320 not a 1320. I thought they were the same except for the number of I/O pins. The 1320 has the EUART which has the extra features you mentioned which should make it work. The 2320 is the older style UART and cannot be set close enough to 115200.

Another fine point I need to remember.....

SteveS


I try the extra features of the EUART setting the SPBRG=16., BRGH=1,SYNC=1 and other register in order to have a 115200bps on a 8MHz but to no avail I can't make it work.


As I said, I suspect the compiler doesn't know about SPBRG. Hence try selecting 28800, which requires the same multiplier, but with SPBRG=0, and then manually turn on SPBRG. This compiles OK for me, and gives the correct register values.
Setting 'sync=1', sets the chip to run in synchronous mode (not normal async comms). Do you really mean to do this?.

Best Wishes
ritchie



Joined: 13 Sep 2003
Posts: 87

View user's profile Send private message

PostPosted: Mon Mar 08, 2004 5:32 pm     Reply with quote

Ttelmah wrote:

As I said, I suspect the compiler doesn't know about SPBRG. Hence try selecting 28800, which requires the same multiplier, but with SPBRG=0, and then manually turn on SPBRG. This compiles OK for me, and gives the correct register values.
Setting 'sync=1', sets the chip to run in synchronous mode (not normal async comms). Do you really mean to do this?.

Best Wishes


Hi Ttelmah,

You're right the SYNC should be zero instead of 1. Good News I have coded it successfully running a 115.2kbps on a 8MHz internal oscillator of PIC18F1320. I'd love to share the code snippet below:

The code list:

Code:


#include <18F1320.h>             // MCU specific library
#device *=16
#fuses INTRC_IO,NOLVP,NOWDT,NOPROTECT,MCLR
#use delay (clock=8000000)       // 8MHz clock

#byte OSCCON = 0xFD3
#byte SPBRGH = 0xFB0
#byte SPBRG  = 0xFAF
#byte TXREG  = 0xFAD

#bit  BRG16  = 0xFAA.3
#bit  BRGH   = 0xFAC.2
#bit  SYNC   = 0xFAC.4
#bit  SPEN   = 0xFAB.7
#bit  TX9    = 0xFAC.6
#bit  TXEN   = 0xFAC.5
#bit  TXIF   = 0xF9E.4
#bit  TXIE   = 0xF9D.4

#define LED    PIN_A2

void led_func()
{
      output_high(LED);
      delay_ms(1000);
      output_low(LED);
      delay_ms(1000);
}


main()
{
   delay_ms(2000);
   setup_oscillator(OSC_8MHZ|OSC_INTRC);
   setup_adc_ports(NO_ANALOGS);
   
   SPBRGH = 0;
   SPBRG = 16;
   BRG16 = 1;
   BRGH = 1;
   SYNC = 0;
   SPEN = 1;
   TX9 = 0;
   TXEN = 1;
   TXIF = 0;
   //enable_interrupts(int_tbe);
   //enable_interrupts(global);

   while(TRUE)
   {
      led_func();
      TXREG = 'A';
   }
}



Hope this could be useful in the community.

Thanx for the help...

I love this forum.
ritchie



Joined: 13 Sep 2003
Posts: 87

View user's profile Send private message

PostPosted: Mon Mar 08, 2004 5:43 pm     Reply with quote

Hi,

I am also trying to code the UART reception? What I have shared above is for UART transmission on a PIC18F1320.

How can I be able to detect if an error occur during reception? How can I clear the error? I read the datasheet and I notice that UART transmission is much simplier than UART reception. My target chip is PIC18F1320.

Need your help.

Thank u.
SteveS



Joined: 27 Oct 2003
Posts: 126

View user's profile Send private message

RS232 error detection
PostPosted: Tue Mar 09, 2004 7:36 am     Reply with quote

I didn't notice a #USE RS232 in your code. If you use that (then correct the baud error in main), then just add ERRORS to save the most current error in RS232_ERRORS - see the CCS help on #USE RS232. If you intend to roll your own serial I/O handler, then just check the error flags in the RCSTA register - bit 1 is overrun error and bit 2 is framing error.

- SteveS
Neutone



Joined: 08 Sep 2003
Posts: 839
Location: Houston

View user's profile Send private message

PostPosted: Tue Mar 09, 2004 8:27 am     Reply with quote

ritchie wrote:
Hi,

I am also trying to code the UART reception? What I have shared above is for UART transmission on a PIC18F1320.

How can I be able to detect if an error occur during reception? How can I clear the error? I read the datasheet and I notice that UART transmission is much simplier than UART reception. My target chip is PIC18F1320.

Need your help.

Thank u.


Notify CCS of your results and request compiler support. The compiler should reach the full potiential of the chip.
ritchie



Joined: 13 Sep 2003
Posts: 87

View user's profile Send private message

Re: RS232 error detection
PostPosted: Wed Mar 10, 2004 5:25 pm     Reply with quote

SteveS wrote:
I didn't notice a #USE RS232 in your code. If you use that (then correct the baud error in main), then just add ERRORS to save the most current error in RS232_ERRORS - see the CCS help on #USE RS232. If you intend to roll your own serial I/O handler, then just check the error flags in the RCSTA register - bit 1 is overrun error and bit 2 is framing error.

- SteveS


Yes I didn't use #use rs232 in the code. With regards to error I am going to use my own error handler.

The code below is for reception and transmission. Hope this helps...

Code:

#include <18F1320.h>             // MCU specific library
#device *=16
#fuses INTRC_IO,NOLVP,NOWDT,NOPROTECT,MCLR
#use delay (clock=8000000)       // 8MHz clock

#byte OSCCON = 0xFD3
#byte SPBRGH = 0xFB0
#byte SPBRG  = 0xFAF
#byte TXREG  = 0xFAD
#byte RCSTA  = 0xFAB
#byte RCREG  = 0xFAE

#bit  BRG16  = 0xFAA.3
#bit  BRGH   = 0xFAC.2
#bit  SYNC   = 0xFAC.4
#bit  SPEN   = 0xFAB.7
#bit  TX9    = 0xFAC.6
#bit  TXEN   = 0xFAC.5
#bit  TXIF   = 0xF9E.4
#bit  TXIE   = 0xF9D.4

#bit  RX9    = 0xFAB.6
#bit  CREN   = 0xFAB.4
#bit  RCIF   = 0xF9E.5
#bit  FERR   = 0xFAB.2
#bit  OERR   = 0xFAB.1

#define LED    PIN_A2

char rcvChar = 0;
char txvChar = 0;

#int_rda
void rda_isr()
{
   rcvChar = RCREG;
   if (OERR){
      CREN = 0;
      #asm nop #endasm
      CREN = 1;
   }

}

void led_func()
{
      output_high(LED);
      delay_ms(1000);
      output_low(LED);
      delay_ms(1000);
}


main()
{
   delay_ms(2000);
   setup_oscillator(OSC_8MHZ|OSC_INTRC);
   setup_adc_ports(NO_ANALOGS);

   SPBRGH = 0;
   SPBRG = 16;
   BRG16 = 1;
   BRGH = 1;
   SYNC = 0;
   SPEN = 1;
   TX9 = 0;
   TXEN = 1;
   TXIF = 0;

   RX9 = 0;
   CREN = 1;
   RCIF = 0;

   enable_interrupts(int_rda);
   //enable_interrupts(int_tbe);
   enable_interrupts(global);

   while(TRUE)
   {
      led_func();
      TXREG = 'A';
      TXREG = ' ';
      TXREG = rcvChar;
   }
}



Thanx for the help.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
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