Hello, I have a variable of type Nat16 (unsigned int) which is called PulseWidth. In the function that fills the variable PulseWidth, there's some assembler code (#pragma asm/endasm included in the .c file), so I have to indicate to the compiler to generate an assembler src file and to assemble this src file too. Because of that, I have to open the corresponding .src file to put breakpoints (apparently, I can't put breakpoints in the 'normal' .c file). When the breakpoint is hit, I would like to see the content of this variable in the watch window #1. However, I only see the value of one byte of this variable iso the whole variable. I have to open the memory window after looking where in the memory this variable is located, and only then I can see the two bytes (so, the 'complete' variable). My question: how to show the complete variable when you have hit a breakpoint in a .src file? Is there something like PulseWidth and PulseWidth+1 to be defined in the watch window? The example I gave just now certainly does not work, because if you put PulseWidth+1, the watch window simply adds 1 to the value of PulseWidth. Is there some other way to represent the second byte (or better, the whole variable at once)? Rgds, --Geert PS.: uVision version 2.33, C-compiler version 7.03.
The problem is that when you use the C compiler to generate an assembler SRC file, the obj file is generated by the assembler (not the C compiler). And, all the rules that apply to assembler files now apply to the object file. In assembler, there are no typed variables (like there are in C). In fact, there are no variables in assembler. There are only labels with either defined storage or with reserved storage (for 2 bytes in the case of an int). So, when you watch a "variable" in an object file that was created by the assembler, you are actually watching the label. And, the debugger has no idea how big that object is (since there is no type). The Keil debugger allows you to read a type from a starting address. This is done using the _R*** functions. For example, if your variable (err, label) is named xyz and it is an unsigned int, you can use the _rword function to display its value. For example: _rword(&xyz) returns the word value stored starting at the address of xyz. You may enter _rbyte in the command window or you may add it to the watch window. For example: ws 1, _rword(&xyz) Jon
Just another example of the side effects from not accepting assembler statements as part of C source without the Texas two step, sorry, German product, der Lancier. Erik
The problem is understandable when using separate command-line tools, but one might have hoped that an Integrated (sic) Development Environment would be able to overcome this limitation from its exalted, Integrated (sic) overview position...
The IDE is not part of the problem. It could be made part of the solution, but only at the considerable cost of blocking out all users who want to use other IDEs than the official one from Keil from reaping the benefits. The correct way of handling this problem is the way Unix compilers like GNU C have been doing it for ages: 1) The assembler must accept special statements that generate C-level debug information, as part of its input. 2) Using inline assembly with annotation describing all its side effects for the compiler, so inline assembly doesn't have to force optimizations off. 3) Drop direct .obj file generation by the C compiler. This creates additional load to support two different output mechanisms. I.e. it creates bugs.
1)I am totally in agreement. 2)I have used '51 compilers where this was not necessary 3) I do not understand Erik
3) E.g. pass the result of the compiler off to the assembler. The compiler only generates "marked up" assy. output.
"so inline assembly doesn't have to force optimizations off." it doesn't anyway: http://www.8052.com/forum/read.phtml?id=25467&top=
3) means that currently C51 has two at least somewhat independent output generators. One outputs object code directly (including debug info), the other generates assembly text (with lots of human-readable comments, but not machine-readable debug info). This creates maintenance problems for Keil --- every once in a while, a modification will be made that only works for one of the output generators. In the relatively short time I've been participating here, I've already seen this kind of bug mentioned a few times, so it's for real. The plan I outline would drop the direct code generation completely, and rely only on assembly language output. This would make the work for Keil simpler in the long run, and kill off this type of bugs for good. The alternative would be to find a method that allows inline assembly code without causing the whole module to go through the assembler. But I strongly doubt this can work in a sufficiently generic way. The catch is that the tools would now have to be able to *read* assembly language and understand their every consequence.
Hi Jon, The solution _rword(&PulseWidth) (to give an example) works fine for me. Thanks for the input! --Geert
Jon, Is there a (convoluted) way of making local (OVERLAYABLE) assembler variables show up with contents in the emulator/simulator ? Erik
Is there a (convoluted) way... When the variable is in context, just type its name in the comand window or open the locals watch window. The problem with local variables is they are only valid when they are in scope. So, if you add a watchpoint for a local variable, it gets invalidated when the function exits. The best suggestion I have is to use the locals watch window. Jon
When the variable is in context, just type its name in the comand window or open the locals watch window. The problem with local variables is they are only valid when they are in scope. So, if you add a watchpoint for a local variable, it gets invalidated when the function exits. The best suggestion I have is to use the locals watch window. This works as a champ with C local variable, I am talking about asm local variables Erik
Oops. Sorry. I skipped right over the assembler part of that. I'd probably use the _rbyte, _rword, and so on debugger functions. These seem to work well for just about anything. Jon
I am talking about asm local variables AFAICS, Keil Ax51 doesn't support local variables (unless you count private ones used in macro bodies as "local"), so there would be nothing to show.
Keil Ax51 doesn't support local variables Have a look at the OVERLAYABLE keyword, it provides the same effect as local variables in C Erik