gnupic: Re: gpasm directives vs. MPASM


Previous by date: 3 Dec 2015 19:08:52 -0000 Re: gpasm directives vs. MPASM, Jerry Zdenek
Next by date: 3 Dec 2015 19:08:52 -0000 Re: gpasm directives vs. MPASM, Andrew E. Mileski
Previous in thread: 3 Dec 2015 19:08:52 -0000 Re: gpasm directives vs. MPASM, Jerry Zdenek
Next in thread: 3 Dec 2015 19:08:52 -0000 Re: gpasm directives vs. MPASM, Andrew E. Mileski

Subject: Re: gpasm directives vs. MPASM
From: Molnár ####@####.####
Date: 3 Dec 2015 19:08:52 -0000
Message-Id: <20151203200849.59baedebec67bf40599f7c6b@freemail.hu>

On Thu, 3 Dec 2015 11:03:52 -0600
Jerry Zdenek ####@####.#### wrote:

> Where does it say that it is a hardware limitation?
> 
> It's just convention to store a 16bit value as 4 4bit values.  You could 
> equally store it as 2 8bit values.
> 
> Jerry

You are right, because the number of the usable bits is differs and not clearly written that it is a hardware limit. I remembered badly.

Example 4-bit: In the http://ww1.microchip.com/downloads/en/DeviceDoc/41640A.pdf page 3, "2.3.1 USER ID LOCATIONS" section.
Example 4-bit: In the http://ww1.microchip.com/downloads/en/DeviceDoc/41227E.pdf page 2, "2.2 User ID Locations" section.
Example 7-bit: In the http://ww1.microchip.com/downloads/en/DeviceDoc/41244F.pdf page 6, "2.2 User ID Locations" section.
Example 7-bit: In the http://ww1.microchip.com/downloads/en/DeviceDoc/40001713A.pdf page 5, "3.1 User ID Location" section.
Example 7-bit: In the http://ww1.microchip.com/downloads/en/DeviceDoc/40001796A.pdf page 6, "3.1 User ID Location" section.

It seems 4 bits are available upon the 12-bit devices and 7 bits are available upon the 14-bit devices.

Károly

> 
> On 12/3/2015 2:25 AM, Molnár Károly wrote:
> > On Mon, 30 Nov 2015 15:22:26 -0500
> > "Andrew E. Mileski" ####@####.#### wrote:
> >
> >>
> >> First, thanks to all those involved for the marvelous gputils suite!
> >>
> >> I admit to being a PIC rookie, but it seems that gpasm is parsing the IDLOCS
> >> symbol as a directive, even when the --mpasm-compatible option is used, despite
> >> IDLOCS not being a MPASM directive (as far as I can tell).
> >>
> >> Is this a potential bug / "feature"?  Or is there a command-line option or
> >> something else that I'm overlooking which avoids this behaviour?
> >>
> >> I don't rule out that I could be doing something really stupid.
> >>
> >> IDLOCS appears to be a standard section name; grep the linker files.  An example
> >> of the following can be found in the current MPASM manual (DS33014L), page 28.
> >> I've just condensed the code, and set the processor type for this example.
> >>
> >>       LIST p=16f1829
> >>
> >> IDLOCS  CODE
> >>
> >>       dw      H'048C'
> >>       dw      H'159D'
> >>       dw      H'26AE'
> >>       dw      H'37BF'
> >>
> >>       END
> >>
> >> $  ./gpasm --mpasm-compatible -c bug.asm
> >> bug.asm:4:Warning[205] Found directive in column 1: "IDLOCS"
> >> bug.asm:4:Error[181]   Directive Error: The IDLOCS directive is invalid in MPASM
> >> mode.
> >>
> >> I would expect IDLOCS to be treated like any other section label when
> >> --mpasm-compatible is specified.
> >>
> >> I was considering patching the ^{IDENT}:? pattern in scan.l to return LABEL
> >> instead of IDENTIFIER for gpasm-specific directives in the ID_DIRECTIVES case
> >> when --mpasm-compatible is specified... unless there is a better route?
> >>
> >> ~~
> >> Andrew E. Mileski
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: ####@####.####
> >> For additional commands, e-mail: ####@####.####
> >>
> >>
> >
> >
> > The gpasm works a little differently. Citations from the gputils handbook:
> >
> >
> > CHAPTER 2. GPASM 18
> >
> >      __IDLOCS __IDLOCS <expression> or __IDLOCS <expression1>,<expression2>
> >
> > Sets the PIC processor’s identification locations. For 12 and 14 bit processors, the four id locations
> > are set to the hexadecimal value of expression. For 18cxx devices idlocation expression1 is set to
> > the hexadecimal value of expression2.
> >
> > .
> > .
> > .
> > .
> > .
> >
> > CHAPTER 2. GPASM 22
> >
> >      IDLOCS <expression> or IDLOCS <expression1>,<expression2>
> >
> > In “gpasm” mode (if the command line is not included the "--mpasm-compatible" option), in the case
> > of PIC18FXXX processors it is possible to use this directive.
> >
> > The expressions may be are as follows: string (“abcdef”), character (’a’), constant (0x37), symbol (NUM1)
> > These may be used simultaneously: IDLOCS “abcd”, 0x76, ’D’, NUM1
> > The length of IDLOCS can be at most 8 bytes.
> >
> > --------------------------------------------------------------------------
> >
> > So in your case so that should be used:
> >
> > 	LIST p=16f1829
> >
> > 	__IDLOCS  H'048C'
> >
> > 	END
> >
> > The compiler will do this:
> >
> > 0x8000: 0x0C
> > 0x8001: 0x08
> > 0x8002: 0x04
> > 0x8003: 0x00
> >
> > That is, a single 16-bit value stored in four 4-bit part. This is a hardware limitation.
> > Therefore the __IDLOCS directive can be used only once in the 12-bit and 14-bit devices.
> >
> > See: http://ww1.microchip.com/downloads/en/DeviceDoc/40001440E.pdf, page 51
> >
> > Molnár Károly
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ####@####.####
> > For additional commands, e-mail: ####@####.####
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 

Previous by date: 3 Dec 2015 19:08:52 -0000 Re: gpasm directives vs. MPASM, Jerry Zdenek
Next by date: 3 Dec 2015 19:08:52 -0000 Re: gpasm directives vs. MPASM, Andrew E. Mileski
Previous in thread: 3 Dec 2015 19:08:52 -0000 Re: gpasm directives vs. MPASM, Jerry Zdenek
Next in thread: 3 Dec 2015 19:08:52 -0000 Re: gpasm directives vs. MPASM, Andrew E. Mileski


Powered by ezmlm-browse 0.20.