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.
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
always yo're freind.
Zeusti
Yes, of course - for any timing loop you would have to disable interrupts.
That was already covered in the linked thread: www.8052.com/.../149030
(under "Addendum")
"If you want a specific machine code sequence to look the same everytime..."
Which, of course, is fundamental to having a predictable time delay
"...you have to write it in assembly"
Yes, that is the point.
And, if it can't be done in assembly, then it can't be done at all.
Things like caches, pipelines, etc can certainly complicate the issue...
My Keil installation has 46 files named "LCD_4bit.c"
16 have a filesize of 12K; 10 have a filesize of 13K; 20 have a filesize of 14K.
At a quick check, it appears that the 12K files are all the same, the 13K files are all the same, and the 14K files are all the same.
Sampling one of each set shows that they do all contain 'C' for loop delays.
Therefore you cannot just drop these files into any arbitrary project and assume that they will work - you must check that the delays work appropriately with your particular project.
(A check would also be necessary for assembler delays, but it wouldn't have to include checking the code generation).
At a quick check, the code does not disable interrupts during these delays.
<QUOTE>At a quick check, the code does not disable interrupts during these delays.</QUOTE>
most text LCD timing needs minimum delay not precise. disabling interrupts not usually needed.
"...disabling interrupts not usually needed"
Probably true.
However, the minimum delay that a HLL loop might produce is zero - if the loop gets optimised away.
BTW: You do realise that this forum does not support <QUOTE>...</QUOTE> tags - don't you?
<QUOTE>However, the minimum delay that a HLL loop might produce is zero - if the loop gets optimised away.</QUOTE>
yes i know
<QUOTE>BTW: You do realise that this forum does not support <QUOTE>...</QUOTE> tags - don't you?</QUOTE>
Always yo're freind.
Zeusti.
"yes i know"
But you said that it's the minimum delay that's important here!
<QUOTE>But you said that it's the minimum delay that's important here!</QUOTE>
i was answering about what you said about interrupts
do you know that if hll optimizes delay away then protecting the optimized delay from interrupts isnt going to do much? why highlight that?
obviously if hll delay is not optimized away you have minimum delay and you do not need interrupt protection.
Why would you need interrupt protection in the first place? Interrupts during the delay will surely extend the duration of the loop IF it does not use a hardware timer as reference (and maybe even if it does).