Jump to content
Sign in to follow this  
Keni

Lcd_driver Controlling Unexpected Outputs

Recommended Posts

Hi All,

 

I am interfacing a 16F88 with a HD44780 driven LCD panel. My arguments are set up as below, i.e. RA6, RA7 and RA0 are the control lines, and RB4, RB5, RB6, and RB7 are the data lines (using the upper nibble). Has anyone experienced any weird output on RB0, RB1, RB2 or RB3 with this configuration?

 

I am controlling a bank of shift registers on RB1 to RB3, and I am seeing some unexpected signals on these output lines Otherwise could my logic levels be incorrect due to a missing capacitor or something??

 

Thanks everyone!

 

#define LCD_ARGS 2, /* Interface type: mode 0 = 8bit, 1 = 4bit(low nibble), 2 = 4bit(upper nibble) */ \

1, /* Use busy signal: 1 = use busy, 0 = use time delays */\

PORTB, TRISB, /* Data port and data port tris register */ \

PORTA, TRISA, /* Control port and control port tris register */ \

6, /* Bit number of control port is connected to RS */ \

7, /* Bit number of control port is connected to RW */ \

0 /* Bit number of control port is connected to Enable */

Share this post


Link to post
Share on other sites

Keni,

I am controlling a bank of shift registers on RB1 to RB3, and I am seeing some unexpected signals on these output lines Otherwise could my logic levels be incorrect due to a missing capacitor or something??
A common "gotcha" is read modify write issues.

What this means is that changing even just a single bit on a port cause the port to be read, the data is then modified and written back. When the reading process is perform it reads the actual logic levels on the port not the last value written to the port, so if you have a large external load (or a capacitive external load) the reading of the port may not give you what was last written. So an output that was turned on may end up turned off.

 

Microchip improved the situation on PIC18 devices by adding LAT registers that hold the actual value written to the port, so you are then not at the mercy of the external loading affects.

 

I hope that makes sense.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Hey Dave, I don't think that it is an external loading issue. My first version of the hardware did not have the LCD panel connected, and it worked fine controlling the shift register bank through RB1 to RB3 (I verified this again yesterday).

 

I hooked up the output lines to some LEDs and the correct signals are being output. The two issues I can think of now are either the ports are jumping state very quickly for some unknown reason, or the voltage levels aren't high/low enough to be picked up as the correct state. Unless anyone has seen an issue like this before??

 

Thanks again

Keni

Share this post


Link to post
Share on other sites

keni, It sounds like the read-modify-write problem could be your problem. What I do for that is make a variable like porta_state and then only change bits in that variable, and then set porta = porta_state; anytime I make a change.

Share this post


Link to post
Share on other sites

Hey Guys,

 

It appears my problem was caused by a long-length multi-core cable that I was using. There were a few lines which weren't connected, and were causing noise to be generated on the data lines. This was also manifested as a slight glow in some leds that I was controlling through a 30 metre line.

 

Thanks for the help!

 

Keni

Share this post


Link to post
Share on other sites
It appears my problem was caused by a long-length multi-core cable that I was using. There were a few lines which weren't connected, and were causing noise to be generated on the data lines. This was also manifested as a slight glow in some leds that I was controlling through a 30 metre line.

Keni,

 

30m!!! I am surprised it worked at all. I wouldn't dare use standard logic levels over more than 300mm.

 

If that is what you are doing I would consider a re-think before you run into other problems.

 

Regards

 

davidb

Share this post


Link to post
Share on other sites
It appears my problem was caused by a long-length multi-core cable that I was using. There were a few lines which weren't connected, and were causing noise to be generated on the data lines. This was also manifested as a slight glow in some leds that I was controlling through a 30 metre line.

Keni,

 

30m!!! I am surprised it worked at all. I wouldn't dare use standard logic levels over more than 300mm.

 

If that is what you are doing I would consider a re-think before you run into other problems.

 

Regards

 

davidb

 

 

Why's that? The multi-core lines aren't used to trigger the LED's directly, hence don't require as much current. All lines, including supply lines, are operating at DC, so there won't be the issue of long line capacitance or inductance interfering with the frequency response of my transmitted signal as it would if I were to send using AC. My control lines exhibit up to 4 Ohm at max, so I am not too stressed about power losses. The only issue I have seen so far is with line noise, which is currently controllable. Upping the voltage, changing its range, or adding some other redundancy (i.e. encoding to overcome line intererences) seems like overkill for my current design.

 

... Even though, it appears my biggest issue is trying to get my dog not to eat the cabling!!! :(

Share this post


Link to post
Share on other sites

Keni,

Why's that? The multi-core lines aren't used to trigger the LED's directly, hence don't require as much current..

Sorry I must have mis-understood your post as I assumed from it that you were trying to drive an LCD display and LEDs directly over a 30 metre cable using the PIC logic level outputs. These are unsuitable for driving transmission lines so at the very least I would expect them to be connected to some form of line driver.

All lines, including supply lines, are operating at DC, so there won't be the issue of long line capacitance or inductance interfering with the frequency response of my transmitted signal as it would if I were to send using AC.
I would be interested to see how you are driving the LCD and LEDs with DC. Perhaps I have the wrong end of the stick again.

 

... Even though, it appears my biggest issue is trying to get my dog not to eat the cabling!!! :(
Now, thats what you call interference!

 

Cheers

 

davidb

Share this post


Link to post
Share on other sites
Keni,
Why's that? The multi-core lines aren't used to trigger the LED's directly, hence don't require as much current..

Sorry I must have mis-understood your post as I assumed from it that you were trying to drive an LCD display and LEDs directly over a 30 metre cable using the PIC logic level outputs. These are unsuitable for driving transmission lines so at the very least I would expect them to be connected to some form of line driver.

All lines, including supply lines, are operating at DC, so there won't be the issue of long line capacitance or inductance interfering with the frequency response of my transmitted signal as it would if I were to send using AC.
I would be interested to see how you are driving the LCD and LEDs with DC. Perhaps I have the wrong end of the stick again.

 

... Even though, it appears my biggest issue is trying to get my dog not to eat the cabling!!! :(
Now, thats what you call interference!

 

Cheers

 

davidb

 

Hey David,

 

I have a multi-core line (5V) to control a set of transistors, and a separate power line (12V) to power up the load. Unfortunately it doesn't take too much to turn on the transistor slightly, hence why I was getting the very slight glow in some of the LEDs. The further away the load was from my control circuit, the brighter the glow. This is because the further away you get from the chip, the weaker its grounding power is.

 

The multi-core cable has decent insulation, but the cables run straight through (as opposed to twisted in CAT5). Fortunately I am not transmitting high frequency data across the line. If I was then there may be some issues. When you convert an ultra-short pulse to the frequency domain, it actually has a very wide bandwidth, which means it can suffer from the issues of long line length (e.g. cross talk in CAT5 cable).

 

Keni

Share this post


Link to post
Share on other sites
I have a multi-core line (5V) to control a set of transistors, and a separate power line (12V) to power up the load. Unfortunately it doesn't take too much to turn on the transistor slightly, hence why I was getting the very slight glow in some of the LEDs. The further away the load was from my control circuit, the brighter the glow. This is because the further away you get from the chip, the weaker its grounding power is.

 

Depending on what kind of transistors (PNP/NPN, FET, MOSFET) you can put a resistor on the base (or gate) to ground (or +5 for PNP pr P-channel) at the transistor end of the cable that will make the lines more resistant to induced voltage and line capacitance. Usual voltage divider situation.

Share this post


Link to post
Share on other sites

Personally, if I had to drive remote indicators, I'd put the transistors at the PIC end of the long cable. :(

 

I'd also add reverse connected diodes + 1K resistors across each LED. Wastes a little current but guarantees that noise pick-up will neither light nor damage them.

 

I do hope that your cable is screened and you have a suitable buffer between it and the PIC.

 

If you cant avoid bipolar transistors at the display end, I'd add a reverse diode B-E to clamp any noise pick-up, 1K to ground and 100R in series with the cable to the base. Add 100pf C-B to exploit the Miller effect and totally kill any RF gain and you shouldn't see any RF pick-up lighting the LEDs.

 

Hanging 30 m of cable off the gate of a MOSFET would be plain crazy. You would need a shunt resistor to give the gate oxide any chance of survival and a Zener clamp. I cant see any advantage in exploring that approach unless you are planning on remote control by smoke signals!

 

On the dog issue, there is a paint on liquid containing Bitrex used to stop children biting their nails. :wacko: Ask your pharmacist for it and treat the cable with it!

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...