Problem: garbage on LCD

Go To Last Post
47 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!
I made an AVR powered console that has a keypad, LCD, buzzer, RS232, etc.
Works fine, but sometimes I get garbage on the LCD. :-(
If I restart the device, LCD comes back to normal feelings...
All text is checked before sending to LCD (max. size and content to be printable).
Question: What should I check in HW/SW? What can I do to solve this problem?
Note that it happens very rarely, that's why it's so annoying!
BTW: Nothing spectacular in my code, I just use Pavel's LCD lib functions.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This can usualy be placed at the door of hardware/ noise or too fast at clocking
Software solutions to try are to delay between writing to the data line and the E to give more settling time.
AS a check read back the data after writting to the display if garbaged send all lines to display low; power down for 0.2 sec power back up and reinitialize. This requires a transistor on the Vcc line.
Hardware
Caps on power lines, small cap say 47pf on enable line, low value resistors on all lines at the lcd end.

Yes I am getting grumpy!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you Mr. bitbasher!
Indeed, quite useful info!

Stanley.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

small cap say 47pf on enable line,

That has also worked well for us. A ratty E line causes all kinds of problems. If practical, put the cap on the LCD end.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just my 2 cents...

We use 4x40 HD44780 compliant character based lcd's in my teaching lab...

We often do controls experiments where the real time control is done inside Timer ISRs - we have had issues with functions printing to the LCD that get interrupted to do the RT code and come back having exceeded some timing contstraints on the LCD interface yeilding a bunch of garbage on our LCDs.

Our fix is to either disable interrupts while updating the display or dramatically slow down the display update and periodically call an lcd_init function to put the module back in a known state.

ELO

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

erickoberstar wrote:
Just my 2 cents...

We use 4x40 HD44780 compliant character based lcd's in my teaching lab...

Our fix is to either disable interrupts while updating the display or dramatically slow down the display update and periodically call an lcd_init function to put the module back in a known state.

ELO

I have tried to avoid similar problems. One thing to do is to keep the interrupts SHORT, and set flags whenever possible to signal to the main program to do some processing.

Turning off interrupts is fine unless updating the display takes too long for some interrupt-dependent activities. These LCD displays are earth-shatteringly slow compared to the uC. 40uS per character or so. If I did my math right this is 25,000 characters per second == 250,000baud. 40 uS is about 320 clocks at 8mHz.

You will waste LOTS of time waiting for the display be ready to accept another character.

So, one alternative is to update the display on an occasional basis (5Hz? 10Hz?). Use a timer to trigger an interrupt every 50+uS, and setup and send the next LCD character, then reset the timer and return to the main task.

To do this, you will need to have a sending buffer for the LCD characters.

What I do is to have a virtual LCD CGRAM (32 bytes for my 16x2 displays. I then put the characters into this virtual display as if it were an LCD. Then every 1/5 or 1/10th second (based on a timer) I copy the virtual display to a 32 byte buffer, and send the characters in a timed manner. It works well, but uses an extra 64 bytes of ram. It is not a great technique for a small uC.

Does this seem reasonable to you?

-Tony

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tony, Good technique for non real time control applications such as the one it sounds like groehen has.

Note that if your using another timer interrupt to do display updates you need to aware of issues relating to nesting interrupts. By default with CVAVR the global interrupt enable bit is not reset until an ISR exits thus eliminating nested interrupts. If your using another timer for real time control related tasks this interrupt wont run until the display update ISR completes thus introducing a delay before your real time control interrupt runs - bad from a control theory perspective.

You can manually enable global interrupts inside your display update ISR to allow the control ISR to run but then your back to the same problem of your display update code getting interrupted again. - Hopefully if the display update is only @ 5-10 Hz the problem should be minimized...

ELO

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I never worry about updating a display in "real time", even if the app is "real time". E.g., take a simple voltmeter display, or a high-speed counter, or a tach. Yes, with the AVR it >>could<< be updated in near real time. But the digits would be changing so fast the eye couldn't grasp the number anyway. My typical is 1/2 second, give-or-take a factor of 2.

Thus, I also use the buffer method and periodically put out a chunk of the display. The display buffer method is also very useful when the app has a remote display involved, especially if it is an additional "aux" display--the buffer contents can be shipped off over the commo link.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your right Lee.
The human eye has a hard time noticing even 60Hz flicker so updating a display in real time doesn't make sense.

This real issue is the display update ISR impacting the real time performance of the control ISR by either delaying it slightly (slightly increasing your sample period) or by missing sample instances entirely.

If it takes 40us / character a 4x40 display should take around 6.4ms. If you are sampling at even 300Hz with another timer ISR for control you could miss 2 samples which could send your control algorithm into unstable land depending on how tuned up your control algorithm gains are.

ELO

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, I never update a character LCD in an ISR. Sometimes when multiplexing LED or LCD segment displays that have frequent (as low as 1ms/column) update requirements I'll do that in the timer ISR, but these are much faster and more deterministic--a few us compared to a few ms.

Most of my industrial apps have "fast" and/or "slow" control loops. The "fast" might be like 10ms and the "slow" like 500ms, give or take. I normally update the display in the pass after the "slow" loop closure--a fresh set of info has just been created.

But each app is different.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I'm back to my computer (awful day today)
...
Usually, the LCD content gets updated at about 3 seconds interval (both lines of the 2x16 LCD). Text comes via RS232 from another device.
Can't open the metal-case, so I'm trying to find the schematics to see if there are capacitors/resistors on LCD lines... Anyway, I'm not good at HW, so let's stick around the SW:
Basically, I use something like this in my code [CodeVisionAVR]:

void refreshLCD(void)
{
  lcd_clear();
  lcd_puts(LcdBuf1);
  lcd_gotoxy(0, 1);
  lcd_puts(LcdBuf2);
}

Globals LcdBuf1 and LcdBuf2 are buffers to keep the text for line1 and line2 sent via RS232.
Gross, isn't it? Can you recommend a better way?

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Aaah, now I've got an idea for you...

Backtracking, I've used the CV LCD drivers, plain & modified, for years in many AVR apps without "garbage" problems.

Now to the idea: When you build LcdBuf1/2, do you ensure that the string is null-terminated, and null-terminated no farther out than the width of the display? One must always be quite careful when building the buf to not let any embedded nulls sneak in there.

I make my bufs 3-6 characters wider than needed, in case an itoa() or similar spits out more characters than I expect. Then when done building I slap a null into the n-th position.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Lee!
Well... I'm going even further. Before sending to LCD:
1) I put/force NULL in LcdBuf[16] (LcdBuf size = 17)
2) I check each char in buffer to be printable -> you know: isprint(x)
Moreover... messages between console and peer are CRC-protected.

Regards,
Stanley.

PS: Forgot to mention:
- processor: ATmega8 (pins are scarce...)
- Fclk = 14.74 MHz. Could this be a problem?!
Hmmm, would it be better to write my own LCD function-set for this project?
Right now I'm using a "mangled" version of Pavel's LCD lib. [CVAVR - v1.25.1]

OT: Lee, I suggested Pavel some new enhancements related to CV registers allocator, leading to smaller and faster code... who knows - probably in v1.25.3.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I checked again my source code... This time I was hunting for interrupts!
So, I have only one timer interrupt running 4 times/sec, but it's extremely short:

if(...) set a flag;

There is another timer interrupt for the 4 kHz buzzer, but this is occasional.
Other interrupts: one for Rx on RS232 and one external interrupt. That's all!

Didn't ring a bell for me... (@least, not so far)

Anyway, as long as I can't reproduce this "LCD garbage" issue, I can only guess what should be the cause... blaming the HW... or the SW... or better G.W.Bush :-)

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Works fine, but sometimes I get garbage on the LCD.
If I restart the device, LCD comes back to normal feelings...

Does that mean that once you have got garbage on the LCD, it stays that way?
We have had this problem on some LCDs in industrial apps, where big contactors were switched. Putting 100pF on every data line including E helped, but could not solve the problem 100%.
What we normally do now is a complete LCD init every now and then, sometimes as often as once a second.
(Normal refresh rate of the LCD is 3 to 4 times a second.)
The init is done completely with writing of the graphic RAM, but instead of a CLS command we use a HOME where only the cursor is repositioned but the LCD not 'erased'. This helped to get rid of any 'flicker'.

Jörg.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jörg!

JBecker wrote:
Does that mean that once you have got garbage on the LCD, it stays that way?

Yes, exactly!

Quote:
..., but instead of a CLS command we use a HOME where only the cursor is repositioned but the LCD not 'erased'. This helped to get rid of any 'flicker'.

Interesting... AFAIK "clear screen" command is 0x01 (4bit mode).
What's the command code for HOME? I can't find it in my HD44780_man.pdf file...
Is it 0x02 or 0x03... probably?

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

erickoberstar wrote:
Tony, Good technique for non real time control applications such as the one it sounds like groehen has.

Note that if your using another timer interrupt to do display updates you need to aware of issues relating to nesting interrupts. By default with CVAVR the global interrupt enable bit is not reset until an ISR exits thus eliminating nested interrupts. If your using another timer for real time control related tasks this interrupt wont run until the display update ISR completes thus introducing a delay before your real time control interrupt runs - bad from a control theory perspective.

ELO

I agree that the delay is excessive if al entire screen of characters gets sent from inside a single interrupt, but I had been talking about using a timer in 2 ways. The first timer interrupt occurs every 100 or 200 milliseconds. Itt moves the virtual display buffer to a second "send" buffer. It also sets the timer trigger every 50+ uS

This 50+ uS timer will send a SINGLE character to the LCD. It will set the LCD pins, and toggle the "E" pin, reset the timer counter to zero, and exit (I am not sure of the exact order of all these events).

Therefore, uC is NOT waiting for the entire screenfull of characters to get sent. Instead, one character gets sent per interrupt and then there is a long delay (in uC terms) where more stuff can be executed in the foreground.

In this manner there would never be a several millisecond long interrupt. Just lots of short ones.

-Tony

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Is it 0x02 or 0x03... probably?

Yes, exactly, bit 0x02 set, bit 0x01 does not matter. Function is described as 'cursor in home position'.

Jörg.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My advice, Try to use Impedance matching techniques.
In this practice, use a 1KOhm pull-down on all Data lines and E, (Ofcourse if the LCD supports 5ma Driving
@ 5Volts). This techniques is especially used in CPU
and motherboard routing for highly noise-immune lines.

BTW, if u're operating in a noisy environment, never
forget to enable CKOPT fuse (CKOPT=0). The same problems happended to me, including System hang even
when I used Watchdog, I couldn't explain why, but
the answer was CKOPT.

Good Luck
Nasser

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, brief conclusion(s) at this moment:
1) Client doesn't want HW changes. So, as usual, SW must handle HW issues... Good part of this story is that the console has a very nice bootloader + related PC application. That means I can easily upload & test new versions without extra pain!
2) At beginning, I thought it should be easy to deal with LCDs... Wrong! Now I realize I'm in deep sh*t, as I can't give any guarantee the next application version will solve the "LCD garbage"-bug...
3) I must admit I didn't understand all the ideas/solutions presented here in this topic, except the one presented by Jörg (periodically call lcd_init to resync the LCD).

If any new ideas, keep them coming! I personally learn better from examples, so code/pseudo-code is highly welcome!

Thank you all!
Stanley.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nasser wrote:
My advice, Try to use Impedance matching techniques.
In this practice, use a 1KOhm pull-down on all Data lines and E, (Ofcourse if the LCD supports 5ma Driving @ 5Volts). This techniques is especially used in CPU and motherboard routing for highly noise-immune lines.

Thanks for your advice. Yet, the HW is already in production phase, so no other modifications allowed (unfortunately).

Quote:
BTW, if u're operating in a noisy environment, never forget to enable CKOPT fuse (CKOPT=0). The same problems happended to me, including System hang even when I used Watchdog, I couldn't explain why, but the answer was CKOPT.

Nasser, I noticed that datasheet - mega8, page 26 - doesn't recommend CKOPT=0 for crystals operating close to maximum frequency. I use Fclk = 14.74 MHz.

Of course, advices regarding HW are very welcome. I hope future design(s) will take them into account. A good HW design also means a much easier life for the programmer... I think... :-)

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

groenhen: One of my boards
had 16MHz crystal oscillator.
It DID NOT work in a noisy
environment until I activated
the CKOPT. Caused me 2 months
of time-waste with no results
.

By the way, I dont
see the recommendation for not
using CKOPT.

Good luck
Nasser

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Empire11 wrote:
One of my boards had 16MHz crystal oscillator.
It DID NOT work in a noisy environment until I activated the CKOPT. Caused me 2 months of time-waste with no results.

Yes, I do believe you.
But unfortunately, as I mentioned before, I don't have any possibility to access inside the console metal-case... So, basically, for the moment I can't change the setting for CKOPT (I presume now CKOPT is un-programmed).
Yet, your information is good to know, if the client will allow me to open console's case. For the moment, I can only access the bootloader via RS232... so, I can only change the application program.

Thanks for the idea,
Stanley.

[Edit:] I forgot... the datasheet for mega8 / page 26:

Quote:
Notes:
1.These options should only be used when not operating close to the maximum frequency of the device, and only if frequency stability at start-up is not important for the application. These options are not suitable for crystals.
2.These options are intended for use with ceramic resonators and will ensure frequency stability at start-up. They can also be used with crystals when not operating close to the maximum frequency of the device, and if frequency stability at start-up is not important for the application.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Question: Would it be feasible to write LcdBuf to LCD and then read back from LCD and compare with the LcdBuf?!
Or maybe not after each LCD write operation, but only from time to time - let's say once every 10 seconds or so.
If feed-back is different from buffer, AVR performs a re-initialization of LCD.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So... waddaya say? Is it a good idea or not?
I know, it's week-end... I shouldn't expect too much feed-back these days...
:wink:

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

groenhen:

Those options u wrote were for CKSEL0, SUT=00 or
SUT=01, I was talking about CKOPT. My advice, first
make sure The cause of error is not hardware, or u
will not be able to solve it, even with 18000 lines
of code, and even if u do, It is likely that the
sytsem is not stable.

On the other hand, always make sure reinitializing LCD
wont jam tour power-lines. Simple check it with a
Volt-meter. Clearing and refilling the LCD looks like
a good idea.

If there is a console, and there are no transformers
or Relays active inside, and the console is isolated,
then Check for Fast-Blinking LED's or diodes, since
they create spikes when proper decoupling is not
applied.

Another Idea: Create a simple counter, which counts
to 1000 with 0.1sec delay and shows it on the LCD.
See if any thing goes wrong, If so, U can be sure u
have hardware, and most likely Spikes on ur VCC or
LCD's VCC line.

Good luck
Nasser

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nasser wrote:

Those options u wrote were for CKSEL0, SUT=00 or
SUT=01, I was talking about CKOPT.

Yes, you're right!
My mistake, sorry! Hmmm, where was my head?...

Quote:
Another Idea: Create a simple counter, which counts
to 1000 with 0.1sec delay and shows it on the LCD.
See if any thing goes wrong, If so, U can be sure u
have hardware, and most likely Spikes on ur VCC or
LCD's VCC line.

Yeah, first thing to try Monday morning!

Thanx Nasser!

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, back again; I have done some tests today with the console and here are the results:
1) first, I must say I've done the tests in the lab, not in the vehicle (it's a driver console);
2) when the LCD gets scrambled, the poor little AVR continues to work fine: keypad works, buzzer works, RS232 communication works... I concluded the mega8 is OK! So, it must be the LCD, right?
3) resetting the device (disconnect and re-connect) makes LCD to be alive again...
4) I didn't check using CKOPT = 0, suggested by Nasser, as I don't see how this can affect the LCD behaviour [?!?].
5) As I'm not allowed to modify the HW, my only chance is - as mentioned in one of my previous posts - to write on LCD, read back from LCD (from time to time, let's say 10 secs.), compare with buffer and if not identical -> re-initialize the LCD.
I would like your opinion on this!... Or, if you have a better idea?!?

TIA,
Stanley.

PS: Hehe, funny how 9 months of "AVR-abstinence" transformed me into a noob :lol:
[I was dealing with some 68xxx during this time...]

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

groenhen,

that is essentially the fix I mentioned above that we implment albeit a bit more robust of a solution since your reading back and comparing to determine if the display matches your buffer.

Expanding on your idea, after your lcd update code you could immediately compare the lcd's buffer with your internal AVR display buffer to see if your update got through properly, and if you see a differnce re-initialize the display.

Too bad you don't have any hardware control - hardware only guys seem to have a bad habit of viewing fixes as a simple matter of programmaing. - Unfortunately you can only do so much in software.

Regards,

ELO

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like you need to go back to the hardware guys and request some changes. At a minimum, request the ckopt change, since that's not really a hardware change.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

erickoberstar wrote:
Expanding on your idea, after your lcd update code you could immediately compare the lcd's buffer with your internal AVR display buffer to see if your update got through properly, and if you see a differnce re-initialize the display.

Good point!
Quote:

Too bad you don't have any hardware control - hardware only guys seem to have a bad habit of viewing fixes as a simple matter of programmaing. - Unfortunately you can only do so much in software.

Sir, you're daaamn RIGHT !!! :wink:

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dksmall wrote:
Sounds like you need to go back to the hardware guys and request some changes. At a minimum, request the ckopt change, since that's not really a hardware change.

Yes, I was thinking about that, too.
After all, they only have to open the damn metal-case so I can access to the ISP connector... :?
Question is: Is CKOPT=0 really necessary?... As I mentioned before, the AVR doesn't get stuck, only the LCD! :?

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

Last Edited: Tue. Dec 5, 2006 - 07:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
to write on LCD, read back from LCD (from time to time, let's say 10 secs.), compare with buffer and if not identical -> re-initialize the LCD

I think that this will not work 100% (at least this is what my experience with garbage on LCDs shows). Sometimes the data in the display RAM is perfectly ok, but the display window is just shifted. This can happen if a command is misinterpreted. Some of the LCD controllers also have additional modes (e.g. inverse)and this status is not readable.
It also appears to me that sometimes the display shows complete rubbish which could never be the result of only one incorrectly understood command or data byte.

Jörg.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Sometimes the data in the display RAM is perfectly ok, but the display window is just shifted. This can happen if a command is misinterpreted. Some of the LCD controllers also have additional modes (e.g. inverse)and this status is not readable.
It also appears to me that sometimes the display shows complete rubbish which could never be the result of only one incorrectly understood command or data byte.

Hmmm... this is indeed bad news!
And in this very moment I see only one way to solve the problem: assigning a key on the keypad - let's say 'F'-key, that may be pressed by the user to FORCE LCD RESET whenever the LCD goes bananas!

OTOH, my question still stands:
Is CKOPT=0 really necessary?... I mean: is CKOPT=0 going to solve THE LCD ISSUE?!? How?

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

groenhen:

If u are sure the atmega is operating the way it
should be, then CKOPT won't change anything. But, since
setting CKOPT will highly improve noise immunity at
no cost, enable it when u get the chance. It's better
than seeing ur micro is not responding, and U just cant
find the reason. On the other hand, it's better to try
everything u think of.

If the LCD is causing all the problems, then I assume
that LCD can't just get the job done. U need a VFO.
VFO is similar to LCD except that it uses very small
LEDs instead of LCD Cells and there are no protocol
changes so U might just by one and plug it without
changing any software. VFO's are extremely immune to
noise, specially radiations and electromagnetic pulses.

BTW, I think u should discuss this "Dont open the black
box" issue with your client. You can't fix anything
without knowing whats wrong. Maybe you can, but the
chances are low.

Good luck
Nasser

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you Nasser!
As always, very good ideas... "Rich" experience, I presume? " :wink:

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

groenhen:

BTW, Here is a simple tutorial on impedance matching
which I mentioned in the first place which MAY be the
answer to your problems.

Good Luck
Nasser

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been lurking on this thread beacue I do a lot of LCD driving, but (so far) I hae not had garbage showing up, despite ample opportunity. Just luck that I have not.

I have a further question about the "matching" part of impedance matching. What exactly is the additional resistor being matched to? How do we know the proper impedance to add?

Some stuff, like 75 ohm coax would presumably need a 75 matching resistor.

Also, I have often seen matching resistors on both ends of the data line. You only showed one at the receiving end. DOes the matching resistor only need to be on the receiving end of a one-way data line, and only be at both ends if it is a bidirectional data line? If there are 2 matching resistors, does this change the value of the resistors compared to a single resistor?

-Tony

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

spamiam:

Well, good question. Here, matching will be a resistor
u add so the total current sourced from ATMEGA is 20mA which
can be provided by the IC. In other words, the maximum
current u can get. This simple tutorial was an introduction.

The point here, however, is that the LCD might not be able
to source 20mA. So using that resistor is not recommended.
(In case u also want to read data from LCD via data lines)

The matching can apply to receivers side. IF this data line
is a bus (which means u write and read from), an additional
resistor would be required on the drivers side, since u are
also about to use that side as receiver to read value on
the line. But both of the resistors, in that case, should
not force the side which is sourcing current, to provide
more current that it can.

For example, if u have a bus line (bi-directional). One of
the sides can source 20ma, the other can do only 5ma. So ur
matching should be for 5ma. Since u need two resistors, and
also assuming VCC is 5volts, then 5(volts)/0.5R (which is
the equation for current) should not exceed 0.005A. in that
case, each R is should be 2KOhms. When in parallel, they will be 1KOhm, where 5Volts / 1000 Ohms = 5mA. So we have
not exceeded our limit which is maximum of 5mA.

Toney, the matching term is mostly used in RF in its real
meaning, which means the consumer and the providers impedance should be the same, to GET the most power from the
source to load, and prevent RF reflections on the line, such
as antennnas. Since alot of antennas are matched to 50 or 75
ohms, they made O'scopes with the same impedance to monitor
the line directly. Of course in RF u also have inductive and
capacitive reactions which is another story.

Good Luck
Nasser

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I think I finally found out what caused the "LCD garbage"...
The power connector was worn-out and either the "+12V"-wire or the "GND"-wire didn't ensure a firm contact - remember it's a driver console installed in a bus... a lot of vibrations, mechanical shocks, nervous driver maybe[?], etc.
Apparently, only the HD44780 seems to be affected by the glitches, while the AVR continues to operate normally.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how to put cap 47pf on enable line.

between enable pin to ground or controller pin to lcd enable pin.

hvrank

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Between the enable pin and ground (0V)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dear,

I am also facing same problem of LCD garbage. i have tried out lot's of hardware changes but still no result.

Application of LCD is near to High voltage transformer so its very noisy and Electromagnetic environment.

As in your post you said VFO is immune to noise so i want to try it in my design.

 

Please share detail that whare can i buy, any  part number or detail description will helps a lot..

 

Thanks ,,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Google Vacuum Flourescent Display. You will be amazed at what comes back.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jignesh Doshi wrote:

i have tried out lot's of hardware changes but still no result.

 

Such as?

 

Have you proved that the display itself is at fault and not the wiring to the display? If you haven't then you should. Just swapping to a different display technology won't help if noise is getting into your wiring.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think BitBasher in post #2 hit the problem on it's head with possible decoupling or too tight timing issues.

Timing for a HD44780 needs to be generous. The timings mentioned in the datasheets assume an RC oscillator for the thing running at some particular frequency, but has anyone even bothered to measure the real frequency the HD44780 chip is running at?

 

About software issues.

In a hard real time application writing to the display is a very low priority task.

Disabling interrupts, or doing this in an ISR would be unacceptable.

An easy fix is an intermediate buffer, and some task / file / Class that checks the buffer and writes a single character to the display periodically. No need for any delays for the display routine, just latch in the next character and return.

For very time consuming commands (I think "Display Clear" takes 45ms) you can simply set a counter, and delay further accessing of the display untill the counter expires. Or simply fill the display buffer with spaces.

Having a single place / task / class that writes to the display will keep data in sync.

Writing 4 bit data chunks to the 8-bit HD44780 data bus is a possible cause for display errors.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Jignesh
What AVR are you using and how do you have the screen connected to it?

What is your clock frequency?

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user