Helpful ReplyASM Variable Addressing Q?

Author
mpgmike
Senior Member
  • Total Posts : 109
  • Reward points : 0
  • Joined: 2014/01/23 17:27:06
  • Location: NJ
  • Status: offline
2019/04/16 19:22:04 (permalink)
0

ASM Variable Addressing Q?

Using MPLABX 5.15 & MPASM 5.83.
 
I created an array

TimTab. RES. 16

In the MASM Listing, it resides at starting address 0x0017.  However, in simulation it is at 0x0C37.  I want to use indirect addressing to access it, but neither address seems to get FSROL_H to affect TimTab.  What am I missing??!?
#1
dan1138
Super Member
  • Total Posts : 3039
  • Reward points : 0
  • Joined: 2007/02/21 23:04:16
  • Location: 0
  • Status: offline
Re: ASM Variable Addressing Q? 2019/04/16 19:52:21 (permalink)
+1 (1)
To answer your question requires a complete, builds without errors, assembly language file that identifies the target controller you are using and shows what you have tried that does not work.
#2
1and0
Access is Denied
  • Total Posts : 8842
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: ASM Variable Addressing Q? 2019/04/16 20:04:00 (permalink)
0
PIC device?  How did you load FSR0L and FSR0H?
#3
pcbbc
Super Member
  • Total Posts : 786
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: offline
Re: ASM Variable Addressing Q? 2019/04/16 21:17:29 (permalink)
0
mpgmikeWhat am I missing??!?
A full source listing.
#4
mpgmike
Senior Member
  • Total Posts : 109
  • Reward points : 0
  • Joined: 2014/01/23 17:27:06
  • Location: NJ
  • Status: offline
Re: ASM Variable Addressing Q? 2019/04/17 08:34:26 (permalink)
0
Attached are the .asm and MASM Listing files.  Since they're quite long, I'm attaching them (one at a time due to size limits).
#5
mpgmike
Senior Member
  • Total Posts : 109
  • Reward points : 0
  • Joined: 2014/01/23 17:27:06
  • Location: NJ
  • Status: offline
Re: ASM Variable Addressing Q? 2019/04/17 08:36:44 (permalink)
0
...and the .LST file.  (OK, it wasn't a size thing, I can't upload a .lst file, so I changed it to a .txt.)
 
#6
jack@kksound
code tags!
  • Total Posts : 3154
  • Reward points : 0
  • Joined: 2014/05/14 10:03:19
  • Location: 0
  • Status: offline
Re: ASM Variable Addressing Q? 2019/04/17 08:51:24 (permalink)
+1 (1)
Since you have a label defined for your table variable (TimTab) why are hard coding the addresses when you load the FSR0 registers? Use the label and let the assembler/linker put the correct addresses in. Hard coding addresses in relocatable code is defeating part of the purpose. Also you can put variables in the access bank by using the proper section directive (like UDATA), I will leave it to you to look in the user guide and find the correct one. Using EQU to do this also defeats the purpose of relocatable code.
#7
1and0
Access is Denied
  • Total Posts : 8842
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: ASM Variable Addressing Q? 2019/04/17 09:24:54 (permalink)
+1 (1)
mpgmike
In the MASM Listing, it resides at starting address 0x0017.  However, in simulation it is at 0x0C37.  I want to use indirect addressing to access it, but neither address seems to get FSROL_H to affect TimTab.  What am I missing??!?

So, without looking at your lst file, I assume the linker allocated the address 0x0017. But your code explicitly assigned the address 0x0C37 here:
; -=- First Save Sent Value to TimTab -=-
MOVLW 0x0C
MOVWF FSR0H
MOVLW 0x37
MOVWF FSR0L

and here:

ORG 0x0300
Send_PPs ;Send TimTab[x] to nx
BANKSEL nCnt
CLRF nCnt ;Load nCnt with 0d
MOVLW 0x37 ;TimTab[0]
MOVWF FSR0L
MOVLW 0x0C
MOVWF FSR0H ;Load FSR0 With TimTab[0]

This brings up a question -- how did you come up with the address 0x0C37?
 
As Jack said, you are using relocatable mode incorrectly. In relocatable mode, you cannot hardcode addresses that are assigned by the linker. Who know where the linker decided to allocate them. ;)
 
 
 
#8
1and0
Access is Denied
  • Total Posts : 8842
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: ASM Variable Addressing Q? 2019/04/17 09:28:52 (permalink)
+1 (1)
By the way, ORG is an absolute mode directive, not relocatable mode.
 
#9
mpgmike
Senior Member
  • Total Posts : 109
  • Reward points : 0
  • Joined: 2014/01/23 17:27:06
  • Location: NJ
  • Status: offline
Re: ASM Variable Addressing Q? 2019/04/17 10:54:58 (permalink)
0
It's amazing how something so obvious to one person is totally new information to another.  I have been programming in PBP3 Basic for about 8 years.  I really wanted to use the new PIC16F18426, but PBP3 needs another update to cover it.  I decided to see if I could do it in ASM; I use ASM for interrupt service routines and other small functions in PBP3.
 
That said, one of the biggest challenges in debugging code is knowing where to find answers.  We don't know what we don't know, and we don't even know that we don't know it!  (Unconscious Incompetence is another way of saying it.)
 
Thank you all for pointing me in the right direction.  Like anything else, I'll eventually conquer it.  I now have direction.
#10
dan1138
Super Member
  • Total Posts : 3039
  • Reward points : 0
  • Joined: 2007/02/21 23:04:16
  • Location: 0
  • Status: offline
Re: ASM Variable Addressing Q? 2019/04/17 13:22:15 (permalink) ☄ Helpfulby mpgmike 2019/04/17 18:02:17
+1 (1)
When using the Microchip PIC assembler in relocatable mode the the HIGH and LOW directives create relocatable entries in the object file.

This syntax will load the FSR register pair with the address of the TimTab data area in RAM:
    MOVLW   HIGH(TimTab)
    MOVWF   FSR0H
    MOVLW   LOW(TimTab)
    MOVWF   FSR0L



#11
dan1138
Super Member
  • Total Posts : 3039
  • Reward points : 0
  • Joined: 2007/02/21 23:04:16
  • Location: 0
  • Status: offline
Re: ASM Variable Addressing Q? 2019/04/17 13:43:33 (permalink)
0
1and0
This brings up a question -- how did you come up with the address 0x0C37?

For the PIC16F18426 the first RAM address in BANK0 starts at offset 0x20.
The offset of the TimTab in the UDATA section is 0x17, so the physical address is 0x0037.
It is unclear why the Original Poster believes this object is in BANK6.
 
<EDIT>
I understand now that the Microchip linker uses BANK 6 as the default when locating objects in RAM for a PIC16F18426.
 
The OP must be finding the physical address of TimTab by inspecting the MAP file output from the linker.
post edited by dan1138 - 2019/04/17 14:17:13
#12
mpgmike
Senior Member
  • Total Posts : 109
  • Reward points : 0
  • Joined: 2014/01/23 17:27:06
  • Location: NJ
  • Status: offline
Re: ASM Variable Addressing Q? 2019/04/17 18:04:51 (permalink)
0
dan1138, you listed:

MOVLW   HIGH(TimTab)
MOVWF   FSR0H

I was doing:
MOVF HIGH TimTab, W

I was getting the value of TimTab and not the address. Thank you.[/code]
#13
dan1138
Super Member
  • Total Posts : 3039
  • Reward points : 0
  • Joined: 2007/02/21 23:04:16
  • Location: 0
  • Status: offline
Re: ASM Variable Addressing Q? 2019/04/17 19:22:19 (permalink)
+1 (1)
mpgmike
dan1138, you listed:
MOVLW   HIGH(TimTab)
MOVWF   FSR0H

I was doing:
MOVF HIGH TimTab, W

I was getting the value of TimTab and not the address. Thank you.

You seem confused about what the assembly language op-codes do.
 
The MOVF op-code reads the value stored in a RAM location. The RAM in a PIC is call the FIle Register Store.
 
The MOVLW op-code loads a literal value in to the working register, called the WREG.
 
These op-codes do very different kinds of things.
 
You need to remember that the assembler only protects you from doing damn fool things not dumb things.
#14
Jump to:
© 2019 APG vNext Commercial Version 4.5