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?
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?
"doesn't mean you can predict their execution duration by looking at that piece of code alone"
But you can predict the execution of that piece of code alone. And you can then make due allowance for the other effects.
"the timing of each HLL 'statement' is documented"
No, it is not - because, as you yourself agreed, you have no idea what machine code will be generated from a HLL.
It has already been agreed that you can analyse the generated code after the event. The point is that you cannot predict the timing of the HLL.
Because you cannot predict the timing of the HLL, you cannot just present a piece of HLL source and say, "this produces a delay of x".
I guess it might be possible to tie it down with an exhaustive list of tool versions, options, etc - but, as stated in the original linked post, it'd be easier to just do it in assembler in the first place!
And, as stated in the original linked post, you could very well use a HLL as your starting point in creating that assembler.
Yes, I missed the "in a particular compilation" bit.
Doesn't alter the original argument about predicting before compilation, though.
View all questions in Keil forum