uVision2 debugger

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

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

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