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?
Not necessarily.
It means that, if you do write a delay in assembler, you must code your assembler carefully to use only those instructions for which you can predict the execution time, and only in ways that give predictable execution times.
The point is, you don't have that control in a HLL.
As you say, it might not even be possible in assembler. But at least you have visibility of that in assembler - you don't in a HLL.
"As you say, it might not even be possible in assembler. But at least you have visibility of that in assembler - you don't in a HLL."
I would agree with you if you define "visibility" for us.
"it might not even be possible in assembler."
it is only possible if you are talking about one-instruction delays.
for anything else, it is possible to predict the delay of a set of assembler instructions, whether they are hand-coded or machine generated from another high level language.
for obvious reasons.
"it is possible to predict"
should have been
"it is NOT possible to predict"
operator error.
for anything else, it is not possible to predict the delay of a set of assembler instructions
And you know that independent of architecture, settings of the CPU, and any other influences. And you're sure about that. As in you're claiming that one can specify the delay by, say, one
NOP
, but not, say,
NOP NOP
Reasons which, of course, it's beneath you to actually explain. We're supposed to take your unsubstantiated word for it. Sure.
The only thing obvious here is that once again you're mouthing off about things you don't understand.
<QUOTE>"it is NOT possible to predict"</QUOTE>
u sure? 8051?
always yo're freind.
Zeusti
"As in you're claiming that one can specify the delay by, say, one
, but not, say,"
only those creativity deficit would have interpreted the way you did.
"Reasons which, of course, it's beneath you to actually explain. "
it is beneath anyone to actually explain it TO YOU.
"We're supposed to take your unsubstantiated word for it. Sure."
no. but you are supposed to have understood it.
"The only thing obvious here is that once again you're mouthing off about things you don't understand."
the only thing obvious here is that you don't have the intellect to understand it.
he said this;
lots of black kettels in the vicinity of this forum. oh yeah.
of course i meant kettles.
I mean, when you write in assembler you can see what the instruction sequence is.
"when you write in assembler you can see what the instruction sequence is."
you have that with HLLs too: if not at the time of writing the (HLL) code but certainly after the compilation and having looked at the disassembly. I remember counting instructions and comparing various branches for TV signal generator code, :).
any (almost all?) "software" based delays run the risk of being non-predictable. the "non-predictability" is certainly bigger with HLL than it is with assembly - which I suspect is what you were trying to say.
fortunately, in most applications, we don't need (absolutely) precise delays, or we tolerate certain degree of timing un-predictability. Obviously, the bigger your tolerance for in-precision, the more likely a HLL delay solution will fit your bill.
so I think it is too extreme to base one's decision to use HLL or assembly delay routines on the ability to predict their duration.
"not at the time of writing the (HLL) code but certainly after the compilation"
But that was my point: you cannot predict it - you can only examine it after the fact.
With a HLL, you have no chance of predicting the delay;
In Assembler, you can see the actual instruction sequence, so you can know to what extent its execution time is predictable, and make your prediction within known limits.
"in most applications, we don't need (absolutely) precise delays"
True, but the duration of a HLL loop could vary by orders of magnitude depending on how, exactly, the compiler decides to implement it.
"the bigger your tolerance for in-precision"
I think the tolerance may be quite low for timing an LCD interface...
but you are supposed to have understood it.
Actually I understood your sweepingly generalized statement so well that it took me less than a minute to come up with a counter-example. Which worked so well you didn't even have the guts to quote it in your reply, turning it into one of those 100% pure ad-hominems we've become used to from you.
You appear to be under the impression that anything you say must be correct simply becuase you said so. You couldn't be any more wrong if you tried hard.
"it took me less than a minute to come up with a counter-example."
that's why no one gives a rat's real @#$ to being able to come up with a wrong answer quickly.
try harder next time.
"If you want a specific machine code sequence to look the same everytime..."
Which, of course, is fundamental to having a predictable time delay
"...you have to write it in assembly"
Yes, that is the point.
And, if it can't be done in assembly, then it can't be done at all.
Things like caches, pipelines, etc can certainly complicate the issue...
My Keil installation has 46 files named "LCD_4bit.c"
16 have a filesize of 12K; 10 have a filesize of 13K; 20 have a filesize of 14K.
At a quick check, it appears that the 12K files are all the same, the 13K files are all the same, and the 14K files are all the same.
Sampling one of each set shows that they do all contain 'C' for loop delays.
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.
(A check would also be necessary for assembler delays, but it wouldn't have to include checking the code generation).
At a quick check, the code does not disable interrupts during these delays.
<QUOTE>At a quick check, the code does not disable interrupts during these delays.</QUOTE>
most text LCD timing needs minimum delay not precise. disabling interrupts not usually needed.
"...disabling interrupts not usually needed"
Probably true.
However, the minimum delay that a HLL loop might produce is zero - if the loop gets optimised away.
BTW: You do realise that this forum does not support <QUOTE>...</QUOTE> tags - don't you?
<QUOTE>However, the minimum delay that a HLL loop might produce is zero - if the loop gets optimised away.</QUOTE>
yes i know
<QUOTE>BTW: You do realise that this forum does not support <QUOTE>...</QUOTE> tags - don't you?</QUOTE>
Always yo're freind.
Zeusti.
"yes i know"
But you said that it's the minimum delay that's important here!
<QUOTE>But you said that it's the minimum delay that's important here!</QUOTE>
i was answering about what you said about interrupts
do you know that if hll optimizes delay away then protecting the optimized delay from interrupts isnt going to do much? why highlight that?
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
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.
View all questions in Keil forum