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.
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.
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!
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.
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?
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.
After the LCD is initialized, why not use the busy status?
Because that would take away its staus as bieng the worst possible way.
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:
Have something to add? Share your thoughts — no account required.
Ask the community — no account required