[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
PIC14e: HIGH directive not setting bit-7
From: Richard Hodges ####@####.#### Date: 30 Jul 2013 01:00:04 -0000 Message-Id: <201307291858.56061.richard@hodges.org> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: PIC14e: HIGH directive not setting bit-7
From: Borut ####@####.#### Date: 30 Jul 2013 06:18:32 -0000 Message-Id: <51F75A78.2040502@gmail.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |