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.
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.
"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.
Something else that might affect the timing is reordering of instructions by the compiler to increase throughput.
"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.
Zeusti.