gnupic: Re: gpasm directives vs. MPASM


Previous by date: 7 Dec 2015 07:51:55 -0000 Re: gpasm directives vs. MPASM, Andrew E. Mileski
Next by date: 7 Dec 2015 07:51:55 -0000 Re: gpasm directives vs. MPASM, Vinod Kanna R
Previous in thread: 7 Dec 2015 07:51:55 -0000 Re: gpasm directives vs. MPASM, Andrew E. Mileski
Next in thread: 7 Dec 2015 07:51:55 -0000 Re: gpasm directives vs. MPASM, Vinod Kanna R

Subject: Re: gpasm directives vs. MPASM
From: Molnár ####@####.####
Date: 7 Dec 2015 07:51:55 -0000
Message-Id: <20151207085152.e377f75867f53fa63c67d750@freemail.hu>

On Thu, 03 Dec 2015 18:50:18 -0500
"Andrew E. Mileski" ####@####.#### wrote:

> On 2015-12-03 03:25, Molnár Károly wrote:
> > On Mon, 30 Nov 2015 15:22:26 -0500
> > "Andrew E. Mileski" ####@####.#### wrote:
> >>
> >> I would expect IDLOCS to be treated like any other section label when
> >> --mpasm-compatible is specified.
> >
> > The gpasm works a little differently.
> 
> That's my point though.  I'd expect it be source compatible with --mpasm-compatible
> 
> If that's not a goal, then I'll just quietly disappear.
> 
> > 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
> 
> Erm... I can find no mention of a 4 bit limitation per location for this processor.
> 
> Excerpt from DS41390D
> http://ww1.microchip.com/downloads/en/DeviceDoc/41390D.pdf
> 
> "3.1 User ID Location
> 
> A user may store identification information (user ID) in four designated 
> locations. The user ID locations are mapped to 8000h-8003h.  Each location is 14 
> bits in length. Code protection has no effect on these memory locations. Each 
> location may be read with code protection enabled or disabled."
> 
> ~~ Andrew E. Mileski
> 

These the new versions, please give it a try:
http://sourceforge.net/projects/gputils/files/snapshot_builds/src/gputils-src-20151206-1161.tar.gz/download
http://sourceforge.net/projects/gputils/files/snapshot_builds/i686-mingw32msvc/gputils-20151206-1161-setup.exe/download

Károly

Previous by date: 7 Dec 2015 07:51:55 -0000 Re: gpasm directives vs. MPASM, Andrew E. Mileski
Next by date: 7 Dec 2015 07:51:55 -0000 Re: gpasm directives vs. MPASM, Vinod Kanna R
Previous in thread: 7 Dec 2015 07:51:55 -0000 Re: gpasm directives vs. MPASM, Andrew E. Mileski
Next in thread: 7 Dec 2015 07:51:55 -0000 Re: gpasm directives vs. MPASM, Vinod Kanna R


Powered by ezmlm-browse 0.20.