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
View all questions in Keil forum