uVision2 debugger

In A51 the next definitions takes two cells of RAM, (0AH), for example, and (0BH):

data_variable: DS 1
typeless_number EQU 0BH

No it doesn't. This will only consume one byte of memory. EQUs don't reserve memory --- they're just fancy names for fixed numbers.

What the instruction

MOV A, typeless_number

typeless_number EQU 0BH

No it doesn't. This will only consume one byte of memory. EQUs don't reserve memory --- they're just fancy names for fixed numbers.

That is correct; however

What the instruction
MOV A, typeless_number
might put into the accu is random garbage. If it shows 0x0B for you, that's pure coincidence.
is not correct. The EQU tell the assembler to substitute, so
MOV A, typeless_number
becomes
MOV A, 0x0b

nothing random about that.

That using such means of defining memory slots is likely to cause all kinds of "housekeeping errors" is another story.

Erik

Erik,

it produces "random" (not good word here, I agree) results because there is difference between next two lines:

MOV,A#0x0b
MOV A,0x0b

LOCATION_0BH  DATA 0x0b

MOV A,LOCATION_OBH

guys,

The definition of all RAM (DATA) locations by EQU was a common practice years (ages?) ago. I haver NO recollection of the reason.

it was something like
;; data area
store1 EQU 30h
store2 equ store1+1

and so on.

Erik

The problem with what you remember is that while it sure is a way time-honoured to definite memory locations, it's not a way to define variables.

The difference is two-fold. First, there's type: an EQU is just a number, not an address. The second is ownership: memory locations belong to the hardware (e.g. some memory-mapped device), whereas variables belong to individual pieces of software.

To put it in a different context: if

foo EQU 0x23

#define FOO 0x23

The problem with what you remember is that while it sure is a way time-honoured to definite memory locations, it's not a way to define variables.
no, but where the variables are, which is just the same as
org 30h
store1 ds 1
store2 ds 1
which you state is "defining variables"
To put it in a different context: if
foo EQU 0x23
were a variable definition, then so would
#define FOO 0x23
in a C program.
C and assembler - apples and oranges

Erik

no, but where the variables are, which is just the same as

org 30h
store1 ds 1
store2 ds 1

; equ.asm:
        DSEG at 30h
store1 equ 30h
store2 equ store1+1
        CSEG
        ORG 0
        mov     a, store1
        mov     B, store2
        END

; ds.asm:
        DSEG at 30h
store1: ds 1
store2: ds 1
        CSEG
        ORG 0
        mov     a, store1
        mov     B, store2
        END

@@ -24,8 +24,8 @@ SYMBOL TABLE LISTING
 N A M E             T Y P E  V A L U E   ATTRIBUTES

 B. . . . . . . . .  D ADDR   00F0H   A
-STORE1 . . . . . .  D ADDR   0030H   A
-STORE2 . . . . . .  D ADDR   0031H   A
+STORE1 . . . . . .  N NUMB   0030H   A
+STORE2 . . . . . .  N NUMB   0031H   A


 REGISTER BANK(S) USED: 0

@@ -17,11 +17,9 @@ LINK MAP OF MODULE:  DS (DS)

             * * * * * * *   D A T A   M E M O R Y   * * * * * * *
             REG     0000H     0008H     ABSOLUTE     "REG BANK 0"
-                    0008H     0028H                  *** GAP ***
-            DATA    0030H     0002H     ABSOLUTE

             * * * * * * *   C O D E   M E M O R Y   * * * * * * *
             CODE    0000H     0005H     ABSOLUTE

-Program Size: data=10.0 xdata=0 code=5
+Program Size: data=8.0 xdata=0 code=5
 LINK/LOCATE RUN COMPLETE.  0 WARNING(S),  0 ERROR(S)

Note that according to the linker, the program using EQU has used no data at all except register bank #0. I hope you can agree that this is desaster waiting to happen.
Yes, there is a disaster waiting, but not the one you mention. The method virtually guarantee that someone at some time will put 2 variables in the same slot.

I have seen several programs using the EQU method that worked beautifully (and fixed some that did not).

Please understand, I totally agree that the EQU method is dangerous and should not be used, where we do not agree is that, it works. I would neither use nor recommend it, but in a way that invites you to make a bug and almost guarantees you will, it works.

NOW, if you mix this with C the house comes tumbling down, but that was not mentioned. Of course if you mix the EQU method with 'ds' statements it will get so many times easier to make a bug, but, again, it CAN be done.

I do not know how long you have been around, but some of the programs from the pre C days were "really fun", you added a variable and spent days to find out why that maded the whole thing fall apart.

Erik

friends,

come back to the original question:

data_variable: DS 1
typeless_number EQU 0BH

and can be treated with the same instruction:

MOV A,data_variable (F50A)
MOV A,typeless_number (F50B)

,but there is the value of "data_variable" displays properly in the "Watch" window,
"typeless_number" shows it's address instead
of the value.

How can I trace such a variable?


I think the question is not in difference between EQU/define/DATA et cetera, the matter is "how to obtain this value". And the answer is simple - follow the [simple] rules which Keil made for us. Debugger (and its Watch module) is not so smart to understand that if user types "EQU" then he orders: "look at the value which is stored in a memory which address in indicated by this fancy number". So open datasheet, read about numbers and addresses and have good sleep then.

Regards,
Oleg

-Thanks alot, for a patience for silly questions :)!
-I'm sorry for the incorrect formulation.
Of corse, the first case is a "pure" variable, the second, -is a constant to refer to as an address, for example.
But anyway, how it could be done, to see a random SFR using it's address?
When I've typed following: ( WS 1, 0x0B ), in watch window appears name: 0x0B with the value: (0x000C)

I think the question is not in difference between EQU/define/DATA et cetera

But it's exactly about the difference between EQU and DS!

And the difference between those is precisely that one generates a number, the other a variable. This difference both neatly explains the difference of behaviour if one tries to display things in the debugger (the EQU is not displayed as "its address", but actually as itself: a number), and provides an obviously correct solution to the problem: don't use EQU if what you wanted was to define a variable.

Now, even an EQU-ed "variable" can be viewed in the debugger, but you'll have to go through quite some painful typing to get there. You'd have use something like

*(data char *)equ_label

to see a random SFR using it's address?

Ah, but that's quite a completely different question! And the answer to this one is, I think, that you can't, because there is no such thing as a random SFR in the 8051 architecture to start with. SFR are direct addressing only, i.e. there's no such thing as a "pointer to an SFR" that you could dereference to access it. In a sense, 8051 SFRs don't have addresses.

If your program uses a given SFR, it has to be accessing by name, in the source. So you should access it by name in the debugger, too.

-Thank You so much!, but, still confused I've to ask, is it possible to display the "ram dump" in uVision3 debugger. What a mechanism can allow to trace changes in data memory caused by a program using addresation through "a constant as an address"

-Wow, I did find it! -It's just a matter of
overriding the "memory" window from default
"code" to the wanted.

"is it possible to display the 'ram dump' in uVision3 debugger."

Of course it is - That is precisely what the Memory windows does!

You can also set a Watch on a specific address.

uVision3 and uVision2 - makes no difference.

As has already been said to you, you need to go back to basics and do some serious study of the Manuals - at the moment, you are just thrashing around like a non-swimmer in deep water!

Specifically for this question, You need to read the uVision Getting Started Guide.

I suggest that you lay your project aside for now, read the uVision Getting Started Guide and work through the example projects in it.

This will give you a proper introduction to the tools, how they work, and how to use them - rather than just jumping-in blindly at the deep end.

Once you've done that, you will be better equipped to proceed with your project.

(The uVision Getting Started Guide is available on the 'Books' tab in the 'Project' Window; The 'Books' window is also available via the 'Help' menu; failing all that, search for GS51.PDF in your Keil folder)