Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
brunomusw
PostPosted: Jul 12, 2011 - 02:14 PM
Posting Freak


Joined: Dec 15, 2005
Posts: 1165
Location: Brazil

Hi freaks....

Freaks I'm using an LCD 16x2 and the LCD Codevision library where it just use the last four data pins of the LCD. The thing is I'm getting cross-talk on this data pins from the enable pin. I tried to put far away the traces and cables of the enable pin from the data pins but still getting cross-talk on data lines. Someone already got this problem?

My cable has 30cm, I know that is long, but it's works fine, until I got some noise on Vcc and the LCD blocks my firmware in a while loop on the LCD library.

_________________
Regards,
Brunomusw
 
 View user's profile Send private message  
Reply with quote Back to top
david.prentice
PostPosted: Jul 12, 2011 - 03:10 PM
10k+ Postman


Joined: Feb 12, 2005
Posts: 20534
Location: Wormshill, England

You have a dry/bad joint somewhere on your blue trace.

The AVR has exceedingly low o/p impedance when the data lines are driven.

When the library code is reading the BUSY line, the LCD is in o/p mode. Admittedly without a very low o/p impedance, but certainly low enough to discourage any noise pick-up.

I cannot read your scope trace. I would expect a single pair of EN strobes for writing the data, followed by several pairs while it is checking BUSY (with RW=1).

Double-check your wiring connections.

David.
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
Jepael
PostPosted: Jul 12, 2011 - 07:30 PM
Raving lunatic


Joined: May 24, 2004
Posts: 6275
Location: Tampere, Finland

That is no cross-talk.

Notice the slow rise but sharp fall.

You have left/configured the pin on blue trace to be input or open-collector output.

Or in fact, it may be that you are polling for BUSY bit, and the AVR pin has to be input. The D7 pin has weak pull-up, as may be the case with AVR pin. This causes the pin to rise slowly. When E goes high when reading from LCD, the LCD drives the D7 pin hard high or hard low.
 
 View user's profile Send private message  
Reply with quote Back to top
ka7ehk
PostPosted: Jul 12, 2011 - 08:51 PM
10k+ Postman


Joined: Nov 22, 2002
Posts: 13986
Location: Tangent, OR, USA

I would add a moderately stiff pull down on the blue trace, if you find no other issues like those suggested above (badly-configured output, bad solder connection). Maybe 1K to ground.

Personally, I strongly suspect a hardware problem. An AVR output is less than 100 ohms (either to Vcc or to Ground). Even with capacitive coupling between lines, you should not see anything like that.

I often separate clock or enable lines from data lines with a ground line. Such as data/data/data/data/ground/enable/..., just to be paranoid about it all.

Jim

_________________
Jim Wagner
Oregon Research Electronics, Consulting Div.
Tangent, OR, USA

Fournier RF4d - My dream plane!
 
 View user's profile Send private message  
Reply with quote Back to top
Jepael
PostPosted: Jul 12, 2011 - 09:27 PM
Raving lunatic


Joined: May 24, 2004
Posts: 6275
Location: Tampere, Finland

Jim, I still believe it looks like that because the bus already has a weak pull-up, and the bus floats with the pull-up during the time when neither AVR nor LCD is driving the bus.

If you put a 1kohm to ground, the LCD is not able to drive so high load and you can't read the BUSY flag or anything. Voh(min) is 2.4V @ 0.2mA for standard HD44780.
 
 View user's profile Send private message  
Reply with quote Back to top
theusch
PostPosted: Jul 12, 2011 - 10:50 PM
10k+ Postman


Joined: Feb 19, 2001
Posts: 28973
Location: Wisconsin USA

I use [my somewhat adapted] CV library in many production designs. Perhaps tell what CV version you are using so I can take a peek at that library code? In my apps I always make the three control signals outputs in the AVR. I know that CV takes care of the data lines, but don't remember whether it makes the control lines outputs.

BTW, a tiny cap at the LCD end of the E line can be helpful with a long cable. One way to test is to 'scope probe the E line on the LCD. If the problems clear up while being probed, then the E line is probably a bit ratty and the probe capacitance helps clear it up.

2.04.5 doesn't set DDR for the control bits--best guess is you forgot to make one or more outputs.
 
 View user's profile Send private message  
Reply with quote Back to top
ka7ehk
PostPosted: Jul 12, 2011 - 11:31 PM
10k+ Postman


Joined: Nov 22, 2002
Posts: 13986
Location: Tangent, OR, USA

I tend to suspect Jepael's suggestion. If so, the data lines need to be driven with a good, stiff, logic source while it is writing. If it needs to be bidriectional, then deal with that on a transaction by transaction basis.

Jim

_________________
Jim Wagner
Oregon Research Electronics, Consulting Div.
Tangent, OR, USA

Fournier RF4d - My dream plane!
 
 View user's profile Send private message  
Reply with quote Back to top
brunomusw
PostPosted: Jul 13, 2011 - 04:02 PM
Posting Freak


Joined: Dec 15, 2005
Posts: 1165
Location: Brazil

Quote:
I often separate clock or enable lines from data lines with a ground line. Such as data/data/data/data/ground/enable/..., just to be paranoid about it all.

Me too Jim... Is better to be paranoid.. Smile

Quote:
2.04.5 doesn't set DDR for the control bits--best guess is you forgot to make one or more outputs.

I modify the library to separete data pins from control pins on diferent ports.. My CV version is 2.04.8a.


Thanks guys... I will check your thoughts and I make some tests on it and came back with more answers.. Wink

_________________
Regards,
Brunomusw
 
 View user's profile Send private message  
Reply with quote Back to top
theusch
PostPosted: Jul 13, 2011 - 04:44 PM
10k+ Postman


Joined: Feb 19, 2001
Posts: 28973
Location: Wisconsin USA

Quote:

I modify the library to separete data pins from control pins on diferent ports..

I have also done that. But can't you quickly look, and/or post a small complete test program that demonstrates the situation, and check that the control signals are outputs?
 
 View user's profile Send private message  
Reply with quote Back to top
brunomusw
PostPosted: Jul 14, 2011 - 03:03 PM
Posting Freak


Joined: Dec 15, 2005
Posts: 1165
Location: Brazil

Quote:
You have a dry/bad joint somewhere on your blue trace.

Can't be, 5 boards with the same situation...

Quote:
I have also done that. But can't you quickly look, and/or post a small complete test program that demonstrates the situation, and check that the control signals are outputs?

I will compare our lib and CV lib on data pins... But Theusch it should be on the data pins the problen, not on the control lines, because we separete the control and data pins, so we set the pins as I/O separately...

_________________
Regards,
Brunomusw
 
 View user's profile Send private message  
Reply with quote Back to top
brunomusw
PostPosted: Jul 15, 2011 - 02:52 PM
Posting Freak


Joined: Dec 15, 2005
Posts: 1165
Location: Brazil

Hi freaks...
We perfom some tests and with the normal CV library (no pins control and data changed) it has the same problem, data lines got spikes simillar with enable pin.

We tried the 1k pull-down, it has less spikes, but still got it...

Theusch, the change on library isn't on version 2.05? Where a new LCD library was avaliable where you can change the pins.

After all, my supecius are in the CV lib, it seens that after set the data pins, it doesn't clear it insted it put the pin to input...

_________________
Regards,
Brunomusw
 
 View user's profile Send private message  
Reply with quote Back to top
Jepael
PostPosted: Jul 15, 2011 - 02:59 PM
Raving lunatic


Joined: May 24, 2004
Posts: 6275
Location: Tampere, Finland

If at any point the CV library puts IO pins as inputs, with or without pull-ups, the internal pull-ups in the display would slowly charge the wires to logic high, until either LCD or AVR drives the bus to full high or low fast. With AVR having pull-ups on, it would just charge faster.

That is all I see from the scope picture. Now the question is, why is that a problem? It is not cross-talk and it is should not be the cause for the display not working, but something else, like ringing on E line.
 
 View user's profile Send private message  
Reply with quote Back to top
brunomusw
PostPosted: Jul 18, 2011 - 01:19 PM
Posting Freak


Joined: Dec 15, 2005
Posts: 1165
Location: Brazil

Quote:
That is all I see from the scope picture. Now the question is, why is that a problem? It is not cross-talk and it is should not be the cause for the display not working, but something else, like ringing on E line.

When We turn on some load on the mains, around my board, on the mains create some noise and on this moment our program blocks when write/read the LCD, so I think that because of the noise the LCD controller should identify the noise as a logic level that block the program to goes on...
PS: We're shure that it blocks on the LCD functions, already tested....

_________________
Regards,
Brunomusw
 
 View user's profile Send private message  
Reply with quote Back to top
Kas
PostPosted: Jul 19, 2011 - 10:18 AM
Resident


Joined: Nov 06, 2005
Posts: 678
Location: Vilnius, Lithuania, Continental EU

Looks more like a crosstalk, indeed. Can be ground wiring related, or, alternatively, AVR output settings. Would incline more towards improper or floating ground. For that a quick check on all LCD terminals running simple cycle can give a hint (with the scope). A brutal solution was to cut in a bus driver into the data and control lines to LCD (bearing in the mind signal direction). This shall exhibit the culprit; at least, shall help with noise immunity.
 
 View user's profile Send private message  
Reply with quote Back to top
brunomusw
PostPosted: Jul 19, 2011 - 12:13 PM
Posting Freak


Joined: Dec 15, 2005
Posts: 1165
Location: Brazil

Quote:
AVR output settings

It's... The AVR data pin are programmed as input so it's floating.. On the new CV library alcd, it's fixed...

_________________
Regards,
Brunomusw
 
 View user's profile Send private message  
Reply with quote Back to top
david.prentice
PostPosted: Jul 19, 2011 - 12:42 PM
10k+ Postman


Joined: Feb 12, 2005
Posts: 20534
Location: Wormshill, England

Nope. The <alcd.h> library still needs to use the RD pin in the same way as the <lcd.h> library.

The library code will write to the DB4..DB7 pins and then set the RD pin to read the BUSY status. When the RD pin is set, the LCD will use its o/p drivers when the EN pin is strobed.

The AVR will be in i/p mode to read the BUSY status. You will have a short period when both the AVR and LCD are hi-Z.

I have not studied the CV code. However it will be much the same as any other LCD 4-bit code. The only differences will be where the individual LCD pins can be assigned to any AVR pins. The old <lcd.h> library has everything on one PORT.

I cannot read your scope trace. If you provided a shorter trace, it should be easy to see the hi-Z timing.

I suspect you would find the same problems with any LCD code that uses BUSY. Since you seldom read the LCD memory, I would use a Write-Only LCD library like danni's.

The other workaround is to call lcd_init() and re-draw every few minutes.

David.
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
Kas
PostPosted: Jul 19, 2011 - 09:56 PM
Resident


Joined: Nov 06, 2005
Posts: 678
Location: Vilnius, Lithuania, Continental EU

If OP could specify in more detail if diagrams in the first post are read or write cycle related (i.e. status of R/W signal), that would help. Shall it be READ, then it's exactly as per David's explanation.
A post:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=104894&highlight=nt7603
is worth looking too, imho.
 
 View user's profile Send private message  
Reply with quote Back to top
brunomusw
PostPosted: Jul 20, 2011 - 02:14 AM
Posting Freak


Joined: Dec 15, 2005
Posts: 1165
Location: Brazil

Quote:
Nope. The <alcd.h> library still needs to use the RD pin in the same way as the <lcd.h> library.

David I really didn't go "inside" in the CV code. But we saw on oscilloscope that the libraries has differences.
I need to perfom some tests, but your ideia of lcd_init() from time to time is good.. Wink

David, the problem is a sum of things that happen and freaze the LCD...

Quote:
If OP could specify in more detail if diagrams in the first post are read or write cycle related (i.e. status of R/W signal), that would help. Shall it be READ, then it's exactly as per David's explanation.

Kas, it's only write cycle...

PS: the tests are perfom on the LCD connection that has long wires and short wires, both have the same waves...

_________________
Regards,
Brunomusw
 
 View user's profile Send private message  
Reply with quote Back to top
Kas
PostPosted: Jul 20, 2011 - 07:47 AM
Resident


Joined: Nov 06, 2005
Posts: 678
Location: Vilnius, Lithuania, Continental EU

Just wanted to draw attention that possibly this is timing issue, and not much wrong with the data signals. Regular re-init for sure can be a good workaround.
 
 View user's profile Send private message  
Reply with quote Back to top
brunomusw
PostPosted: Jul 20, 2011 - 04:20 PM
Posting Freak


Joined: Dec 15, 2005
Posts: 1165
Location: Brazil

Freaks, We did other test, disconnect the enable pin from LCD, and on the LCD put a pull-up on enable.. We write the LCD and observe it on oscilloscope: no more pick-up from enable on data pins, and on the data pins in the moment where there aren't data, the logic level doens't goes up to Vcc...

So the data pins are configurated as input and the "noise" are pick-up thorught the LCD hardware, from enable to data pins..

_________________
Regards,
Brunomusw
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits