Hi all, I try to use the simulator with a code that contains struct or union, but it doesn't seem to see members. Here is an example code: struct chuf { unsigned char hi; unsigned char lo; }; union { struct chuf chi; unsigned int both; } buf; void main(void) { buf.chi.hi =5; buf.chi.lo =1; buf.both =0x1122; while (buf.both) buf.both>>=1; } When I try to see something like buf.both, it shows error 10. By the way, where can one see the list of simulator errors? When I look for just buf, it shows the first byte of this union. At the same time, within the memory it seems to work right. Can anything be done about it? Thanks, Michael.
You don't call it a bug, I do. You explain me the difference between .obj and .src files. But it is your interior problem and your virtual reality - it wasn't I who chose your implementation. What I see as a user is that writing code using both C and assembler in the same file is a common practice and your simulator doesn't provide a mean to see what is going on in the controller - that is why I call it a bug. Michael.
I found a bug in my Ford Explorer. It doesn't accelerate from 0 to 60 MPH in 4 seconds. :-) Jon
You explain me the difference between .obj and .src files. Actually, I explained why you can't see C structures when you compile the C file and generate assembly source. I guess I wasn't very clear on that point. Maybe this makes more sense. Rule 1. The Keil A51 Assembler does not have a struct data type. Therefore, structures in assembly must be implemented as an array of bytes. When you use the debugger to view these assembly structures, only the first byte will be displayed. This applies EVEN IF you start with a C file and compile it using the SRC directive. The output from the C compiler is an assembler source file (.SRC) which you must then assemble using the A51 Assembler. And, Rule 1 applies. The assembler works this way by design. Jon
"You don't call it a bug, I do." No, it's not a bug; it's a direct consequence of the way Keil have chosen to implement their support for inline assembler, as Jon has explained. You may consider this to be a bad implementation, but that's a different issue! BTW: Keil are not alone in choosing this implementation. BTW2: You see a similar effect if you #include executable code in a 'C' source file: the 'C' compiler only sees the resulting pre-processed file, so it can't generate line number debug information for the #included file! This is certainly not limited to just Keil.