We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I have a memory mapped A/D converter (with a conversion time << one machine cycle, therefore no need to check for End of Conversion). The following code was written to explain the problem: -
xdata unsigned char A_D _at_ 0xE000; //this is the address of the A/D converter unsigned char x,y; main() { A_D = 0; //start conversion by doing a "dummy write" x = A_D; // read the value from the A/D }
CLR A MOV DPTR,#A_D(E000) MOVX @DPTR,A MOV x(0x80),A
Looks like you need to declare A_D as volatile - mike
...or use the XBYTE macro.
Thanks for the solutions. However, the question remains - why should I need to do anything at all? Does this qualify as a compiler bug?
I wouldn't class it as a bug - you want the compiler to optimise the use of variables - in your instance you need to give it some clues to tell it your memory address is NOT memory so it can do what you require. In the case where it is memory - I would curse the compiler if it loaded the dptr, write the value, then load the dptr again and read the same location. The optimiser's job is to identify such things and streamline the code. In this instance we have a 'design feature'!
"However, the question remains - why should I need to do anything at all?" If you look up 'volatile' in a decent 'C' book you'll realise that the optimisation you're seeing is exactly what 'C' compilers are expected to do. In embedded stuff you'll find yourself using volatile quite a bit to suppress this when dealing with memory mapped peripherals and interrupt service routines.