• State Not Answered
  • Locked Locked
  • Replies 72 replies
  • Subscribers 21 subscribers
  • Views 11712 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Interfacing LCD to LPC2378

hasan darab

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.

Parents
  • 0 in reply to Andy Neil

    "With a HLL, you have no chance of predicting the delay;"

    you certainly have a chance of predicting a HLL delay. I do it all the time.

    "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."

    only after you have examined the code in its totality.

    for a "dumb-ass" example, the following code:

    NOP; NOP;

    has an undetermined and undeterminable duration without knowing what's happening outside of that sequence, even if each NOP has a finite and well defined execution duration.

    so in both cases, you have to examine the generated code to figure out how long the execution will take place, and in some cases even looking at the assembly you wouldn't be able to tell its execution duration.

    "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 same holds true for assembly too.

    "I think the tolerance may be quite low for timing an LCD interface..."

    it depends on the actual display. for example, many hd44780 controllers can tolerate initial delay as short as 0.5ms (specification is 15ms), and the longest I have tried is 10s.

Reply
  • 0 in reply to Andy Neil

    "With a HLL, you have no chance of predicting the delay;"

    you certainly have a chance of predicting a HLL delay. I do it all the time.

    "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."

    only after you have examined the code in its totality.

    for a "dumb-ass" example, the following code:

    NOP; NOP;

    has an undetermined and undeterminable duration without knowing what's happening outside of that sequence, even if each NOP has a finite and well defined execution duration.

    so in both cases, you have to examine the generated code to figure out how long the execution will take place, and in some cases even looking at the assembly you wouldn't be able to tell its execution duration.

    "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 same holds true for assembly too.

    "I think the tolerance may be quite low for timing an LCD interface..."

    it depends on the actual display. for example, many hd44780 controllers can tolerate initial delay as short as 0.5ms (specification is 15ms), and the longest I have tried is 10s.

Children