Searching \ for '[PIC] movff ignores banksel, correct?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/memory.htm?key=bank
Search entire site for: 'movff ignores banksel, correct?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] movff ignores banksel, correct?'
2007\10\16@070559 by Peter Todd

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The 18f instruction movff ignores banking right?

I'm trying to figure out why these two code fragments act completely
differently on sdcc

Using this macro:

#define i2c_write(c) \
 PIR1bits.SSPIF = 0; \
 SSPBUF = (c); \
 while (!PIR1bits.SSPIF); // cleared at 9th (ACK) clock


i2c_write(i);

!=

i2c_write(0x40 + i);


Looking at the outputted asm code the former produces:

00346 ;       .line   71; mcp23017.c  i2c_write(i);
0030 9600      00347         BCF     _PIR1bits, 3
0032 C000 F000 00348         MOVFF   r0x00, _SSPBUF
0036           00349 _00108_DS_:
0036 A600      00350         BTFSS   _PIR1bits, 3
0038 EF00 F000 00351         GOTO    _00108_DS_

and the latter:

00346 ;       .line   71; mcp23017.c  i2c_write(0x40 + ((i)));
0030 9600      00347         BCF     _PIR1bits, 3
0032 0E40      00348         MOVLW   0x40
0034 2400      00349         ADDWF   r0x00, W
0036 6E00      00350         MOVWF   _SSPBUF
0038           00351 _00108_DS_:
0038 A600      00352         BTFSS   _PIR1bits, 3
003A EF00 F000 00353         GOTO    _00108_DS_


Basically identical. However the latter outputs 0x00 on the i2c bus
regardless of what value i is. The former works fine, although I rather
need that 0x40 bit. I'm guessing that sdcc is missing a banksel
instruction. It's the only thing I can think of that would make the two
versions act so differently.

Does this make any sense to you guys?

- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHFJnK3bMhDbI9xWQRAkPDAJ4vv+RH7NabJ4niqOXLQkcphzN8LgCgloZD
xsVkJ9hCEZdi2Nz34GUNFtw=
=LXul
-----END PGP SIGNATURE-----

2007\10\16@075831 by Michael Rigby-Jones

picon face


{Quote hidden}

I think your conclusion is correct.

MOVFF takes a 12 bit address, so it can operate on any address in the data memory with no banking.  The second bit of code loads 0x40 into W and tries to add it to your 'i' value by using ADDWF.  Unfortunately ADDWF takes only an 8 bit address, and since the access bank is not being used here, if the BSR register is not correctly set at this point the result will be invalid.

It may be worth trying this with the optimiser disabled to see if the bank selction is being removed by the optimiser or never inserted in the first place.


Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2007\10\16@085026 by Jan-Erik Soderholm

face picon face


Michael Rigby-Jones wrote:
{Quote hidden}

> the data memory with no banking.  The second bit of code loads
> x40 into W and tries to add it to your 'i' value by using ADDWF.
> Unfortunately ADDWF takes only an 8 bit address,...

> and since the access bank is not being used here,...

I think it is.
To use the BSR, the machine inst for ADDWF "2400" would have been
"2500". The difference is the "a" bit. a = "0" => access bank.
And the "MOVWF   _SSPBUF" also uses the access bank, so it weird...

Maybe the asm listing isn't the final PIC code ?
Notice that the target adress of both MOVWF and MOVFF is h'000',
SSPBUF is at h'FC9' (in one of the PIC18 I looked at).

I'd try to write a few lines in asm in MPALB and run it
through MPSIM and see what happens.

Jan-Erik.


2007\10\16@091910 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: @spam@piclist-bouncesKILLspamspammit.edu [KILLspampiclist-bouncesKILLspamspammit.edu]
>On Behalf Of Jan-Erik Soderholm
>Sent: 16 October 2007 13:50
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] movff ignores banksel, correct?
>
>
>
>
> > and since the access bank is not being used here,...
>
>I think it is.
>To use the BSR, the machine inst for ADDWF "2400" would have
>been "2500". The difference is the "a" bit. a = "0" => access bank.
>And the "MOVWF   _SSPBUF" also uses the access bank, so it weird...

Oops, you are absolutely correct, I was thinking the access bit worked the other way around.  On closer inspection the address of all registers is zero, so I guess this assembly listing is probably directly from the compiler, before the link stage so no addresses have been resolved.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2007\10\16@093952 by Jan-Erik Soderholm

face picon face


Michael Rigby-Jones wrote:
{Quote hidden}

Right, and the question is id the linker does anything with the
"a" bit also... :-)

Jan-Erik.

2007\10\16@155019 by Peter Todd

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Oct 16, 2007 at 02:50:24PM +0200, Jan-Erik Soderholm wrote:
{Quote hidden}

Ahh, good point, here's the same two fragments, after link:

;        .line        71; mcp23017.c        i2c_write(0x40 + i);
0001c6   969e     bcf        0x9e, 0x3, 0                BCF        _PIR1bits, 3
0001c8   0e40     movlw        0x40                      MOVLW        0x40
0001ca   2400     addwf        0, 0, 0                    ADDWF        r0x00, W
0001cc   6ec9     movwf        0xc9, 0                    MOVWF        _SSPBUF
                                          _00108_DS_:
0001ce   a69e     btfss        0x9e, 0x3, 0              BTFSS        _PIR1bits, 3
0001d0   efe7     goto        0x1ce                      GOTO        _00108_DS_
0001d2   f000


;        .line        71; mcp23017.c        i2c_write(i);
0001c6   969e     bcf        0x9e, 0x3, 0                BCF        _PIR1bits, 3
0001c8   c000     movff        0, 0xfc9                  MOVFF        r0x00, _SSPBUF
0001ca   ffc9
                                          _00108_DS_:
0001cc   a69e     btfss        0x9e, 0x3, 0              BTFSS        _PIR1bits, 3
0001ce   efe6     goto        0x1cc                      GOTO        _00108_DS_
0001d0   f000

FWIW these fragments are from a function, with i being one of the
arguments.

For the life of me, I can't see why these would work so differently. I
didn't know about the access bank before, but now that I do I see that
the two are completely equivilent, both cases correctly use the access
bank directly.

> I'd try to write a few lines in asm in MPALB and run it
> through MPSIM and see what happens.

Yeah, but then I gotta track down a copy of windows. :)

- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHFRP63bMhDbI9xWQRAmHhAKCBPNvCOIwhWspWljhfsW7Cztf60gCglHc6
ateW3uSF2uXCJE81Munu04g=
=7dKX
-----END PGP SIGNATURE-----

2007\10\16@170935 by Jan-Erik Soderholm

face picon face
Peter Todd wrote:
{Quote hidden}

Yes they do, but they don't do the same thing, do they ?

If h'00' is stored at RAM address h'000', one of them
will send h'00' and the other will send h'40'. Isn't that
quite a difference ? I must have lost the original
question in the first post... :-)

Jan-Erik.

2007\10\16@172302 by Peter Todd

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Oct 16, 2007 at 11:09:31PM +0200, Jan-Erik Soderholm wrote:
{Quote hidden}

Er... Right, I stayed up too long last night debugging. :)

> If h'00' is stored at RAM address h'000', one of them
> will send h'00' and the other will send h'40'. Isn't that
> quite a difference ? I must have lost the original
> question in the first post... :-)

The contents of RAM address 0x00 are > 0, yet the output of the former
on the i2c bus, with the addwf, is always 0, but the latter outputs the
contents just fine.

- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHFStv3bMhDbI9xWQRAv1KAKCGw0rKpug7lUzOg8w1W+Ftm99K1wCffgPL
wVLoS5JKCz57IKfrDsDIGCI=
=SHJu
-----END PGP SIGNATURE-----

2007\10\16@174308 by Jan-Erik Soderholm

face picon face
Peter Todd wrote:
{Quote hidden}

Right, that was the issue, got it now.

Well, did I mention MPLAB and MPSIM and singlestepping
those instructions to actualy "see" what's happening ? :-)

It would take me 10 minutes, but it's 20 min to midnight, so
maybe tomorrow, if there isn't any message about the issue
beeing solved before that... :-)

Jan-Erik.

>
> - --
> http://petertodd.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHFStv3bMhDbI9xWQRAv1KAKCGw0rKpug7lUzOg8w1W+Ftm99K1wCffgPL
> wVLoS5JKCz57IKfrDsDIGCI=
> =SHJu
> -----END PGP SIGNATURE-----

2007\10\17@015330 by Peter Todd

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Oct 16, 2007 at 11:43:07PM +0200, Jan-Erik Soderholm wrote:
{Quote hidden}

Sure enough... Fixed it.

Turns out the 2520 chip I'm using has some new fangled "extended
instruction set" that I didn't disable. It changes the behavior of the
FSR registers somehow, haven't tracked down exactly how, in such a way
that SDCC fails to correctly pass function arguments. The code snippits
I showed were in fact completely correct, it was only dumb luck that the
error looked the way it did due to some random chance of exactly how the
corrupted arguments worked out.

Weird that I've already done two projects using the 2520. Likely you
need to have a minimum number of arguments to a function before the bug
is triggered.

Disabled the extended instruction set via the appropriate config
register and now all is good.


...well, almost, I've got a hard deadline to have a working demo 14
hours from now, and I woke up 15 hours ago. Hopefully I really can write
boring led pwm code in my sleep. :)

- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHFaId3bMhDbI9xWQRAkE5AJ91Yz7cRQ/+V40vcs1+ZBvQ/buikwCgnPLy
acJalt2H5wDPUKmvhAd4SgE=
=i4Tz
-----END PGP SIGNATURE-----

2007\10\17@023923 by Jan-Erik Soderholm

face picon face
Peter Todd wrote:
> Sure enough... Fixed it.
>
> Turns out the 2520 chip I'm using has some new fangled "extended
> instruction set" that I didn't disable.

Ah, should have thought of that !
Many (most ?) C-compilers enables that (and that is
what it's ment for, not for ASM programming).

Now, if the compiler (or programmer) enables ext-instructions,
but the compiler doesn't know how to handle the difference,
then you do have a problem... :;-)

Jan-Erik.

2007\10\17@044921 by Hector Martin

flavicon
face
Jan-Erik Soderholm wrote:
> Ah, should have thought of that !
> Many (most ?) C-compilers enables that (and that is
> what it's ment for, not for ASM programming).
>
> Now, if the compiler (or programmer) enables ext-instructions,
> but the compiler doesn't know how to handle the difference,
> then you do have a problem... :;-)

SDCC has an option for it (-y/--extended), but I've never used it
(mostly because I've only done a few projects with it so far, and I
haven't had the chance to try it out yet). However, if you enable the
fuse but disable the compiler functionality, or vice versa, you're going
to get some really fun behavior (as far as I know, SDCC does not do
anything with fuses - it's your responsibility to set the fuses to the
proper values, including the right extended mode depending on your
compilation options).

Bonus points if you compile some files in extended mode and others in
normal mode, and then link them together. I don't know if the linker
will somehow barf or if it will let it go through. If it does I'll bet
it would make for some interesting bugs. Unless of course you
dynamically reprogram your fuses from your program when you need to, to
make it work :) (as long as you don't do it thousands of times per
second! Flash endurance... ouch.)

--
Hector Martin (TakeThisOuThectorEraseMEspamspam_OUTmarcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...