What is wrong with this LCD code?

Yes, it's that 40us per character interface that I'd like to see fixed. Too much time to wait around between characters, too little time to do much of anything else. Just in this thread we have seen the lengths that people have gone to to accommodate the display interface -- 500us interrupts and serial loop-backs with the baud rate setting the timing. These are clever solutions, but they are workarounds for a really clumsy interface.

Reply to
Mike Silva
Loading thread data ...

I'm not so sure about that, outputing 1 character on a timer interrupt from a shadow buffer would seem to be the sensible way even if it was much faster.

Reply to
cbarn24050

The problem then is that you have to deal with e.g. 40 interrupts to update a display. How much more sensible to go into a tight loop and dump those 40 characters all at once. But at 40us per character (up to

60us at temperature extremes), not every program can or wants to throw away 1600us updating the display (multiple times a second, if it's displaying real-time data). That could be many tens of thousands of CPU cycles, just to write 40 characters. Hence the tricks like timer interrupts and serial loop-backs. It's not the end of the world, but dang!
Reply to
Mike Silva

On the contrary, you dont have to deal with or wait for anything. Your main program writes to the buffer and forgets all about it, gets on with its own thing. The timer interrupt updates the display "in the background" so to speak.

Reply to
cbarn24050

I understand, but then you have to have a suitable interrupt. And you have to write more code that tells the interrupt routine when to start a new update, and more code that keeps track of the next character to output. As I keep saying, it's not the end of the world, but it's more hassle than it needs to be. It certainly is not an optimum solution.

Look at it this way. If you had your choice of a display that could accept a character every 400ns or a character every 40us, which would you choose?

Reply to
Mike Silva

True, but every processor has a timer (I think).

And you

It updates continuosly,

and more code that keeps track of the next character to

Ok you need a static pointer

As I keep saying, it's not the end of the world, but it's more

There isn't a better one I know of, especially if you want to edit your display.

Well if there was no price difference the faster one.

Reply to
cbarn24050

After the LCD is initialized, why not use the busy status?

Reply to
Everett M. Greene

Because that would take away its staus as bieng the worst possible way.

Reply to
cbarn24050

Mad,

I recently implemented a similar project. First thing I would say is get a data sheet on the device and look at your delays, you have what looks like a delay of 1uS when the device needs delays in the order of several mS! Anyway below is some of my init code for philips LPC which might help you. Good luck.

IODIR |= PIN_IO_LCD_DATA; // Set all data pins as outputs IODIR |= PIN_OUT_LCD_CTRL; // Set all control pins as outputs IOCLR = PIN_OUT_LCD_CTRL; // Bring all control lines low lcd_write (0x38); // Select 8-bit interface delay (100000); lcd_write (0x38); delay (10000); lcd_write (0x38);

lcd_write (0x38); // 2 lines, 5x8 character matrix lcd_wr_cmd (0x0e); // Display ctrl:Disp/Curs/Blnk=ON lcd_wr_cmd (0x06); // Entry mode: Move right, no shift LCD_load ((U8 *)&UserFont, sizeof (UserFont)); LCD_cls();

Mad I.D. wrote:

Reply to
Yan

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.