Hello. I copied "LCD_4bit.c" and "LCD.h" files from Keil examples folder to my project folder and add it to my project. Then I changed Pins definition in "LCD_4bit.c" according to my project board LCD pins(LPC 2378). (I don't think that The problem is here.) Then I could successfully Build it, but when I download it to my project board,there is no signs that LCD works. However when I compile "LCD_4bit.c" in IAR environment ,the produced "hex file" works well on my project board. Thanks for your help.
"it might not even be possible in assembler."
it is only possible if you are talking about one-instruction delays.
for anything else, it is possible to predict the delay of a set of assembler instructions, whether they are hand-coded or machine generated from another high level language.
for obvious reasons.
"it is possible to predict"
should have been
"it is NOT possible to predict"
operator error.
for anything else, it is not possible to predict the delay of a set of assembler instructions
And you know that independent of architecture, settings of the CPU, and any other influences. And you're sure about that. As in you're claiming that one can specify the delay by, say, one
NOP
, but not, say,
NOP NOP
Reasons which, of course, it's beneath you to actually explain. We're supposed to take your unsubstantiated word for it. Sure.
The only thing obvious here is that once again you're mouthing off about things you don't understand.
<QUOTE>"it is NOT possible to predict"</QUOTE>
u sure? 8051?
always yo're freind.
Zeusti
"As in you're claiming that one can specify the delay by, say, one
, but not, say,"
only those creativity deficit would have interpreted the way you did.
"Reasons which, of course, it's beneath you to actually explain. "
it is beneath anyone to actually explain it TO YOU.
"We're supposed to take your unsubstantiated word for it. Sure."
no. but you are supposed to have understood it.
"The only thing obvious here is that once again you're mouthing off about things you don't understand."
the only thing obvious here is that you don't have the intellect to understand it.
he said this;
lots of black kettels in the vicinity of this forum. oh yeah.
of course i meant kettles.
I mean, when you write in assembler you can see what the instruction sequence is.
"when you write in assembler you can see what the instruction sequence is."
you have that with HLLs too: if not at the time of writing the (HLL) code but certainly after the compilation and having looked at the disassembly. I remember counting instructions and comparing various branches for TV signal generator code, :).
any (almost all?) "software" based delays run the risk of being non-predictable. the "non-predictability" is certainly bigger with HLL than it is with assembly - which I suspect is what you were trying to say.
fortunately, in most applications, we don't need (absolutely) precise delays, or we tolerate certain degree of timing un-predictability. Obviously, the bigger your tolerance for in-precision, the more likely a HLL delay solution will fit your bill.
so I think it is too extreme to base one's decision to use HLL or assembly delay routines on the ability to predict their duration.
"not at the time of writing the (HLL) code but certainly after the compilation"
But that was my point: you cannot predict it - you can only examine it after the fact.
With a HLL, you have no chance of predicting the delay;
In Assembler, you can see the actual instruction sequence, so you can know to what extent its execution time is predictable, and make your prediction within known limits.
"in most applications, we don't need (absolutely) precise delays"
True, but the duration of a HLL loop could vary by orders of magnitude depending on how, exactly, the compiler decides to implement it.
"the bigger your tolerance for in-precision"
I think the tolerance may be quite low for timing an LCD interface...
but you are supposed to have understood it.
Actually I understood your sweepingly generalized statement so well that it took me less than a minute to come up with a counter-example. Which worked so well you didn't even have the guts to quote it in your reply, turning it into one of those 100% pure ad-hominems we've become used to from you.
You appear to be under the impression that anything you say must be correct simply becuase you said so. You couldn't be any more wrong if you tried hard.
you have that with HLLs too:
No.
if not at the time of writing the (HLL) code but certainly after the compilation and having looked at the disassembly.
.. but that only holds until the next time you run the compiler and/or linker, with modifications somewhere else in the source code, or a different compiler version, or just different switch settings.
Looking at what the compiler did today doesn't, in general, tell you anything about what will happen tomorrow. If you want a specific machine code sequence to look the same everytime, you have to write it in assembly.
To summarize: writing delays in pure software (without reference to a hardware time of some sorts) is already a bad idea --- writing them in any other language above assembly, however, is lunacy.
"With a HLL, you have no chance of predicting the delay;"
you certainly have a chance of predicting a HLL delay. I do it all the time.
"In Assembler, you can see the actual instruction sequence, so you can know to what extent its execution time is predictable, and make your prediction within known limits."
only after you have examined the code in its totality.
for a "dumb-ass" example, the following code:
NOP; NOP;
has an undetermined and undeterminable duration without knowing what's happening outside of that sequence, even if each NOP has a finite and well defined execution duration.
so in both cases, you have to examine the generated code to figure out how long the execution will take place, and in some cases even looking at the assembly you wouldn't be able to tell its execution duration.
"True, but the duration of a HLL loop could vary by orders of magnitude depending on how, exactly, the compiler decides to implement it."
the same holds true for assembly too.
"I think the tolerance may be quite low for timing an LCD interface..."
it depends on the actual display. for example, many hd44780 controllers can tolerate initial delay as short as 0.5ms (specification is 15ms), and the longest I have tried is 10s.
"it took me less than a minute to come up with a counter-example."
that's why no one gives a rat's real @#$ to being able to come up with a wrong answer quickly.
try harder next time.
"has an undetermined and undeterminable duration"
How so?
<QUOTE>"How so?"</QUOTE>
the sequence can be in interrupted