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.
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.