Dose anybody know the purpose of doing this
void Send_CmdNo(unsigned char command){ CSX=0; RDX=1; D_CX=0; DBUS=command; WRX=0; WRX=0; WRX=0; WRX=1; CSX=1; }
why use WRX=0 3 times b4 WRX=1? wouldn't that just give you WRX=1?
by the way WRX is just
sbit WRX = P7^2;
does it mean on the I/O pin the output will send out 0 three times and 1 one time? It performs that fast?
No, see it as a short delay, to make sure that the pulse isn't too short.
By the way - why not use a more descriptive thread title than "HELP!"? I can't really see how HELP! is a summary of your post.
so a short delay uh... I see so you can use 4 or 5 or 6 or 7? and excuse me for the title cuz I really can't think of another title
"so you can use 4 or 5 or 6 or 7?"
Of course you can!
As already explained, this just provides a "short" delay - so the more times you repeat it, the longer will be the delay!
It's just a matter of determining how much delay you need, and then using the appropriate number.
A word of warning:
In general, an optimising compiler (such as Keil C51) will look at code like this
fred = 0; fred = 0; fred = 0; fred = 1;
and realise that all the zero assignments are pointless - so it will optimise it to
fred = 1;
To prevent this, you need to use the standard 'C' volatile keyword - look it up in any 'C' textbook.
(sfr is a Keil extension to the standard 'C' language - it is implicitly volatile).
ok... thanks... i got it all but this part
and I am using the Keil C51, so all that is just pointless now???
Note This message was edited to reduce width.
If you're using a variable declared as sfr, the volatile keyword may be omitted. If you're using something else (for example, I/O mapped into xdata space or similar), you'll need to tell the compiler by using the volatile keyword.
even simpler do not optimize and keep you code debuggable.
Erik
do not optimize and keep you code debuggable
Erik,
Just out of interest (and I know off topic), could you tell me(us) whether this is something you would do for production code.
I would normally use 'near-to-max' (i.e., common block subroutines) for both the debugging and production builds - And only switch down when I have a really nasty problem to catch or when I suspect that the optimizer itself is causing a problem.
The reason I do this is because I want to give the optimized code as much of a thrasing as possible before it gets released.
David.
"I am using the Keil C51, so all that is just pointless now???"
No, it is not pointless.
It is very important that you understand the issue here - otherwise you will get caught out!
You need to understand what the 'volatile' keyword does, and when and why it is needed - this is general to any 'C' compiler including Keil.
You need to understand why you can omit it in the special case of the Keil-specific 'sfr' keyword extension.
Optimised code is still debuggable - it's just more difficult.
The higher the optimisation level, the harder the debugging gets...
David,
There's a saying that goes "Premature optimization is the root of all evil." from some guy named Donald Knuth (whoever that is :). I generally follow Eric's sentiment on this one. I start with the optimizer OFF and only turn it on if I find I cannot meet performance requirements without it.
The real difficulty (and the one I'm sure Erik will mention) is that optimized code is generally more difficult to debug since the source no longer necessarily aligns with the actual assembly code to be executed.
That said, I don't have quite as great a hatred for the optimizer as Erik. I think one of his main gripes is that there are quite a few sensible optimizations that do not affect debugability that should rightfully be done by the compiler.
-Jay Daniel
View all questions in Keil forum