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.
<QUOTE>But you said that it's the minimum delay that's important here!</QUOTE>
i was answering about what you said about interrupts
<QUOTE>At a quick check, the code does not disable interrupts during these delays.</QUOTE>
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.
Always yo're freind.
Zeusti.
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).
The point is, Zooeesti, that you mix up largely unrelated stuff.
I just made two observations about those source files:
1. That they do use HLL loops for delays;
2. That they do not seem to disable interrutps during those loops.
<QUOTE>Why would you need interrupt protection in the first place? Interrupts during the delay will surely extend the duration of the loop</QUOTE>
Tapeer,
you get it, late again and probebly taking all credit for the wisdom.
look for the word <BOLD>minimum</BOLD> in your fav reference book
But, again, you have no idea what code will be generated - the compiler might generate a very "tight" loop, or a rather slow one.
So you have no idea what this minimum delay will be.
Therefore, you have no idea if it will meet the requirements of the application (the requirement of the LCD, in this case).
Therefore, you have no idea if the code will work.
Given that the OP has code that does not work, this would certainly be one ofthe first things to check...
oh it looked like you were connecting them.
<SOB>and we call ourselves engineers</SOB>
"How so?"
Andy, that's very disappointing, to say the least.
"Yes, of course - for any timing loop you would have to disable interrupts."
so that particular sequence's execution is contingent on something outside of it. aka. the execution of that particular sequence itself is indeterminant.
btw, that's the same criticism you put on HLL delays.
not to mention other reasons that particular sequence may give indeterminant execution duration.
"(under "Addendum")"
so if the advocate of HLL delays had an addendum stating that you have to examine its disassembler output, you would have been OK with the use of HLL delays?
many of your criticism for HLL delays is valid. it is just that the same criticism can be leveled against pretty much any software solutions, including assembler code.
to use any solution successfully, you have to understand their limitations. and software delays (assembler or HLL) have plenty of limitations. As a programmer, you just need to understand what they are and use them when they are more / most efficient.
"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."
that (dropping in those files and assuming that they will work) isn't something you can do to any code, assembler or otherwise.
if your yardstick is to drop and pray, you should not use any software based delays.
"I just made two observations about those source files:"
congratulations on passing the 1st trimester of Programming 101.
As far as I understand, the only (?) thing that can undermine the execution duration prediction of these instructions is the pipeline and pipeline-related effects.
And of course - interrupts, as mentioned earlier.
"But, again, you have no idea what code will be generated - the compiler might generate a very "tight" loop, or a rather slow one."
the same is true for any HLL code. does that mean you should stop coding in C?
"So you have no idea what this minimum delay will be."
you do.
"Therefore, you have no idea if it will meet the requirements of the application (the requirement of the LCD, in this case)."
"Therefore, you have no idea if the code will work."
"Given that the OP has code that does not work, this would certainly be one ofthe first things to check..."
I am not sure on that one. if the code as he said worked on IAR and not on MDK, I would first check for compiler settings.
Something else that might affect the timing is reordering of instructions by the compiler to increase throughput.
I said: "you have no idea what [machine] code will be generated"
You said: "the same is true for any HLL code"
Yes! That is exactly the point!!
It is precisely because you have no idea what machine code will be generated from a HLL that, therefore, you cannot use a HLL to create specific timings!!
"Something else that might affect the timing"
tamir: good ones.
hopefully that's sufficient to convince andy that the execution duration of assembler delays is not possible to predict based on a) the code; and b) disable of the interrupt.
I could add a few more:
1) some chips can run on variable frequencies; 2) some 8051 chips can run on 1 cycle, 6 cycles or 12 cycles; 3) some chips can be user-configured on variable frequencies (those that use outside RC oscillators for example. but other possibilities exist too). ...
<QUOTE>the only (?) thing that can XXX</QUOTE>
<QUOTE>And of course YYY</QUOTE>
<QUOTE>Something else that ZZZ</QUOTE>
tapeer,
are you a fan of monty python? ever seen there won for the spanish inquisition?
please my freind, think thirst then right.
"It is precisely because you have no idea what machine code will be generated from a HLL that, therefore, you cannot use a HLL to create specific timings!!"
It is precisely because you have no idea what machine code will be generated from a HLL that, therefore, you cannot use a HLL to do specific things!!