I have a standard cheap HD44780 16x2 hooked up to atmega328p via 74HC595 SR in 3-wire configuration with a 0.1uF cap decoupling the supply right at the Vcc pin on the SR. In steady state everything works fine and the display will work indefinitely if left alone on the table. I bought a crappy aluminum enclosure from RadioShack (RadioShack.com Official Site - America's Technology Store) and when the rim of the LCD touches the metal it sometimes causes garbage text on the LCD. I then found that I could just take a jumper wire from ground anywhere on the board or LCD and rub it across random metal objects and reproduce the same result.
So thinking I had a bad contact or loose wire, I reproduced the entire setup on a breadboard with a completely new SR and LCD and again put a jumper on the breadboard ground rail and touch it to aluminum enclosure or hobby knife or whatever and get the same result.
What am I missing here? Do I need some filtering on the signal side of things coming into SR? I did read in the Arduino SR tutorial to put a 0.1uF cap on the latch pin (http://arduino.cc/en/Tutorial/ShiftOut), but that only seems to stop the display from updating, and I read elsewhere on the forum not to do that.
Putting a cap on the latch pin isn't a good idea, it doesn't allow the latch pin to go 'High' fast enough before you bring it back down again.
Put a 10uF between VCC and GND close to the input lines from the arduino and put 0.1uf caps on the LCD and 595 VCC and GND pins, as close to the devices as you can.
TheCoolest:
Putting a cap on the latch pin isn't a good idea, it doesn't allow the latch pin to go 'High' fast enough before you bring it back down again.
Put a 10uF between VCC and GND close to the input lines from the arduino and put 0.1uf caps on the LCD and 595 VCC and GND pins, as close to the devices as you can.
Understood about cap on latch pin.
I will try adding cap near LCD as suggested.
When you say "close to input lines from the arduino", do you mean near where I'm taking power from arduino?
Well, when it's inside your box the big cap should be as close to the inputs as possible, but it doesn't matter that much.
The 0.1uF decoupling caps should be as close as possible to the VCC and GND pins of the devices they are supposed to provide filtering to.
595s are very susceptible to noise and ground bounce.
Keep your power lines and grounds for all the components as short as possible
and particularly the ground and power wires that power the 595 and the LCD.
Also you will need a decoupling cap across the power and ground lines of the 595
as close the 595 as you can get.
Ok, here is an update: the short answer is that it looks like a problem caused by this specific wal-wart and I cannot reproduce with other power supplies.
How I discovered this:
I tried all of the above suggestions yesterday and nothing worked (thanks for the replies BTW; I tried posting pics but my connection was too slow). I got discouraged and decided to strip everything down to a simple use-case, so took new Uno (other project is breadboard atmega328p with a bunch of other circuitry) and connected only SR on breadboard with LCD + onboard POT to contrast. Hooked up my laptop and wrote simple program that uses LiquidCrystal_SR.h and increments a counter every 500ms and prints to screen. With this setup I could not reproduce the problem at all. So at this point I become very discouraged because I spent a lot of time soldering on the other project and it's looking like my problem is caused by some of that other circuitry. My plan is to start adding things to the Uno incrementally until it becomes the same circuit as the other project and see if I can identify the problem along the way... First up (and easiest difference to test), power supply on the other project is 9v 1.5A wal-wart, not USB to laptop like I have on Uno at the moment. So I switch the Uno to that power supply and hook a long lead to ground on Uno and touch it to various loose metal objects (e.g., aluminum enclosure, metal caliper, hobby knife, etc...) and can immediately reproduce the problem. I then switch back to USB, but now instead of laptop I use desktop computer, again no problem at all. Then I scour the house looking for another wal-wart with acceptable parameters and find a 13.5V 300mA brick. Cannot reproduce the problem using this new brick... So must be my original supply causing the problem.
So I switch back to problematic power supply and try adding capacitors of various sizes (10uF, 47uF, 470uF) to the output side of the 7805 linear regulator and cannot make the problem go away.
Well as you just said it's possible that this was a bad power supply.
If you have a scope by any chance you can try checking its outputs to see what's going on.
The power supply could be a red herring.
Perhaps some power supplies are simply masking the true problem.
I'm still guessing ground bounce caused by improper wiring or filtering,
since 595s are notorious for noise issues.
I've had this very problem while doing testing on SR and SR2W code with fm's library.
It can easily be accidentally created by using a breadboard and using the two power/ground
rails and using ground or power for the LCD from one rail and ground or power for the 595
from the other.
The 595 makes a big (albeit short) current drain during transitions on the output latch.
If the 595 is wired to run in "non latching" mode this happens on every clock.
The schematic you are using does not run the part in "non latching" mode but
the E signal is being driven at the same time as the latch pulse to the 595.
This violates the hd44780 spec since the spec requires the control lines to be valid
prior to raising E and in this case the LCD will "see" E is being raised before the control line
are stable.
The internal propagation delay from STCP/RCLK to output pin is in the 50ns area
(wire lengths and slew rates through the wires increase this time)
In most cases you can get away with this, but it is possible that a power or wiring issue
can extend this time and create an issue.
I run the 595 in "non latching" since I mostly use SR2W
(which is the same as SR in 2 pin mode)
For 3 Wire mode you can run the 595 in "non latching" mode and drive E directly.
This ensures that the control lines are stable prior to E being raised.
I put the cap in the breadboard literally right up to pins 8 and 16 where the
cap sits over the top of the 595.
Here is an ascii schematic for the SR interface that will be in fm's library in a future release:
It would still be interesting to see some photos your actual circuit and wiring,
particularly in the case where one power supply works and another doesn't.
First of all, thank you for taking the time to reply and help out.
I could certainly believe that the "good" power supplies are masking a problem. So far I have been unable to reproduce the problem with any power supply other than the original bad one. And with that one I can reproduce every time in seconds.
I am willing to try different configurations and keep testing, as I am here to learn after all. I have attached a picture of the simplified breadboard setup with Uno as well as the "backpack" thing I made soldered to the LCD that I originally discovered the problem with. There is a decoupling cap 0.1uF on the breadboard version right at the Vcc pin of the 595, it's a bit hard to see in the picture.
Now it is looking like the power supply was a red herring. I tried many power supplies and finally located another that allowed me to reproduce the problem.
Not sure what to try next. I did a bunch of searching and did find others that were putting low-pass filters on the RCK of the 595. I haven't tried this yet other than adding a 0.1uF cap once as stated in OP. I would think that you'd have to know how long the software is holding that pin high to ensure the time constant of the filter is short enough to be stable. Unfortunately I don't have access to a scope so it's going to be trial and error for me.
Bill - you said that this problem is even worse in non-latching mode, right? What is the solution in that case? Also, looking more closely on the fm lib docs there are some more elaborate circuits that look to have filtering than my simple circuit...
It isn't that the "problem" is worse. It is just that the extra transitions/latches
can aggravate any existing issues.
Is the problem the same on the backpack vs the breadboard?
Can you draw the exact schematics that you are using?
I see 6 wires going to your backpack and two resistors and a single cap.
I can't tell from the photo how that is wired up.
The bread board is very difficult to tell.
On the breadboard there is an orange wire going off the photo.
What is that connected to?
Are you driving the LCD contrast voltage input directly with an Arduino pin?
Given the components I see, there doesn't appear to be any filtering
to smooth out the voltage. I'm not sure what affect that has on the LCD
circuitry. That might exacerbate the issue.
analogWrite() does not create an variable/analog voltage output it creates a PWM signal.
The contrast input on the LCD wants a voltage not a PWM signal.
You can convert that to a voltage but you will need some filtering.
See this for a quick overview: http://www.thebox.myzen.co.uk/Tutorial/PWM.html
Does the problem go away if you add the RC filtering or
add a pot instead?
I use a pot and the circuits in SR2W see LiquidCrystal_SR2W.h (I'm the author of that code).
The one above is one that I have used for SR
and will be included in a fm library update in the near future.
I've added backlight control to SR and also added ascii schematics to SR.
The update essentially obsoletes SR2W since the wiring
for SR2W and SR when used in 2 Wire mode is the same.
Yes, the problem is the same for both backpack and breadboard setup.
I can draw the schematics later when I get home. I'll try to describe backpack:
3 wires are 5v and Grnd, and a reserved wire for future use currently not connected to anything on backpack.
Other 3 wires are Data, Latch, and Clock.
The resistors form a voltage divider for contrast since I did not have a Pot available.
The backlight is hooked up to 5v (red wire on top jumping over 595).
There is 0.1uF cap between Vcc and Grnd right at Vcc pin on 595 (where power comes in from main board).
LCD and 595 are connected as the earlier schematic indicates with LCD E pin shared with latch pin.
Power coming from 7805 regulator with 10uF caps on input and output.
As for breadboard:
There is cap at 595 Vcc and at LCD Vcc.
The orange wire going out of picture is floating from breadboard ground rail and is what I am using to create the synthetic noise.
Contrast is being driven from blue Pot on my protosheild
Power coming from Uno board.
okstumbler:
The orange wire going out of picture is floating from breadboard ground rail and is what I am using to create the synthetic noise.
ok so this really jumped out at me.
I guess I totally missed the original issue in post #1: (oops....)
when the rim of the LCD touches the metal it sometimes causes garbage text on the LCD. I then found that I could just take a jumper wire from ground anywhere on the board or LCD and rub it across random metal objects and reproduce the same result.
This definitely sounds like a ground potential issue.
Injecting noise/voltage into the circuit ground can cause all kinds of strange issue.
I'd connect the case to circuit ground to create a common ground.
This definitely sounds like a ground potential issue.
Injecting noise/voltage into the circuit ground can cause all kinds of strange issue.
I'd connect the case to circuit ground to create a common ground.
This does not seem to help.
And I still don't get why it is impossible for me to reproduce with most power supplies.
I have a car usb charger (12v --> 5v adapter) which causes heavy interference problems with the radio and gps navigators...
It's quite possible that a low quality or defective power supply will introduce enough interference into the circuit to mess things up.
I can't understand why are you determined to reproduce the issue with other power supplies when clearly the issue you were having was due to a specific unit.
If you have access to a scope try connecting it to a scope with your circuit connected to it and see what goes on the power rail.
I wanted to suggest that. it's really simple. Only make sure you use very stable source of power for the arduino, such as a 9V batter. Or at least use one of the "good" PSU's to power the arduino-scope.
You haven't identified in which country you are (and thus what season it is; what humidity) or whether you are in air-conditioning and such but it sounds like the USA.
The problem much more likely relates to electrostatic discharge, not mains frequency injection. The problem is that static discharge to the ungrounded shell of the display capacitively injects impulses into the HD44780 and scrambles it. If this is a problem, you need to firstly ground the shell of the LCD display.
If it is already grounded (check with a multimeter) and the situation is more generic, that injecting static into any ground point in the lash-up causes the behaviour, then you must have some serious static in your environment, sufficient to propagate through your wiring by induction.
The connection with power supplies is not in regard to their filtering, but their isolation between primary and secondary and particularly this capacitance (or merely whether the capacitance favours the "live" or "neutral" mains pin - re-try each supply plugged in upside down!). Precisely which way this relates is not immediately obvious - but you could by way of interest, measure the primary (mains pins together) to secondary (ground) capacitance with a capacitance meter (such as the ones readily and cheaply available "bare bones" using a microcontroller and 16 x 2 LCD display!) and see if there is a common factor.
In general, it may be a good idea to pay attention to ESD; use a wrist strap; ensure all your instrumentation has grounding, ground metal parts of benches (via 1M resistors) and remove upholstery with synthetic materials. While a nuisance at this stage, when built into that perfectly serviceable aluminium case and grounded to it, there should be no problem.
