gnupic: Re: gpasm directives vs. MPASM


Previous by date: 7 Dec 2015 08:10:44 -0000 Re: gpasm directives vs. MPASM, Molnár Károly
Next by date: 7 Dec 2015 08:10:44 -0000 Re: gpasm directives vs. MPASM, Andrew E. Mileski
Previous in thread: 7 Dec 2015 08:10:44 -0000 Re: gpasm directives vs. MPASM, Molnár Károly
Next in thread: 7 Dec 2015 08:10:44 -0000 Re: gpasm directives vs. MPASM, Andrew E. Mileski

Subject: Re: gpasm directives vs. MPASM
From: "Vinod Kanna R" ####@####.####
Date: 7 Dec 2015 08:10:44 -0000
Message-Id: <1449474737.S.4256.23453.f4-235-231.1449475839.31455@webmail.rediffmail.com>

UnsubscribeSent from RediffmailNG on Android

From: &quot;Moln&Atilde;&iexcl;r ####@####.####
Sent:Mon, 07 Dec 2015 13:22:17 +0530
To: ####@####.####
Subject: Re: gpasm directives vs. MPASM
On Thu, 03 Dec 2015 18:50:18 -0500
> "Andrew E. Mileski" ####@####.#### wrote:
> 
> &gt; On 2015-12-03 03:25, Molnár Károly wrote:
> &gt; &gt; On Mon, 30 Nov 2015 15:22:26 -0500
> &gt; &gt; "Andrew E. Mileski" ####@####.#### wrote:
> &gt; &gt;&gt;
> &gt; &gt;&gt; I would expect IDLOCS to be treated like any other section label when
> &gt; &gt;&gt; --mpasm-compatible is specified.
> &gt; &gt;
> &gt; &gt; The gpasm works a little differently.
> &gt; 
> &gt; That's my point though.  I'd expect it be source compatible with --mpasm-compatible
> &gt; 
> &gt; If that's not a goal, then I'll just quietly disappear.
> &gt; 
> &gt; &gt; So in your case so that should be used:
> &gt; &gt;
> &gt; &gt;    LIST p=16f1829
> &gt; &gt;
> &gt; &gt;    __IDLOCS  H'048C'
> &gt; &gt;
> &gt; &gt;    END
> &gt; &gt;
> &gt; &gt; The compiler will do this:
> &gt; &gt;
> &gt; &gt; 0x8000: 0x0C
> &gt; &gt; 0x8001: 0x08
> &gt; &gt; 0x8002: 0x04
> &gt; &gt; 0x8003: 0x00
> &gt; &gt;
> &gt; &gt; That is, a single 16-bit value stored in four 4-bit part. This is a hardware limitation.
> &gt; &gt; Therefore the __IDLOCS directive can be used only once in the 12-bit and 14-bit devices.
> &gt; &gt;
> &gt; &gt; See: http://ww1.microchip.com/downloads/en/DeviceDoc/40001440E.pdf, page 51
> &gt; 
> &gt; Erm... I can find no mention of a 4 bit limitation per location for this processor.
> &gt; 
> &gt; Excerpt from DS41390D
> &gt; http://ww1.microchip.com/downloads/en/DeviceDoc/41390D.pdf
> &gt; 
> &gt; "3.1 User ID Location
> &gt; 
> &gt; A user may store identification information (user ID) in four designated 
> &gt; locations. The user ID locations are mapped to 8000h-8003h.  Each location is 14 
> &gt; bits in length. Code protection has no effect on these memory locations. Each 
> &gt; location may be read with code protection enabled or disabled."
> &gt; 
> &gt; ~~ Andrew E. Mileski
> &gt; 
> 
> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 

Previous by date: 7 Dec 2015 08:10:44 -0000 Re: gpasm directives vs. MPASM, Molnár Károly
Next by date: 7 Dec 2015 08:10:44 -0000 Re: gpasm directives vs. MPASM, Andrew E. Mileski
Previous in thread: 7 Dec 2015 08:10:44 -0000 Re: gpasm directives vs. MPASM, Molnár Károly
Next in thread: 7 Dec 2015 08:10:44 -0000 Re: gpasm directives vs. MPASM, Andrew E. Mileski


Powered by ezmlm-browse 0.20.