Parallel Alphanumeric LCD (MOP-AL202C)

HackWar · 2012-12-16 15:11

I am trying to get my Matrix Orbital LCD display to work with my Propeller. This display is HD44780 compliant and backlit. I found several spin objects which should make this whole process a walk in the park. Unfortunately, it's not that straightforward. The problem is that I cannot get the display to show anything at all. I've tried the "LCD Driver HD44780 16x2 4 bit 8 bit DEMO" object but no luck there. I switch on the power on the board and the display is activated (see photo). When I compile and upload the supplied demo program nothing really happens. I connected the pins as described in the comments. The datasheet of the display describe some kind of initialization steps which do not make any sense to me.

I have built several small projects with the BS2 BoE but the Propeller is something different. I'm really stuck here, I could really use some good advice

Hardware used:
MSR1 Robot control board
Matrix Orbital MOP-AL202C display (datasheet here)

whicker · 2012-12-16 16:35

That controller chip is ornery having had first-hand experience with it back around 1999 or so.
but once you get it up and running, it's a pretty neat display. (except for the buggy busy flag, but that's a gripe for another time)

Looking at the way the display is showing, it doesn't look like it has been successfully initialized, or it appears that the initialization data is incorrect.
Are you sure your wiring is correct? Are you sure your bus is connected in the correct direction? Are you sure your pins are correctly defined?
Are you actually calling the driver initialization routine at the start of your program? Can you see if your program is actually running by having it do something else (turn on an led or something).

There is also a contrast problem, have you simply tried adjusting the contrast or have a means of adjusting the contrast?
What I am saying is that if you tried to send it some text strings, some portion of it may be on the first line that is way too dark even if it was some bad initialization.
The display chip starts up in 1 line mode, and this looks like a 2 line display. contrast setting between one line and two line mode are different.

As for how to initialize it, it is simply a matter of just sending a certain bit pattern and then waiting for a certain amount of time, then sending another, waiting, sending another, etc.
In other words, it's not smart enough to power up and automatically start displaying on the LCD by itself, it must be told information about the actual LCD it is connected to.

Mark_T · 2012-12-16 16:48

I'd lose the long cable until the display is working (in case its causing glitches/crosstalk or whatever).

MagIO2 · 2012-12-16 23:29

As whicker already said, the display showing a bar on top usually means that it has not been initialized correctly.

I also tried some other LCD drivers and that's why I in the end wrote my own one. I remember one driver having initialization problems after a reset. So, the display only worked when doing a power on, but it failed to work after a reset. So far I had no problems with any of my displays and I only heard of one problem here in the forum which has been solved by increasing a value for the timing. (Have to search for the thread)

I'd simply give it a try, but be aware that this is definitely a 4 bit interface, no possibility to switch to 8 bit without changing the code:
http://obex.parallax.com/objects/576/

The interface to the PASM is a little bit low-level, but there is a SPIN wrapper somewhere in the forum which gives you the common functions.

8 bit interface in my eyes is simply a waste of precious propeller pins. You can still refresh the display faster than the liquid crystals can turn - not to speak about perception of the eyes.

HackWar · 2012-12-17 02:50

As far as I know the wiring is correct, I triple checked it

It indeed seems an initialization issue. Tonight I will try the suggested driver and see if that will help me, actually it is the only object I did not try yet. Thanks for the support so far!

JonnyMac · 2012-12-17 11:04

Do you have a pull-down on the E pin? If not, you really should as noise on this pin can create troubles on reset. I've been using character based LCDs (HD44780 variants) since 1993 and have never had a lick of trouble.

The attached object has been used commercially in a camera pan/tilt/trolley controller that a friend of mine makes. It handles the 4-bit LCD interface as well as six button inputs (four arrows which share LCD data buss, Enter, and Escape). You can ignore the button inputs if you choose (set the buttons mask to %000000). As I had not previously shared this I added comments that should help you get through it. Some of my timing values are fairly conservative; I tend to do this with commercial code -- better to be safe than have an issue when it's in the customer's hands.

HackWar · 2012-12-17 14:00

Thanks Jon, I will look into it shortly and share the results.

EDIT:

I've made a simple test by just calling the 'start' function like this:

LCD.start(8, %000000)

The start pin on my board is 8 and it is connected to pin 14 of the display (number 9 is connected to 13 etc...) Unfortunately no luck yet, but I really feel that I'm doing something wrong here, I just don't know where to look (still bit of a newb). Are the initialization steps different for each LCD which is HD44780 compatible? I'm understading to think that they are, this is what the datasheet of the display says:

... Before beginning any application, it is recommended that all display settings be initialized. Below are
algorithms for initializing the display in both 8-bit and 4-bit communication modes.
Before the first wait condition, please allow Vcc to rise to 2.7V then wait 40ms. During the three
function set commands that follow, note that the busy flag cannot be checked; it becomes available in
the last block. The unit will always expect a total of 8 bits to be sent, so note the structure used in four
bit mode. The last initialization block will set the number of lines and character font as specified, turn
the display off, issue the display clear command, and finally set the entry mode as desired...

This appears to be different from all the init steps I've seen so far in all objects.

HackWar · 2012-12-18 15:00

Today I tried to manipulate to driver code to match the init steps described as in the datasheet of the display, but still no luck. After reading the init steps from the datasheet over and over again and comparing them to the driver init steps, it all starts to make some sense. At the end of the init I power a LED to make sure it processes the code, and it does, but the display remains as it is (no init).

Some pointers anyone?

whicker · 2012-12-18 22:06

Do you realize that an 80 conductor hard drive ribbon cable (ATA/IDE) does not necessarily feed the signals from one side to the other in a one-to-one manner?
I am concerned that signals on certain pins are connected together and also grounded because the cable is treating these as grounds.

http://pinouts.ru/HD/AtaInternal_pinout.shtml

I'm not 100% sure how this works, but I think from this pinout diagram that the following pins are considered grounds and thus connected all together: 2, 19, 22, 24, 26, 30, and 40. Plus pin 20 is missing, and pin 34 is questionable depending on what kind of cable it is. Are you trying to use any of these pins to pass signals? Or are you already aware of the limitations of using this particular ribbon cable?

Some other things to check:

Are you powering the display module's pin #2 with 3.3V or with 5.0V?
what is the voltage level of the outputs you are using to send data and control signals to the display?

JonnyMac · 2012-12-18 22:30

I really feel that I'm doing something wrong here...

Probably...

Don't worry, we all go through this.

I feel pretty confident my code is well-vetted, so I would suggest you check your connections. Remember, you can use the .startx() method to define your pins; in this case the only requirement for contiguous pins are those on the LCD buss (and DB4 must be the LSB).

I agree with Whicker that you ribbon cable is the likely culprit. Whenever possible, simplify connections. I like to use these wires when experimenting:

-- http://www.pololu.com/catalog/category/67

I keep a stock of the M/M, M/F, and F/F in various colors -- makes chasing connections so much easier.

MagIO2 · 2012-12-19 00:41

Testing connections can be done in a few lines of propeller code. Just set one pin to output and high at a time and use a volt-meter or an LED (with resistor) on the other side to check where the high-level shows up. I'd really go through all pins just to make sure that there is no shortcut as well.

OBJ
  io: "FullDuplexSerial"

PUB main | i
  io.start ..... ' using your parameters

  repeat
    repeat i from 0 to 27
      io.rx

      dira := |<i
      outa := |<i
      
      io.str( string( "High-level on pin " ) )
      io.dec( i )
      io.tx( 13 )

HackWar · 2012-12-19 05:51

I will remove the IDE cable as I can now replace it with jumper wires which just came in

I was thinking what would be the easiest way for me to connect all those pins, because I cannot plug it into a breadboard directly (2 pin rows). That's why I improvised with the IDE cable. Now that I have enough jumper wires I can wire it directly to my board. The signal voltage is 5V and not 3.3V as for most propeller boards (MSR1 board), so that should be ok.

Peter Jakacki · 2012-12-19 06:19

Be aware that if you try to read the redundant busy signal from the LCD that this is at a 5V level into non 5V tolerant Propeller inputs. The easiest way around this is not to use the busy signal at all (I don't) and simply add a 1ms delay for the 01 Clear Display instruction. All other instructions execute within 11us which means you don't need a delay because Spin can't write to it that fast. The other advantage of this sensible mode of operation is that you can free up the R/W pin and simply tie it low on the LCD.

Also make sure your LCD contrast voltage on pin 3 is correct. Easiest way is to just ground this pin for testing as it will be good enough. I normally use an RC from the Prop and run a counter in DAC mode to vary the voltage in software.

HackWar · 2012-12-19 13:43

Finally it WORKS!!

) This time I took no chance and re-soldered the pins, replaced the IDE cable with the jumper wires and voila! Indeed the IDE cable was the culprit. Thank you all for helping me out, I appreciate it!

Here's the proof (please ignore the typo):

Parallel Alphanumeric LCD (MOP-AL202C)

Comments