Need help using HD44780U LCD[SOLVED]

[MAD MACRO]

I'm trying to use my HD44780U LCD, found drivers on the internet, couldn't make them work, compiler issues, it was a brain fry, I made my own driver,.... well, I ported the old one that was intended for AVR.

anyway, if you've been able to use this LCD, plz post your project files, I'd really appreciate it if the code is small, it doesn't matter if it's not well written, all I care about is that it works. and also, it would be really helpful to not have the RW pin grounded, cuz I find reading the busy flag very helpful. 


I have this feeling that i'm using wrong delays in my code, i've been reading the LCD datasheet, http://fab.cba.mit.edu/classes/863.06/11.13/44780.pdf pages 24 and 46 are the most relevant to this topic.


My lcd.h and lcd.c files are in the attached files, you can have a look if you're interested though.

compiler: XC8
chip: pic18F2550
OS : linux

thanks in advance   

[RogerRowland]

I blogged about a small project that I made a couple of years ago that includes a 16x2 LCD panel, if you're interested.

It's all 8-bit PIC and there's a link to the source code at the end of the post.

http://rogerrowland.blogspot.com/2014/12/pic-and-mix.html

[obiwanjacobi]

Yes if you follow the sequence on page 46 and use the timings on page 58 you should be able to make it work.
Use a logic analyzer or scope to check if you generate the correct signals(with LCD disconnected)...

[2c]

[MAD MACRO]

I blogged about a small project that I made a couple of years ago that includes a 16x2 LCD panel, if you're interested.

It's all 8-bit PIC and there's a link to the source code at the end of the post.

http://rogerrowland.blogspot.com/2014/12/pic-and-mix.html

Nice project, I might look into using the M74HC595 shift register in the future, if pins get crowded.

[MAD MACRO]

Yes if you follow the sequence on page 46 and use the timings on page 58 you should be able to make it work.
Use a logic analyzer or scope to check if you generate the correct signals(with LCD disconnected)...

[2c]

Gonna keep reading and trying, i'm pretty sure it's a tiny silly rookie mistake...

a scope ?  well, I think you gonna understand when I say i'm a hobbyist, and those things cost a fortune out here.
I've managed to make myself a sound scope(the one that uses the soundcard), I'll give it a try.

[obiwanjacobi]

This:
http://www.ebay.com/itm/24MHz-8-Channel-USB-Logic-Analyzer-8-CH-Logic-Analyzer-for-Arduino-MCU-/191685084604?hash=item2ca15245bc:g:KFYAAOSwyQtV1vOO
(please refine the search - they might even be cheaper than this one)


and this:
https://www.saleae.com/downloads

And you have a 8 channel logic analyzer. Not expensive at all 
Get one, it's worth its weight in gold.

Good luck.

[newbrain]

Disclaimer: I don't do PICs (just ARM, a little AVR, old time 8 bitters).
So some parts of the code are just inscrutable to me (#pragmas etc.)  .

I have this feeling that i'm using wrong delays in my code

But yes, I think you missed something in you lcd_e_toggle() (mad) macro.

The macro as it is will simply toggle the E line (H->L or L->H):

Code: [Select]

#define lcd_e_toggle()  toggle (LCD_E_PORT, LCD_E_PIN)

Code: [Select]

#define toggle(LAT,PIN)         LAT         ^=  _BV(PIN)
But in your code you use it as it would cycle the E line:

Code: [Select]

    /* output high nibble first */
    [...large inefficient way to write a contiguous series of bits...]
    lcd_e_toggle();
   
    /* output low nibble */
    [...large inefficient way to write a contiguous series of bits...]
    lcd_e_toggle();

This also happens in the initialization routine, AFAICS, but not in the read read routine (where a different mistake is found).

The E line of a 447780 needs to go High, stay High for minimum of 500ns (at 5V, more at a lower supply) then go Low.
For writing you need to set E high, set the output data, wait a little (myabe not needed, I don't know your PIC's speed) then set it Low.

For reading, set E High, wait a little (see above), read the data, set E Low, instead what you are doing is: read data, E=H, wait, E=L; that will not work since 44780 internal state machine is tied to E transitions:

Code: [Select]

        data = LCD_PORT << 4;     /* read high nibble first */
        lcd_e_high();
        lcd_e_delay();
        lcd_e_low();

These are the first two things I found. I did not check much further (e.g. init sequence, display addressing) but these should get you going.

Another remark:
The code tries to take care of data bits spread on different ports and positions, but is not very consistent, e.g. in lcd_read() if the bits are on the same port they are assumed to be adjacent. I would write for a generic case and a case where same port and adjacent bits are used, and select at compile time.

Hope this helps.

[Gyro]

This:
http://www.ebay.com/itm/24MHz-8-Channel-USB-Logic-Analyzer-8-CH-Logic-Analyzer-for-Arduino-MCU-/191685084604?hash=item2ca15245bc:g:KFYAAOSwyQtV1vOO
(please refine the search - they might even be cheaper than this one)


and this:
https://www.saleae.com/downloads

And you have a 8 channel logic analyzer. Not expensive at all 
Get one, it's worth its weight in gold.

Good luck.

Or legally and just as functional, download Sigrok Pulseview (Free/Open Source)...

http://sigrok.org/wiki/Main_Page

(Download pulseview-NIGHTLY-installer.exe if you're on windows)

[MAD MACRO]

Disclaimer: I don't do PICs (just ARM, a little AVR, old time 8 bitters).
So some parts of the code are just inscrutable to me (#pragmas etc.)  .

I have this feeling that i'm using wrong delays in my code

But yes, I think you missed something in you lcd_e_toggle() (mad) macro.

The macro as it is will simply toggle the E line (H->L or L->H):

Code: [Select]

#define lcd_e_toggle()  toggle (LCD_E_PORT, LCD_E_PIN)

Code: [Select]

#define toggle(LAT,PIN)         LAT         ^=  _BV(PIN)
But in your code you use it as it would cycle the E line:

Code: [Select]

    /* output high nibble first */
    [...large inefficient way to write a contiguous series of bits...]
    lcd_e_toggle();
   
    /* output low nibble */
    [...large inefficient way to write a contiguous series of bits...]
    lcd_e_toggle();

This also happens in the initialization routine, AFAICS, but not in the read read routine (where a different mistake is found).

The E line of a 447780 needs to go High, stay High for minimum of 500ns (at 5V, more at a lower supply) then go Low.
For writing you need to set E high, set the output data, wait a little (myabe not needed, I don't know your PIC's speed) then set it Low.

For reading, set E High, wait a little (see above), read the data, set E Low, instead what you are doing is: read data, E=H, wait, E=L; that will not work since 44780 internal state machine is tied to E transitions:

Code: [Select]

        data = LCD_PORT << 4;     /* read high nibble first */
        lcd_e_high();
        lcd_e_delay();
        lcd_e_low();

These are the first two things I found. I did not check much further (e.g. init sequence, display addressing) but these should get you going.

Another remark:
The code tries to take care of data bits spread on different ports and positions, but is not very consistent, e.g. in lcd_read() if the bits are on the same port they are assumed to be adjacent. I would write for a generic case and a case where same port and adjacent bits are used, and select at compile time.

Hope this helps.

marvelous, this really helped, all I was missing was the toggle_e function, I should've done it using a function like this

Code: [Select]

static void toggle_e(void)
{
    lcd_e_high();
    lcd_e_delay();
    lcd_e_low();
}

and also you're right about the assumption of port pins being lined up next to each other, going to fix that.

newbrain, you're a goddamin' hero, thanks man   

It might seem like it's a "large inefficient way to write a contiguous series of bits" , it's supposed to be generic to serve me in any situation i'm in.


anyway, here is my victory dance

[MAD MACRO]

This:
http://www.ebay.com/itm/24MHz-8-Channel-USB-Logic-Analyzer-8-CH-Logic-Analyzer-for-Arduino-MCU-/191685084604?hash=item2ca15245bc:g:KFYAAOSwyQtV1vOO
(please refine the search - they might even be cheaper than this one)


and this:
https://www.saleae.com/downloads

And you have a 8 channel logic analyzer. Not expensive at all 
Get one, it's worth its weight in gold.

Good luck.

very interesting, i'm definitely buying it. Thanks for the advice.   

This:
http://www.ebay.com/itm/24MHz-8-Channel-USB-Logic-Analyzer-8-CH-Logic-Analyzer-for-Arduino-MCU-/191685084604?hash=item2ca15245bc:g:KFYAAOSwyQtV1vOO
(please refine the search - they might even be cheaper than this one)


and this:
https://www.saleae.com/downloads

And you have a 8 channel logic analyzer. Not expensive at all 
Get one, it's worth its weight in gold.

Good luck.

Or legally and just as functional, download Sigrok Pulseview (Free/Open Source)...

http://sigrok.org/wiki/Main_Page

(Download pulseview-NIGHTLY-installer.exe if you're on windows)

Thanks for the help 
judging by the screenshots, saleae seems alot better than Sigrok.   


also, I really like the smilies here     

[alank2]

very interesting, i'm definitely buying it. Thanks for the advice.   

Be aware that the cheapie ones like this on eBay have the WRONG buffer on them.  They are good for 3.3V or below only unless you change the buffer to:

http://www.digikey.com/product-detail/en/on-semiconductor/MC74LCX245DTR2G/MC74LCX245DTR2GOSCT-ND/919295

You should use the sigrok software unless you get a real Saleae (which is totally worth doing).

[danadak]

One of the issues I found using this controller is display "artifacts", basically
randomly flashing segments that detract from display appearance when
writing new data to display in a tight loop.

To get rid of this I created a buffer, 4 x 20 (size of my display) and whenever
code wanted to update display it first checked the buffer, char for char, and if
no match the display char for that position updated as well as the buffer char.
This way only changed data was written to the display. Effectively eliminated all
artifacts in display and created very stable appearance, except of course for the
changing chars.


Regards, Dana.

[alank2]

One of the issues I found using this controller is display "artifacts", basically
randomly flashing segments that detract from display appearance when
writing new data to display in a tight loop.

...except of course for the changing chars.

For the changing chars, another thing to do is tweak the contrast voltage with the goal of reducing the time it takes for a pixel to transition.  I usually have a blinking block and a number counting from 0-9 on a test screen to adjust it.

White on blue displays don't seem as clean on these transitions as other types (like green on yellow), but perhaps it is just more visible with them.

[newbrain]

marvelous, this really helped, all I was missing was the toggle_e function, I should've done it using a function like this

Code: [Select]

static void toggle_e(void)
{
    lcd_e_high();
    lcd_e_delay();
    lcd_e_low();
}

and also you're right about the assumption of port pins being lined up next to each other, going to fix that.

  Glad to to see it helped.
Remember that your toggle_e() is good for writing (no problem if the data is set before pulsing E), but not so good for reading (data is not valid before L to H transitions of E).

TBH, I always end up removing the "read busy flag" part and just make do with waiting enough time, but I mostly use these displays on a I2C port extender, slow enough to make it a moot point.

On the Saleae topic, I'm with Gyro and alank2: the license states clearly that the SW has to be used only with their HW, and I find that fair (I don't own a LA, Saleae or otherwise).

[Gyro]

 

Note that you can download and run the software without any LA hardware to try it out and understand the sort of facilities that are available. Without any hardware it will come up as a 'demo device' and provide dummy data to play with.

[macboy]

Free, open-source Sigrok supports those cheap Saleae clones, without legal or moral issues.