28 replies to this topic

[cce1911]

Hanzibal,

First let me say thank you for your assistance. I've been working with your code and I can't seem to get it to work. My breadboard is wired as shown in the attached image. I'm not sure if I have the pins assigned wrong or your code need to be tweaked for the N+2. Here is my code using your sample:

using System;using System.IO;using System.Net;using System.Net.Sockets;using System.Threading;using Microsoft.SPOT;using Microsoft.SPOT.Hardware;using SecretLabs.NETMF.Hardware;using SecretLabs.NETMF.Hardware.Netduino;using Hd44780Test;namespace FirstPlus    {    public class Program        {        public static void Main()            {            // create the LCD driver class (d4, d5, d6, d7, E, RS)            var lcd = new Hd44780(Pins.GPIO_PIN_D4, Pins.GPIO_PIN_D5, Pins.GPIO_PIN_D6, Pins.GPIO_PIN_D7, Pins.GPIO_PIN_D9, Pins.GPIO_PIN_D8);            lcd.Write("- Hd44780 Demo -");            bool onoff;            for (int i = 0; true; i++)                {                onoff = (i & 1) == 0;                lcd.ChangePosition(1, 0);                lcd.Write((i & 0xff).ToString("X2") + " LED is " + (onoff ? "ON " : "OFF"));                //led.Write(onoff);                Thread.Sleep(250);                }            }        }    }

Attached Files

•  wiring_diagram2.png   92.37KB   11 downloads

[hanzibal]

That is strange, the wiring looks ok to me and the corresponding gpio# in code checks out too. You shouldn't have to tweak anything more than the gpio# so I find it very strange. 1. The code does compile yes? 2. If so, exactly what do you see when you run the app? 3. If you see something (like garbeled text or so), could you perhaps take photo of it? EDIT: Would it be possible to isolate the board and LCD from everything else, i.e. temporarily disconnect all the other stuff or maybe you have an extra board, a regular N, NP or mini you could try the LCD alone with?

[cce1911]

Hanz,

Yes, I will stand up a new board with just the LCD on it and see if my wiring is the issue. It is a rather complex breadboard. I will also take a picture of the setup and what I'm seeing on the LCD. I won't be able to do this until this evening after work.

[cce1911]

Here is the picture. I'll set the other board up this weekend.

Attached Files

•  breadboard.jpg   154.08KB   7 downloads

[hanzibal]

I know that appearance only too well, I'm now quite positive it's a timing issue. Before employing an alternate board, you can try tweaking the code a bit. If you dive into the driver source, there's a method called _WriteNibble that basically does all data transfers to the LCD. As you will see, there are two lines of code driving the E pin. For starters you could try increasing the delay before lowering the pin to 2ms instead of just 1ms. The delay shouldn't be necessary since minimum data setup time is just 80ns but in comparison to which, even 1ms is an eternity but still worth a try. If that does not help, you can try other means but I'm on a train now and haven't got access to the code.

 

EDIT: When looking more closely to your setup, I noticed that your pull-downs on d0...d3 are wrong - I meant to pull down each of them separately. At this point, you can simply remove the pull-downs all together.

 pulldowns.jpg   18.27KB   5 downloads

[cce1911]

I'll remove the pull-downs on d0-d3, but do you think that is causing this problem?

[hanzibal]

Not really, it's just because they're not needed anymore and the fact that you have bridged them which might not be 100% healthy.

 

I feel very confident it's a timing issue. When thinking about it, the fact that you do see characters suggests that the LCD controller is actually correctly configured for 4 bit 16 x 2 mode and hence responds to commands. So why does data get garbled?

 

This in turn suggests the problem has to do with the RS pin rather than the E pin....Have a look at fig. 25 on page 58 and then page 52 in the d/s describing the timing characterstics:

https://www.sparkfun...LCD/HD44780.pdf

 

The driver works on my mini but then again, the NP2 is much faster which could affect timing. Anyway, before going down that lane, I think you should try the E pin code mod I suggest earlier. If that doesn't help, you could try moving the E pin assertion to just before the data pins are written to.

 

I believe you're almost there now!

[cce1911]

Hanzibal,

Tweaking the delay to 2ms did the trick. I also removed the pull-downs. Thanks for all your help.

[hanzibal]

That's great news!

Not to be a kill joy, but the necessity of such a long delay is likely only a symptom of the actual problem likely being something else. l should think it has to do with the RS pin and it should be further investigated. I might look into it when I find the time.

In my PCF8574 based driver, the delay is only 100us and that works perfectly well.

If you decide to make a PCB for your project, may I suggest you use the pcf8574 io expander. It's I2C and should save you some 4 pins of which you could use one for controlling brightness via PWM, periodically sampling a photo resistor to automatically adapt to variations in ambient light (daylight compensation). The code is available in this post:

http://forums.netdui...-and-ir-remote/