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 want a fast and simple delay routine:
#pragma OT(8,SPEED) // Switch to speed optimization for this routine void my_delay(BYTE count) { register BYTE i; for (i=count; i; i--); }
Is the best so far and becomes:
B02:0xB1F1 EF MOV A,R7 B02:0xB1F2 6003 JZ B02:B1F7 B02:0xB1F4 1F DEC R7 B02:0xB1F5 80FA SJMP I2C_delay(B02:B1F1) B02:0xB1F7 22 RET
but I was hoping there was a way to get C51 to do just a DJNZ instead of 4 instructions for each loop.
Is there a magic coding style or optimization level that will generate the DJNZ?
this thread is missing one very important fact delay routines in C are fraught with error opportunities the next version of the compiler may do it differently (use DJNZ ?) the optimizer may change the code ....
erik
Changes to the delay caused by changed compiler version or changed optimization level isn't so much of a problem - code that relies on an instruction-counting busy loop should have some form of benchmark function so normal regression testing can validate the delay.
What is worse is that global optimization can change the delay after code changes in completely different parts of the code. Because of the problems with supporting high-level languages on the 8051 architecture, you can get parts of the optimization actually happening in the linker. It isn't until linking that variable overlaying can be performed - and first then will it be known the actual address distance between different symbols.
Making use of a timer means only a changed clock frequency will require code adaptations. So every new release build doesn't require the delay function to be explicitly checked.
code that relies on an instruction-counting busy loop should have some form of benchmark function so normal regression testing can validate the delay. and you think that will happen?
No, I don't. Most people who write busy-loop delays based on execution speed doesn't even realize there are issues with that concept. And neither do they know how to make code testable.
I just hope that hardware I buy have the code developed by someone who do care and have a reasonable amount of knowledge.
The big problem is that too much bad code exists on the net - and when people see bad code enough times they tend to assume that it is representative code that represents best practices. People tends to think that if they Google and find an answer, it has to be a good answer - why else would the information show up...