gnupic: PIC14e: HIGH directive not setting bit-7
Subject:
Re: PIC14e: HIGH directive not setting bit-7
From:
Borut ####@####.####
Date:
1 Aug 2013 16:56:14 -0000
Message-Id: <51FA92F0.20103@gmail.com>
Fixed in svn revision #985.
The gputils snapshot build source package is available at
http://sourceforge.net/projects/gputils/files/snapshot_builds/src/gputils-src-20130801-985.tar.gz.
Windows 32bit setup package is at
http://sourceforge.net/projects/gputils/files/snapshot_builds/i686-mingw32msvc/gputils-20130801-985-setup.exe.
Borut
On 30. 07. 2013 08:17, Borut Ražem wrote:
> Hi Richard,
>
> this really seems to be a gputils bug: I tried your example with
> MPASMX and HIGH sets the 7th bit:
>
> 0000 00003 testme:
> 0000 3080 00004 movlw HIGH table
> 0001 0085 00005 movwf FSR0H
> 0002 3004 00006 movlw LOW table
> 0003 0084 00007 movwf FSR0L
> 00008
> 0004 345A 00009 table dt 0x5a
> 00010 end
>
> Please create a new ticket at https://sourceforge.net/p/gputils/bugs/.
>
> Borut
>
>
> On 30. 07. 2013 02:58, Richard Hodges wrote:
>> I am writing new code for the 16F1518, and I believe that gpasm is not handling HIGH
>> correctly for this chip. My datasheet (DS41452C) states on page 19:
>>
>> "3.1.1.2 Indirect Read with FSR
>> The program memory can be accessed as data by setting bit 7 of the FSRxH register and
>> reading the matching INDFx register. The MOVIW instruction will place the lower eight bits
>> of the addressed word in the W register. Writes to the program memory cannot be performed
>> via the INDF registers. Instructions that access the program memory via the FSR require
>> one extra instruction cycle to complete. Example 3-2 demonstrates accessing the program
>> memory via an FSR.
>> The HIGH directive will set bit<7> if a label points to a location in program memory."
>>
>> I _think_ that this access method is only for the "enhanced" 14 bit chips (like the
>> 12f1822 and 12f1501, for example.) But I could be wrong...
>>
>> This may be the line in question: (line 250 of gpasm/evaluate.c)
>> case HIGH:
>> return (evaluate(p->value.unop.p0) >> 8) & 0xff;
>>
>> I looked at disassembled relocatable code from gplink and I do not see the high bits set
>> there either.
>>
>> Here is code to show what happens:
>> LIST P=PIC16F1518
>> include p16f1518.inc
>> testme:
>> movlw HIGH table
>> movwf FSR0H
>> movlw LOW table
>> movwf FSR0L
>>
>> table dt 0x5a
>> end
>>
>> And here is the disassembly:
>>> gpdasm -p 16f1518 bad.hex
>> 000000: 3000 movlw 0
>> 000001: 0085 movwf 0x5
>> 000002: 3004 movlw 0x4
>> 000003: 0084 movwf 0x4
>> 000004: 345a retlw 0x5a
>>
>> I do not know whether the struct pnode has enough information to figure out when to set
>> the high bit (bit 7) of the result, but I can dig into it if it is not an easy fix for the
>> main developers.
>>
>> Thanks!
>> -Richard
