gnupic: Re: [gnupic] errors in header p18f4550.inc with gputils 0.13.5-beta
Subject:
Re: [gnupic] errors in header p18f4550.inc with gputils 0.13.5-beta
From:
David ####@####.####
Date:
6 Nov 2007 00:05:45 +0000
Message-Id: <20071105190342.27b0bab3@DEEPTHOUGHT.BARNET.net>
On Sun, 04 Nov 2007 05:01:44 -0300
"Nestor A. Marchesini" ####@####.#### wrote:
> El 03/11/07 09:00, David escribió:
> > On Sat, 03 Nov 2007 03:45:29 -0300
> > "Nestor A. Marchesini" ####@####.#### wrote:
> >
> >> ...
> >> and it should be:
> >> _FCMEN_OFF_1H EQU H'BF ; M -> N
> >> _FCMEN_ON_1H EQU H'FF' ; M -> N
I fixed the bad header file in SVN (r499), and I also updated the
definitions that made the CONFIG directive fail (r500). More details
below...
> >
> > I also noticed from p18f4550.inc:
> > ...
> >
> > gputils now supports the CONFIG directive (as opposed to
> > '__CONFIG'). It looks like these definitions in this and similar
> > headers should be uncommented now...?
I did some digging and answered my own question. I don't think they're
used at all by gpasm either in absolute or relocatable mode, so they
can stay commented.
> I was using MPLAB 7.62 with (kqemu + qemu + winme) and it generates
> warnings df that uses the new directive CONFIG,
> but assemble without problems.
> ...
> Not which will be the mistake, but for the present time I will
> continue using __CONFIG
> in my opinion gpasm would do what MPLAB did ... a warning, but that
> assemble.
As I remember it, MPASM warns you to use the new CONFIG directive
instead of the old __CONFIG. I don't think gpasm gives that warning,
but that's a separate issue from these errors. Can you confirm this is
the warning you're talking about?
> ...
> Now if I use CONFIG I obtain mistakes in FCMEN = OFF and BORV = 3
> ...
> Error [176] : CONFIG Directive Error: (setting not found for
> selected processor)
> 30000C 400F 00046 CONFIG FCMEN = OFF
> Error [176] : CONFIG Directive Error: (specified value not valid for
> directive)
> 00047 CONFIG BORV = 3
>
> I have modified the file p18f4550.inc, but one sees that it is not
> there where looks gpasm at the assemble.
That's correct. These parameters come from libgputils/gpcfg-table.c and
need to be compiled in. I just updated this file fresh from the
definitions used in MPASM 5.13 (the version that comes with MPLAB
7.62), so the options allowed should be identical now. I tested for
FCMEN and BORV, so please give those a shot again and (@everyone)
consider switching over to the CONFIG directive. Microchip is giving
deprecation warnings for the __CONFIG directive with 18F chips, so we
should start testing the new CONFIG support and phasing out the old
__CONFIG for the 18F's.
Thanks a lot for reporting the issue!
David Barnett
