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 support@ccsinfo.com

pic18lf4520 to pic18f4685

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







pic18lf4520 to pic18f4685
PostPosted: Thu Jul 09, 2009 3:01 pm     Reply with quote

I wrote a program that works great in the pic18lf4520. Since I am low on program memory I am trying to use it in the pic18f4685. However, the code that compiles with only 2 warnings for the pic18lf4520 will not compile for the pic18f4685.

The compiler does not understand even the most basic #defines like putc. I checked the 18f4685 header file and putc is correctly defined. It is defined the exact same way in the 18f4520 header file.

I read that the pic18f4685 was just added in compiler version 4. I am running 4.016, and I am wondering if this version is too old to have a stable compile for the 18f4685. I noticed that all the people on this forum talking about this pic are running a newer compiler version.

I would like to know if this is a basic compiler issue, before I try writing small test programs.

Thanks.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Jul 10, 2009 11:40 am     Reply with quote

Quote:
The compiler does not understand even the most basic #defines like putc

putc() is not a #define. It's a built-in function of the compiler.

I installed vs. 4.016, and compiled the test program shown below.
It compiled with no errors:
Quote:
BUILD SUCCEEDED: Fri Jul 10 10:23:06 2009

Code:

#include <18F4685.h>
#fuses XT,NOWDT,PUT,BROWNOUT,NOLVP
#use delay(clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)

//================================
void main()
{

putc('A');

while(1);
}
mkuang



Joined: 14 Dec 2007
Posts: 257

View user's profile Send private message Send e-mail

PostPosted: Fri Jul 10, 2009 11:50 am     Reply with quote

Quote:

putc() is not a #define. It's a built-in function of the compiler.


In the 18f4685.h file there is this:

Code:

#define getc getch
#define fgetc getch
#define getchar getch
#define putc putchar
#define fputc putchar
#define fgets gets
#define fputs puts


Looks like putc is a #define for putchar or am I missing something?
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Jul 10, 2009 11:54 am     Reply with quote

You're right.

Those same #define statements are in vs. 4.016. So it should compile
for him.
John Hopkins
Guest







Exactly
PostPosted: Fri Jul 10, 2009 1:31 pm     Reply with quote

PCM programmer wrote:
You're right.

Those same #define statements are in vs. 4.016. So it should compile
for him.


Yeah, that's what I meant when I said that I checked the header. Sorry if that was unclear.

What I'm trying to say is, basically nothing will compile. The compiler gets hundreds of errors with basic statements, like putc. If I compile it for the 4520, there are no errors and two minor warnings. This seems to suggest that the compiler for the 4685 is unstable in v.4.016. That's all I'm asking. Even if I can use work-arounds, I am not willing to trust that an unstable compiler can handle my ~2000 line program (which works great in the 4520).

I am still trying to determine whether the problem is with the compiler, or with me. Maybe I'm making a really basic error.

Here's some additional info:

My header is:

#include <18F4685.h>
#device PASS_STRINGS = IN_RAM
#include <stdio.h>
#include <string.h>
#include <command_list.h>

#use delay(INTERNAL=8M, clock=16M)
#fuses INTRC, NOPUT, NOBROWNOUT, NOWDT, NOLVP//, DEBUG

Thanks,
JH
John Hopkins
Guest







Re: Exactly
PostPosted: Fri Jul 10, 2009 1:38 pm     Reply with quote

And for rs232:

#use rs232(BAUD=9600, XMIT=PIN_A1, RCV=PIN_A0, BITS=8, PARITY=N)

Thanks,
JH
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Jul 10, 2009 1:47 pm     Reply with quote

What happens if you try to compile my little test program ?

I think you need to put the statements in the correct order in your
program, as shown below. Then it should work:

Code:
#include <18F4685.h>
#device PASS_STRINGS = IN_RAM
#fuses INTRC, NOPUT, NOBROWNOUT, NOWDT, NOLVP//, DEBUG
#use delay(INTERNAL=8M, clock=16M)
#use rs232(BAUD=9600, XMIT=PIN_A1, RCV=PIN_A0, BITS=8, PARITY=N)
#include <stdio.h>
#include <string.h>
#include <command_list.h>

//================================
void main()
{

putc('A');

while(1);
}
John Hopkins (2)
Guest







Order doesn't seem to be the problem
PostPosted: Fri Jul 10, 2009 3:08 pm     Reply with quote

Thanks for responding so quickly.

PCM programmer wrote:
What happens if you try to compile my little test program ?

I think you need to put the statements in the correct order in your
program, as shown below. Then it should work:

Code:
#include <18F4685.h>
#device PASS_STRINGS = IN_RAM
#fuses INTRC, NOPUT, NOBROWNOUT, NOWDT, NOLVP//, DEBUG
#use delay(INTERNAL=8M, clock=16M)
#use rs232(BAUD=9600, XMIT=PIN_A1, RCV=PIN_A0, BITS=8, PARITY=N)
#include <stdio.h>
#include <string.h>
#include <command_list.h>

//================================
void main()
{

putc('A');

while(1);
}



I tried compiling your test program, and it compiles/runs correctly.
I also tried compiling a test program with my header, and it also compiles/runs correctly:


#include <18F4685.h>
#device PASS_STRINGS = IN_RAM
#include <stdio.h>
#include <string.h>
#include <command_list.h>

#use delay(INTERNAL=8M, clock=16M)
#fuses INTRC, NOPUT, NOBROWNOUT, NOWDT, NOLVP//, DEBUG

#use rs232(BAUD=9600, XMIT=PIN_A1, RCV=PIN_A0, BITS=8, PARITY=N)

//================================
void main()
{

putc('A');

while(1);
}

Both your test and mine compile and run correctly on both the 18lf4520 and the 18f4685.

My main program with both your header and mine compile and run correctly on the pic18lf4520.

However, the main program will not compiles on the 18f4685 with either your order or mine.

My order has always worked, as far as I know, on the 18f4520.

You still might be right about the order.

What order do you recommend for port maps? (see below)

Using your order, I do

#use rs232 (several rs232 driver, etc)
#include <stdio.h> etc.
port maps

I am also starting to wonder whether the 4685 and the 4520 use the same environment variables. Besides failing to compile rs232 code, it also consistently chokes on the following port map.

struct porte_pin_map {
unsigned short PIO5;
unsigned short Phone_RST;
unsigned short VREG_ERROR;
} porte;

#locate porte = getenv("sfr:PORTE")

However, the lines above it don't return errors:

struct portd_pin_map {
unsigned short Phone_Power;
unsigned short Phone_ON;
unsigned short MP_TX;
unsigned short MP_RX;
unsigned short PWRMON;
unsigned short GPIO6;
unsigned short GPIO7;
unsigned short GPIO3;
} portd;

#locate portd = getenv("sfr:PORTD")

It seems to have no trouble with the sfrs for PORTA-PORTD, but fails on PORTE. The 18f4520 and 18f4685 both have the PORTE sfr mapped to F84h.

Unless the compiler is just spitting out junk...

Think I should just upgrade the compiler?
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Jul 10, 2009 3:35 pm     Reply with quote

Yes. I couldn't get it compile for getenv for PortD or PortE with vs. 4.016.
Upgrade it.
John Hopkins (2)
Guest







It was the compiler version
PostPosted: Fri Jul 10, 2009 3:37 pm     Reply with quote

I just got it to compile by doing an upgrade.

The program consistently failed to compile with ccs v4.016 in mplab v8.1.

My program compiles correctly on ccs v4.085 in mplab v8.2.

I haven't tested it in a pic yet, but it does compile correctly.

I'll let you guys know as soon as its working in a pic.

Thanks for the help PCM programmer and mkuang.

JH
John Hopkins (2)
Guest







Compiler upgrade worked
PostPosted: Fri Jul 10, 2009 4:14 pm     Reply with quote

The compiler upgrade solved the problem. The program works fine in the pic18f4865. We now have lots of room to expand the program. Thanks again for the help.

JH
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