HD4470 display only working during debug

NETMF & Gadgeteer
#1

Hi,

I have an HD4470 connected to a Cerbuino Bee that is working fine during debugging. However, when the Cerbuino is then rebooted the display is all garbled with random characters.

I’ve used the onboard LEDs and debug output in MFDeploy to confirm that the application is working correctly, but the display is not. ???

Anyone got any ideas what it could be?

Many thanks

#2

try cicking the reset button on the cerbuino bee, theres only 2(one) button to choose from so you cant go wrong

#3

how about clearing the display during initialization?

#4

@ wolfbuddy - How is it connected to Bee and what code driver do you use?

#5

Thanks for the replies!

@ MRTFEREN this produces the same problem as a reboot.

@ Mike clearing the display is the first thing that I do when the program starts. Can I do it earlier than that?

@ Architect the display is connected to gadgeteer socket 3 and I’m using SDK 4.2. I should probably add that my application is NETMF, not gadgeteer. However, I have some applications where the display is working fine all the time and, in the current project that I am working on, I am not doing anything differently.

Also, I have tried re-flashing tinybooter and the firmware.

I just don’t understand what is different between sending the application to the Bee during debugging and rebooting/resetting the Bee! :wall:

#6

@ wolfbuddy - Speed is your enemy :open_mouth:

1 Like
#7

Interesting.

I am updating the display at 5hz once the application has moved on from the initial stages, but this is working OK. Is this causing the Bee or the display to crash when the Bee is rebooted/reset?

Or should I be clearing the display at the start of my application then waiting for a second or so before trying to display something?

#8

https://www.ghielectronics.com/community/forum/topic?id=7423&page=1

#9

Hmmm. Pretty sure I’ve seen that before and have the delays in my driver.

I will check later. Thanks! ;D

#10

OK, so I had a look at this and found that the example given actually made it worse! :think:

However, by changing the SendCmd method to have 1ms delays I was able to get it to work.

///<summary>
         /// Sends an LCD command.
         /// </summary>
         private void SendCmd(byte c)
         {
             LCD_RS.Write(false); //set LCD to data mode

             LCD_D7.Write((c & 0x80) != 0); Thread.Sleep(1);
             LCD_D6.Write((c & 0x40) != 0); Thread.Sleep(1);
             LCD_D5.Write((c & 0x20) != 0); Thread.Sleep(1);
             LCD_D4.Write((c & 0x10) != 0); Thread.Sleep(1);
             LCD_E.Write(true); Thread.Sleep(1); LCD_E.Write(false); //Toggle the Enable Pin
             Thread.Sleep(1);
             LCD_D7.Write((c & 0x08) != 0); Thread.Sleep(1);
             LCD_D6.Write((c & 0x04) != 0); Thread.Sleep(1);
             LCD_D5.Write((c & 0x02) != 0); Thread.Sleep(1);
             LCD_D4.Write((c & 0x01) != 0); Thread.Sleep(1);
             LCD_E.Write(true); Thread.Sleep(1); LCD_E.Write(false); //Toggle the Enable Pin

             Thread.Sleep(1);

             LCD_RS.Write(true); //set LCD to data mode
         }

I’m not particularly happy with this though as it adds another 10ms to the process of displaying something which could be bad for this particular application. In fact it is 20ms to use both lines of the display. Fortunately, no delay is needed for the Putc method.

Also, I still don’t get why this application needs this at as none of my other apps do.

So all of this leads me to ask if anyone knows of a display that is faster and doesn’t have issues like this?

Many thanks