gnupic: Thread: spelling mistake

    Hi,

        I am using the SDCC C compiler to compile programs for the
PIC18F442. Of course the support for the processor is not yet completed, but
there seems to be a spelling mistake to the .inc file in the header/
directory. The p18f442.inc file contains the following text at line  294

;----- OSCON Bits ---------------------------------------------------------
SCS EQU H'0000'

The problem is in the comment. The official name of the SFR is OSCCON and
OSCON, which is important even if it is placed in comment, because SDCC uses
a script file which creates various macros based on the comment text.

Will this be corrected in a future release, or should one patch the SDCC
script to handle this mistake?


Vangelis Rokas

PS. The same error is in p18f452.inc, p18f458.inc, p18f442.inc and
p18f448.inc files
but it is corrected in some other like p18f4320.inc !!

Vangelis Rokas said:
> The problem is in the comment. The official name of the SFR is OSCCON
> and OSCON, which is important even if it is placed in comment, because
> SDCC uses a script file which creates various macros based on the
> comment text.

So long as the SDCC header script relies on comment parsing for register
definitions, it will be prone to these sorts of errors. I tried to add
some "intelligence" to the script to handle the PIC16C745/765 USB
registers, and only succeeded in proving to myself that I still know how
to make write-only Perl code :-)

[dons flame-proof vest]

I know most of the people on this list don't like the idea of playing
around with MPLAB, but since gputils is pretty much going to be playing
catch-up to MPLAB for the foreseeable future, it really can't hurt to
install MPLAB every once in a while to see what's new.

MPLAB 6 has a nice feature in the "...\MPLAB IDE\Device" directory:
machine-readable descriptions of each processor's registers and memory
maps.

For instance:

  format=0.1

  #device=PIC16C765

  vpp (range=12.750-13.250  dflt=13.000)
  vdd (range=4.500-5.250  dfltrange=4.500-5.250  nominal=5.000)

  pgmmem (region=0x00-0x1FFF)
  cfgmem (region=0x2007-0x2007)
  testmem (region=0x2000-0x20FF)
  userid (region=0x2000-0x2003)

  NumBanks=4
  MirrorRegs (0x0-0x0  0x80-0x80  0x100-0x100  0x180-0x180)
[...]
  sfr (key=ADCON0 addr=0x1F size=1)
      reset (por='' mclr='')
      bit (names='ADCS1 ADCS0 CHS2 CHS1 CHS0 GO - ADON')
      bit (names='- - - - - NOT_DONE - -')
  sfr (key=ADCON1 addr=0x9F size=1)
      reset (por='' mclr='')
      bit (names='- - - - - PCFG2 PCFG1 PCFG0')

If I had time to fix it, I'd try and use these files. In fact, what
might be nice is a Perl class to insulate programmers from any changes
to this file format. I don't know what Microchip's license policy is on
these files, but there isn't so much as a copyright notice on them, and
since they were so kind as to provide the MPASM testsuite way back when,
they may be amenable to putting an agreeable license on these files as
well.

These files are at least used by the simulator UI, as I was able to create
my own register in one of the existing .dev files.

--
Charles Lepple ####@####.####
http://www.ghz.cc/charles/

----- Original Message ----- 
From: "Vangelis Rokas" ####@####.####
To: ####@####.####
Sent: Tuesday, May 06, 2003 4:19 PM
Subject: spelling mistake



> PS. The same error is in p18f452.inc, p18f458.inc, p18f442.inc and
> p18f448.inc files
> but it is corrected in some other like p18f4320.inc !!
> 

Here is a complete list of the header
p18c242.inc
p18c252.inc
p18c442.inc
p18c452.inc
p18c658.inc
p18c858.inc
p18f242.inc
p18f248.inc
p18f252.inc
p18f258.inc
p18f448.inc
p18f452.inc
p18f458.inc
p18f6620.inc
p18f6720.inc
p18f8620.inc
p18f8720.inc

----- Original Message -----
From: "Vangelis Rokas" ####@####.####
To: ####@####.####
Sent: Tuesday, May 06, 2003 4:19 PM
Subject: spelling mistake



> PS. The same error is in p18f452.inc, p18f458.inc, p18f442.inc and
> p18f448.inc files
> but it is corrected in some other like p18f4320.inc !!
>

Here is a complete list of the header file that have misspelled the OSCCON
SFR:

p18c242.inc
p18c252.inc
p18c442.inc
p18c452.inc
p18c658.inc
p18c858.inc
p18f242.inc
p18f248.inc
p18f252.inc
p18f258.inc
p18f448.inc
p18f452.inc
p18f458.inc
p18f6620.inc
p18f6720.inc
p18f8620.inc
p18f8720.inc

Charles Lepple wrote:
> 
> Vangelis Rokas said:
> > The problem is in the comment. The official name of the SFR is OSCCON
> > and OSCON, which is important even if it is placed in comment, because
> > SDCC uses a script file which creates various macros based on the
> > comment text.
> 
> So long as the SDCC header script relies on comment parsing for register
> definitions, it will be prone to these sorts of errors. I tried to add
> some "intelligence" to the script to handle the PIC16C745/765 USB
> registers, and only succeeded in proving to myself that I still know how
> to make write-only Perl code :-)
> 

The header files come from MPLAB.  I don't want to maintain a seperate
set of files.  Has any one told Microchip?  They might fix it.  I will
ask.

> [dons flame-proof vest]
> 
> I know most of the people on this list don't like the idea of playing
> around with MPLAB, but since gputils is pretty much going to be playing
> catch-up to MPLAB for the foreseeable future, it really can't hurt to
> install MPLAB every once in a while to see what's new.
> 
> MPLAB 6 has a nice feature in the "...\MPLAB IDE\Device" directory:
> machine-readable descriptions of each processor's registers and memory
> maps.
> 
> For instance:
> 
>   format=0.1
> 
>   #device=PIC16C765
> 
>   vpp (range=12.750-13.250  dflt=13.000)
>   vdd (range=4.500-5.250  dfltrange=4.500-5.250  nominal=5.000)
> 
>   pgmmem (region=0x00-0x1FFF)
>   cfgmem (region=0x2007-0x2007)
>   testmem (region=0x2000-0x20FF)
>   userid (region=0x2000-0x2003)
> 
>   NumBanks=4
>   MirrorRegs (0x0-0x0  0x80-0x80  0x100-0x100  0x180-0x180)
> [...]
>   sfr (key=ADCON0 addr=0x1F size=1)
>       reset (por='' mclr='')
>       bit (names='ADCS1 ADCS0 CHS2 CHS1 CHS0 GO - ADON')
>       bit (names='- - - - - NOT_DONE - -')
>   sfr (key=ADCON1 addr=0x9F size=1)
>       reset (por='' mclr='')
>       bit (names='- - - - - PCFG2 PCFG1 PCFG0')
> 
> If I had time to fix it, I'd try and use these files. In fact, what
> might be nice is a Perl class to insulate programmers from any changes
> to this file format. I don't know what Microchip's license policy is on
> these files, but there isn't so much as a copyright notice on them, and
> since they were so kind as to provide the MPASM testsuite way back when,
> they may be amenable to putting an agreeable license on these files as
> well.
> 

That is a good idea.  I will send them a quick message and find out.

> These files are at least used by the simulator UI, as I was able to create
> my own register in one of the existing .dev files.
> 
> --
> Charles Lepple ####@####.####
> http://www.ghz.cc/charles/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

I could help out although I probably can't get to it until the weekend
(I wrote the code originally).

I'll also try to look over the new files mentioned earlier to see if I
can make sense of them.  What would be the advantage of using them over
the *.inc files (have the *.inc files gone away)?


On Tue, 2003-05-06 at 12:41, Vangelis Rokas wrote:
> 
> ----- Original Message -----
> From: "Vangelis Rokas" ####@####.####
> To: ####@####.####
> Sent: Tuesday, May 06, 2003 4:19 PM
> Subject: spelling mistake
> 
> 
> 
> > PS. The same error is in p18f452.inc, p18f458.inc, p18f442.inc and
> > p18f448.inc files
> > but it is corrected in some other like p18f4320.inc !!
> >
> 
> Here is a complete list of the header file that have misspelled the OSCCON
> SFR:
> 
> p18c242.inc
> p18c252.inc
> p18c442.inc
> p18c452.inc
> p18c658.inc
> p18c858.inc
> p18f242.inc
> p18f248.inc
> p18f252.inc
> p18f258.inc
> p18f448.inc
> p18f452.inc
> p18f458.inc
> p18f6620.inc
> p18f6720.inc
> p18f8620.inc
> p18f8720.inc
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

----- Original Message -----
From: "Charles Lepple" ####@####.####
To: ####@####.####
Sent: Tuesday, May 06, 2003 6:29 PM
Subject: Re: spelling mistake


> MPLAB 6 has a nice feature in the "...\MPLAB IDE\Device" directory:
> machine-readable descriptions of each processor's registers and memory
> maps.

    Well, thats a good trick. Do you have anything ready, or can I begin
working on this type of script. I began writting some draft code based on a
flex  script. I would be a nice translator.

Vangelis Rokas

----- Original Message -----
From: "Craig Franklin" ####@####.####
To: "Charles Lepple" ####@####.####
Cc: ####@####.####
Sent: Wednesday, May 07, 2003 4:28 AM
Subject: Re: spelling mistake


> The header files come from MPLAB.  I don't want to maintain a seperate
> set of files.  Has any one told Microchip?  They might fix it.  I will
> ask.

    Well, I didn't notice that they where direct copies from MPLAB. One
might infom them but I do not think they will be very interested (since it
is a comment). They proposal by Charles is much better and cleaner, since
one is based on the device descriptions and not on comments.

They only drawback is that .dev files are not distributed with gputils
tarball so we must obtain them separate. However they might be a part of
SDCC package if licensing is ok.


> That is a good idea.  I will send them a quick message and find out.

    I'll be waiting for their response. Since they distribute MPLAB free,
probably they won't mind to let us use their .dev files.


Vangelis Rokas

On Wednesday, May 7, 2003, at 08:24  AM, Vangelis Rokas wrote:

> ----- Original Message -----
> From: "Charles Lepple" ####@####.####
> To: ####@####.####
> Sent: Tuesday, May 06, 2003 6:29 PM
> Subject: Re: spelling mistake
>
>
>> MPLAB 6 has a nice feature in the "...\MPLAB IDE\Device" directory:
>> machine-readable descriptions of each processor's registers and memory
>> maps.
>
>     Well, thats a good trick. Do you have anything ready, or can I 
> begin
> working on this type of script. I began writting some draft code based 
> on a
> flex  script. I would be a nice translator.

Nope, nothing written here.

I second the notion of using flex (and bison) for this sort of thing, 
although it may be a little hard to get the grammar correct in the 
absence of a formal spec.

-- 
Charles Lepple ####@####.####
http://www.ghz.cc/charles/

Vangelis Rokas wrote:
> 
> ----- Original Message -----
> From: "Craig Franklin" ####@####.####
> To: "Charles Lepple" ####@####.####
> Cc: ####@####.####
> Sent: Wednesday, May 07, 2003 4:28 AM
> Subject: Re: spelling mistake
> 
> > The header files come from MPLAB.  I don't want to maintain a seperate
> > set of files.  Has any one told Microchip?  They might fix it.  I will
> > ask.
> 
>     Well, I didn't notice that they where direct copies from MPLAB. One
> might infom them but I do not think they will be very interested (since it
> is a comment). They proposal by Charles is much better and cleaner, since
> one is based on the device descriptions and not on comments.
> 

I received a response.  They will fix it.  The dev files are a better
solution. 

> They only drawback is that .dev files are not distributed with gputils
> tarball so we must obtain them separate. However they might be a part of
> SDCC package if licensing is ok.
> 

Scott and I have been talking about how to distribute the SDCC header
files (or rather the script that generates them).  Could be in SDCC or
gputils-extra.  There are advantages to each one.  If the home ends up
being gputils-extra, the dev files should probably go there.  Not a big
problem for me.  I already have to update the .inc and .lkr from MPLAB. 
One more set of files isn't a big deal.

I starting to like this solution.  The dev files and the new script are
in gputils-extra.  When gputils-extra is installed, the dev files are
installed and the header files are created.  When the dev files change,
you install the new gputils-extra and get updated headers.  If other
languages want to use the dev files, they can add a new script to
gputils-extra to generate their own compiler specific files.  Some
device programing software might also use the data.

We should wait on a response about the licensing before making any
decisions.

> > That is a good idea.  I will send them a quick message and find out.
> 
>     I'll be waiting for their response. Since they distribute MPLAB free,
> probably they won't mind to let us use their .dev files.
> 

I haven't received a response on this one.

> Vangelis Rokas
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####