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 use KeilC uVision4 for 89C51 MCU. By "Inline ASM", i can easily direct write value to R7 register, like this :
#pragma ASM MOV R7, #10 #pragma ENDASM
But now, there are some reason that i have to write to R7 register direct from C (not from inline ASM), eg:
R7 = 10;
Of course, the C compiler does not understand R7 as MCU Register (not Inline ASM).
-> Is there anyway to solve this problem. Please help me if anyone know, thanks a lot !
Maybe you understand my idea incorrectly. I've used MikroC for 8051. That compiler has a built-in Delay_ms() routines. When I want to delay 10ms, just code
Delay_ms(10);
The compiler will auto generate source code (to delay 10ms) :
_Delay_10ms : MOV R5, #8 MOV R6, #1 MOV R7, #247 DJNZ R7, PC-2 DJNZ R6, PC-4 DJNZ R5, PC-6 RET
Then, I wonder if I can write a Macro like that in KeilC. Just code "Delay_ms(x);" with x is any number you want. Anything wrong in my idea ?
Yes - trying to mess about with macros in 'C'!
if at least 2 experienced people are telling you DON'T DO IT! and you refuse and insist on doing it your way, when it is clear even to a non-C51 guy like me that what you are doing is plain wrong, then you are no less than a ticking bomb. have you even considered that your "time gain" will be nullified by the hoops the processor will have to jump through in order to compensate for your macroed assembly...?
.. I will repeat
DO NOT MESS WITH REGISTERS IN INLINE ASM
you are hellbent on doing it this way and in a while you will come crying here "why does this not work" when you run into a conflict between your inline and the compilers register usage which legally can be any which way and be changed at any time.
Erik
Actually, that's about the one thing that's not at issue!
We're talking about software delays - so wasting processor cycles is the object of the exercise!
The problem is that the proposed macro approach is so horribly cumbersome and error-prone - especially when doing it as an assembler module is so clean, simple, and easy!
to compensate for his register usage in the middle of it
When it comes to programming, there is not always a clear right or wrong.
However, some methods have clear advantages and some clear disadvantages. I can see no advantage in what you're trying to do - And I think others here would concur. It is simply cumbersome and potentially error prone.
A piece of complicated looking code does not mean that author is a genius. On the contrary, quite often it is the simple elegant pieces of code that are written by the smarter people.
There's nothing much simpler than a software delay loop - Why try to complicate it?
"I can see no advantage in what you're trying to do"
Absolutely: no advantage whatsoever; but plenty of clear disadvantages!!
"often it is the simple elegant pieces of code that are written by the smarter people."
Indeed - hence the "Engineer" comment earlier!
;-)
I merely trying to convince the OP (without much success, I guess...!) of the cascade negative impact his design will have - include impairing other piece of software that are supposed to have "well-known behavior".
.. to tell a young truly modern person not to write unmaintainable code.
today, the typical shop has 5 testers for each programmer, so who gives an iota if code is good, if it fails, the teaters will catch it.
Always worth leaving the accidental on purpose error in to test whether the teaters are awake ;)