Prop to character lcd problem

ihmech · 2012-08-06 16:14

I'm having trouble with a character lcd display connected to my prop, everything on the display is garbled.

It worked great while everything was on my PPDB. I moved it to a prop proto board with an IDC connecter wired in. Currently it's wired directly, it's the same as I had it connected to the PPDB. I was thinking I was having trouble with voltage drops through poor connections. I checked each control and data line with a scope and I'm seeing aprox 3.3v.

I've been looking for anything I can find on 3.3v to 5v interfacing and it seems there are many ways of doing. I just don't know which is best.

ihmech · 2012-08-07 18:00

I'm going to strip everything off that I added to my proto board and try again. I may just trash can both of my proto boards and get a 40 pin dip and build my own scratch board.

kwinn · 2012-08-07 18:25

ihmech wrote: »

I'm going to strip everything off that I added to my proto board and try again. I may just trash can both of my proto boards and get a 40 pin dip and build my own scratch board.

Before you do anything too drastic you might try an npn transistor to shift the level to 5V. Set the serial driver up to invert TX, put a 4.7K resistor between the output pin and the transistor base, emitter to ground, a 1K pullup from collector to +5V, and connect collector to LCD input.

Sometimes a few mV difference in the signal is all there is between working and not working.

ihmech · 2012-08-07 19:13

@ kwinn

Thanks for the tips. I thought about using a transistor, but I'm working with a parallel display. It would be a lot of transistors even with 4bit mode.

I did come up with a breakthrough tonight.

I just stripped the first proto board I built that didn't work at all and rebuilt it (a bigger failure than the second one!). Interestingly enough, I get the same garbled message as the second proto board. It's looking like it's a few just a few mV is causing my problems since they are now the same with two different proto boards. I'll just have to order a few buffers to keep on hand. My only local supply is Radio Shack....they don't even stock Parallax stuff. :-P

The only odd thing is that the display works just fine on my PPDB but not on a proto board. Can the 40 pin dip on my PPDB provide a slightly stronger output than the QFP chip on my proto boards?

Cluso99 · 2012-08-07 19:53

I don't think you will find that it is 3v3 that is the problem. it could just be the timing is slightly off (using ribbon cables) or else a bad joint.
Might be time to post some pics and code.

Toby Seckshund · 2012-08-08 02:13

I have had some LCD (as usual for me, reclaimed from old junk) that seemed to work on one 3.3V and not another. That was because they were really 5V displays and I was just lucky when they did run at all, at 3.3 V.

Mark_T · 2012-08-08 07:33

For byte-wide level shifting 3.3 to 5V the 74HCT245 bus transceiver is handy - TTL input levels so 3.3V compatible on the inputs when powered from 5V. The 74HCT244 also works but the pin-out is less bread-board friendly. If using the '245 be careful to hard-wire the direction input correctly to avoid driving 5V into the Prop. I've used this chip to boost Prop signals for driving servos/ESCs which might be fussy about logic levels. The 245 is a 20pin DIL or SOIC and widely available.

The HC family is likely to work too, but not guaranteed because input levels at 0.3Vdd and 0.7Vdd respectively.

[edit, just a thought, a simpler solution might be to drop the 5V supply to the LCD via a 1N4001 diode or similar - might make the difference]

ihmech · 2012-08-08 09:25

Cluso99 wrote: »

I don't think you will find that it is 3v3 that is the problem. it could just be the timing is slightly off (using ribbon cables) or else a bad joint.
Might be time to post some pics and code.

Thanks,

I'll try and post a picture tonight and some code.

I've had bad joints cause me trouble in the past. That was the first thing I assumed and redone all of the joints. It didn't fix it. I have two boards built with a 14pin IDC socket wired in and a ribbon cable to the display and both produce the same garbled results. The first board I built (it was a total failure, didn't even work at all...built late with little sleep) is rebuilt with smaller wires with less crossing and shorter more uniform lengths. I had also hoped that would help too, but sadly it didn't.

I'm up for trying anything.

ihmech · 2012-08-08 09:32

Toby Seckshund wrote: »

I have had some LCD (as usual for me, reclaimed from old junk) that seemed to work on one 3.3V and not another. That was because they were really 5V displays and I was just lucky when they did run at all, at 3.3 V.

Toby,

You work like I do, I'm usually on a shoestring budget. I took apart a dead YMIU planter controller from work to see if it had a 4Mhz crystal I needed for a keypad encoder chip. It did and it worked. :-) I hate it when I need one small part and I have to order one. I usually just wait until I can put together a big order to make shipping worth it.

This display is new sealed in bag, but it is a 5v display. I know I'm flirting with a very small window of getting a solid high signal to the display. I have something to try tonight and see if it works. We'll see.

ihmech · 2012-08-08 09:39

Mark_T wrote: »

[edit, just a thought, a simpler solution might be to drop the 5V supply to the LCD via a 1N4001 diode or similar - might make the difference]

Mark_T

I bought a bag of diodes on my lunch break. RS did have those.

I'll try it out tonight and see if that .7v drop is enough.

I've got stupid questions: If my supply voltage is 5v and the logic threshold is 2.5v. Does that threshold change dependant on the supply voltage coming in?
With a supply of 4.3v cause the logic threshold to be 2.15v?

Mark_T · 2012-08-08 10:29

Pretty much yes - but remember there isn't one threshold in most chips (the Prop is rather an exception), there is a forbidden region in the middle which you shouldn't be in (just cross it quickly) - the input circuit will consume a lot more power in the middle region due to both transistors being on. Mostly this power loss isn't a big problem, but it matters for micro-power applications.

Also even if you are nominally within the threshold, but very close to it there will be two issues that might cause problems - lower noise-immunity and slower response. In general its good to have healthy margins for peace of mind!

Toby Seckshund · 2012-08-08 14:36

With the opening statement of " Parallax say that 3.3 Volts is the normal".

I have had a Prop running at 4.2 Volts ( I know that some have tried 5 Volts) and nothing bad happened (but 9 Volts did have some effects, OOPS !!!!!!!!!!), this was when it was nuzzling up to a Z80.

I am afraid to say that the 3.3/5 Volt thing sometimes led me to the AVR way out of things.

The only things that are new in my trials are usually the PCB (toner), the solder, err, no thats it.

This is my playing with Jazzed AVR based I2C (so far)

ihmech · 2012-08-08 19:03

So far the only thing I had time tonight to do was install a diode inline with the lcd power. I still get a garbled mess.

I commented out most of the code for the screens so I could just take a picture of the APF2 logo. Nine times out of 10 it will load just the logo perfectly. I can add more code and it works and then it don't. What ever my problem is...it seems small and on the razors edge of working/not working.

I have included some pictures and code.

I'm open to any improvements or ideas anyone has.

It's the first time I have wrote a useful object. I know there are many lcd objects out there. I'm trying to learn and I wanted to write my own and know how it works.

The picture of the display is it running on my PPDB.

APF2_startup_screens.spin
Lcd_driver_4bit.spin

I have noticed that my lcd object or lcd is very sensitive to faster clock speeds. I had noticed it on the PPDB and slowed the clock down so things would work reliably.

Peter Jakacki · 2012-08-08 19:20

Hi Phil, I've only just looked at your thread now but I'm a bit confused. You said or implied earlier that the LCD is serial (I think) but your photo shows a parallel connection. Also you mentioned your own "object" but I don't see any source. Just a suggestion but if you supply software and hardware details then we will be able to see about half of what you see. At present we see very very little.

ihmech · 2012-08-08 20:19

Peter Jakacki wrote: »

Hi Phil, I've only just looked at your thread now but I'm a bit confused. You said or implied earlier that the LCD is serial (I think) but your photo shows a parallel connection. Also you mentioned your own "object" but I don't see any source. Just a suggestion but if you supply software and hardware details then we will be able to see about half of what you see. At present we see very very little.

Sorry for my lack of clarification. I've been very tired putting this together.

It is a Hitachi HD44780 4x20 parallel lcd running in 4bit mode with a prop proto board, it works just fine when connected to my PPDB. Just doesn't work with the proto board.

Here is the code I am working with, APF2_startup_screens.spin is the top object.

APF2_startup_screens.spin
Lcd_driver_4bit.spin
(I'm sure my coding is laughable and sad...but I'm just learning.)

Peter Jakacki · 2012-08-08 21:08

Doesn't matter how good the code looks, does it work? If you have yours working (or just about) then it doesn't matter if anybody laughs because you've got it working!

I'm still looking at the code but the one thing that I always recommend with these LCDs which use a very ancient parallel style interface is that for modern practice that we forego the checking of the busy flag as this is the only read operation we bother doing but it is absolutely totally redundant. If you get rid of the reading you can then free up the I/O line that currently controls R/W and then just tie R/W low. The bonus for 3.3V systems like the Prop is that they don't have to worry about voltage levels. The LCDs are specified with TTL input levels, meaning that a high level only needs to be at least 2V, perfect for the Prop!.

Trying to read back on this long cable is also prone to be influenced by interference.

Make the changes as listed here in the code where we remove the check for busy and simply wait 5us after every instruction or 2ms for a clear display instruction. BTW, I've simplified the code a bit and you can always just leave the R/W line connected as it is now and just make sure it's low.

EDIT: Just noticed another function in the 4bit driver as it seems to be a totally replicated function that also check busy. Print2 (cchar) can be removed and reference made instead to Char_out

PRI WRLCD (data,rssel)
  rs := rssel
  outa[db7..db4] := inst >>4 
  outa[en]~~ 
  outa[en]~ 
  outa[db7..db4] := inst 
  outa[en]~~ 
  outa[en]~ 
  waitcnt(clkfreq/4000)            ' wait 5us (Actually this is quite redundant for Spin as it's so slow)

Pri Command(inst)
  WRLCD(inst,0)        
  if inst == 1 
    waitcnt(clkfreq / 160000)        ' if it's a clear display instruction then wait 2ms


PRI  Char_out (char)                                    ' Send character to the lcd 
  WRLCD(char,1)

ihmech · 2012-08-09 19:19

Peter Jakacki wrote: »
Trying to read back on this long cable is also prone to be influenced by interference.

Make the changes as listed here in the code where we remove the check for busy and simply wait 5us after every instruction or 2ms for a clear display instruction. BTW, I've simplified the code a bit and you can always just leave the R/W line connected as it is now and just make sure it's low.

EDIT: Just noticed another function in the 4bit driver as it seems to be a totally replicated function that also check busy. Print2 (cchar) can be removed and reference made instead to Char_out
PRI WRLCD (data,rssel)
  rs := rssel
  outa[db7..db4] := inst >>4 
  outa[en]~~ 
  outa[en]~ 
  outa[db7..db4] := inst 
  outa[en]~~ 
  outa[en]~ 
  waitcnt(clkfreq/4000)            ' wait 5us (Actually this is quite redundant for Spin as it's so slow)

Pri Command(inst)
  WRLCD(inst,0)        
  if inst == 1 
    waitcnt(clkfreq / 160000)        ' if it's a clear display instruction then wait 2ms


PRI  Char_out (char)                                    ' Send character to the lcd 
  WRLCD(char,1)

Thanks for your help!

The "Print2" was a left over from when I was trying to figure out how to work with custom characters. I figured out a while back that it was not needed, I just forgot to remove it. :-)

I put the display back on my PPDB and ran the original code to make sure everything worked. Then I tried several times plugging in the code you provided. Nothing was working, so after carefully studying your code I started working on mine.

I first worked on removing the "busy" calls and replaced them with large delays. After getting that working I kept making the delays smaller until it didn't work, then I backed off a bit so everything worked again. I'll work on simplifying the "command" and char_out" methods another night. I am including the modified code that now works on the proto board.

Thanks everyone for all of your help!!!!! This is why I love this forum!

BTW I was also able to bump the system clock from 5Mhz back up to 80Mhz. I don't have the clock speed sensitivity like I had before. Nice little added bonus. :-D

APF2_startup_screens_X.spin
Lcd_driver_4bit_X.spin

Prop to character lcd problem

Comments