 |
 |
| View previous topic :: View next topic |
| Author |
Message |
John Hopkins
Guest
|
| pic18lf4520 to pic18f4685 |
 Posted: Thu Jul 09, 2009 3:01 pm |
 |
|
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
|
|
| Posted: Fri Jul 10, 2009 11:40 am |
|
|
| 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
|
|
| Posted: Fri Jul 10, 2009 11:50 am |
|
|
| 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
|
|
| Posted: Fri Jul 10, 2009 11:54 am |
|
|
You're right.
Those same #define statements are in vs. 4.016. So it should compile
for him. |
|
|
John Hopkins
Guest
|
| Exactly |
| Posted: Fri Jul 10, 2009 1:31 pm |
|
|
| 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 |
| Posted: Fri Jul 10, 2009 1:38 pm |
|
|
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
|
|
| Posted: Fri Jul 10, 2009 1:47 pm |
|
|
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 |
| Posted: Fri Jul 10, 2009 3:08 pm |
|
|
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
|
|
| Posted: Fri Jul 10, 2009 3:35 pm |
|
|
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 |
| Posted: Fri Jul 10, 2009 3:37 pm |
|
|
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 |
| Posted: Fri Jul 10, 2009 4:14 pm |
|
|
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 |
|
|
|
|
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
