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.
So, clearly, there must be something non-portable about this software, and/or some critical differences about the way you have your projects configured.
A prime suspect would be Timing - in particular, any HLL delay loops:
www.8052.com/.../162556
You need to start debugging to find where, exactly, the problems are:
www.8052.com/.../120313
" you can never predict the duration of any piece of high-level language (HLL) source code[1]. "
I will expand it for you:
1) you cannot predict the duration of many (assembler) instructions; 2) you can never predict the duration of any series of (assembler) instructions.
does that mean you should stop using assembler to code delays?
"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.
Zeusti.
"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!!
I did only say one of the first things to check.
In fact, I think the first check that I, personally, would do would be with a 'scope on the interface pins to see if anything was happening at all.
If that showed that something was happening, then I'd look a bit closer at whether it was the right things - including the right timing.
HLL source code specifies what is to be done - not how it is to be done.
In particular, timing is a "how" thing.
In 'C' parlance, the "what" is referred to as Side Effects
"HLL source code specifies what is to be done - not how it is to be done."
HLL source code = "what is to be done" in a user-specified sequence <> how it is to be done?
the HLL user may not specify to the utmost detail how each step is to be done (nor do most assembly applications), but a C source code certainly specify how a task is to be done.
Whatever.
But, as you very well know, timing is totally outside the scope of the 'C' source.
"But, as you very well know, timing is totally outside the scope of the 'C' source."
depending on how you define "scope" and one can argue, not without merit, that timing is totally outside the scope of the 'assembly' source too.
not that it strengthens one's argument (for or against).
depending on how you define "scope"
Err, that would be the C standard...?
No, it isn't.
The timing of each instruction is documented - you yourself spoke of "cycle counting" earlier!
"The timing of each instruction is documented - you yourself spoke of "cycle counting" earlier!"
yes, but that doesn't mean you can predict their execution duration by looking at that piece of code alone - for reasons we have articulated earlier.
for example, in a particular compilation, the timing of each HLL "statement" is documented - you only need to look at the disassembly to confirm that.
"Err, that would be the C standard...?"
if you define "scope" to be within a language standard, then "scope" is undefined for assembly language as there is no such standard.
so what does it mean by saying that timing in assembly is within the scope of something that doesn't exist?
View all questions in Keil forum