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.
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.
Always yo're freind.
Zeusti.
<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!!
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.
"But you can predict the execution of that piece of code alone."
I think (hope?) that we have established that. for confirmation, you could read that tamir had to say about it, for example.
"And you can then make due allowance for the other effects."
let me rephrase my HLL example then:
you can predict the executation of that piece of HLL code alone. and you can then make due allowance for the other effects.
does that mean by your own logic you should use HLL delays?
"No, it is not - because, as you yourself agreed, you have no idea what machine code will be generated from a HLL."
yes. But that doesn't mean that the code itself isn't documented - the disassembly is the place where such code is documented.
unless of course if you meant something different by your version of "document"?
"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."
you certainly can predict the timing of any HLL, as much as you would with assembly, before then making due allowance for the other effects.
"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"."
since it is on a false premise, ...
"And, as stated in the original linked post, you could very well use a HLL as your starting point in creating that assembler."
and you could very well use a HLL as your ending point as well. many applications do just that.
"you can predict the executation of that piece of HLL code alone"
No, you cannot: because you cannot predict - ie, know before compilation - what code will be generated.
"the disassembly is the place where such code is documented"
But, again, that is only available after compilation.
you can predict the executation of that piece of HLL code alone"
What I'm posting now has little to do with the choice of language (assembly, HLL), but I think that if, for example, a memory barrier is used calling any function, all assumptions about certain optimizations can fly out of the window. My conclusion? In order to make valid predictions, even in assembly, you need to be aware of many parameters (system load, memory barriers, scheduling issues if they apply, C compiler settings,...). In the end, just looking at HLL delay code might hide real faults, like loops being optimized out due to a forgotten "volatile" (certainly many here had that, when running out of ROM and needing to increase optimization level...). That's a little dangerous.
"No, you cannot: because you cannot predict - ie, know before compilation - what code will be generated."
maybe you are not talking about your definition of "predict": you probably mean predicting up to the exactly "click"?
in that case, you are right in that looking at a HLL delay loop doesn't allow you to predict its timing up to the exact click.
and you are wrong in that looking at an assembler delay loop doesn't allow you to predict its timing up to the exact click either - we have gone through that multiple times in this very thread.
"In order to make valid predictions, even in assembly, you need to be aware of many parameters (system load, memory barriers, scheduling issues if they apply, C compiler settings,...)."
agreed.
"In the end, just looking at HLL delay code might hide real faults, like loops being optimized out due to a forgotten "volatile" (certainly many here had that, when running out of ROM and needing to increase optimization level...). That's a little dangerous."
agreed too.
Looking at the HLL source does not allow you to make any prediction at all about its timing - because you cannot make any prediction about what code the compiler will generate.
"looking at a HLL delay loop doesn't allow you to predict its timing up to the exact click"
It does not not allow you to predict the timing at all.
"looking at an assembler delay loop doesn't allow you to predict its timing"
That is not necessarily true.
In summary:
In a HLL, you cannot predict the timing at all; In assembler, you might not be able to predict the timing.
Therefore, the original recommendation not to use a HLL stands.
The alternative should be qualified as, "if it can be done at all, it must be done in assembler"
"In a HLL, you cannot predict the timing at all;"
I am going to make the following prediction about the timing of any HLL delay, and I can guaranttee you that it is 100% accurate under any circumstance:
any delay, being it HLL or assembler, software or hardware, will generate a delay whose duration is between 0 and infinity
prove me wrong, please.
and totally worthless.
View all questions in Keil forum