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?
obviously if hll delay is not optimized away you have minimum delay and you do not need interrupt protection.
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
Always yo're freind.
Zeusti.
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!!
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.
View all questions in Keil forum