minor lcd problem

[skyv]

hi all
i'm having a minor problem driving my lcd display.
it is a 16x2 parallel display.
i am using hippy's code to test.
the first line displays "Hello" as expected, the cursor then moves to the second line and prints 6 characters but not the right characters.
eg U,v,(pi sign),&,(2 parallel dashes),B
does anyone have any ideas why this is so ?

Thank
skyv

 

[jamison]

Edited by - Admin on 6/20/2005 8:35:16 AM

 

[ylp88]

Try posting your code. Are you using symbols or other characters other than your standard "A-Z" and "a-z"?

ylp88

 

[skyv]

i'm using hippy's code for parallel lcd's. a straight copy/paste from his website. i'm not sure wether i should post it here.
further to my previous description of the problem, if i remove the change line command $c0 then the message prints correctly "Hello World!" but of course its all on the top line.

skyv

 

[ylp88]

What should the second line show?

ylp88

 

[hippy]

As it seems to be the $C0 command which is causing the problem, try putting a PAUSE 10 after that and before printing the second line. Although as you are seeing the six characters it's trying to print ( "World!" presumably ), just corrupted, I'm not sure that's the actual problem. And as it works without $C0 it doesn't look like a mis-wiring or similar.

Is this a genuine Hitachi HD44780 based LCD display ?

Another thing to try is to replace $C0 with $82. This should give "HeWorld!" and prove that character addressing itself works.

Unless I've introduced any bugs into the code it should work okay. As there are a number of versions of the LCD code I've created, I have no problem with you posting the actual code you've used - I'm wondering if I've inadvertantly left a bit set in 'rsbit' ? Although what you are seeing doesn't seem to map to such a simple bit error.

The only other thought is that the initialisation bytes may need tweaking for your particular LCD module.

 

[skyv]

the first line should show "Hello"
and the second line should show "World!"

using hippy's original code it shows
"Hello" on the first line
"Uv(pi sign)&(2 parallel dashes)B" on the second line.
the second line contains the right number of characters but not the right ones.

 

[hippy]

Another thought; if you are using an 18X or any other PICAXE which supports SERTXD, you can add the following immediately after the 'SendDataByte:' label ...

- SERTXD(#byte," ",#rsbit,CR,LF)

and use the Programming Editor Terminal to see what the program is putting out to the display.

If you don't have SERTXD, using Pin 0 or Pin 1 as a SEROUT will allow the same ( use an Nxxxx baud rate ), eg ...

- SEROUT 0,N2400,(#byte," ",#rsbit,CR,LF)

 

[skyv]

i'm using a 18x so i'll be able to try hippy's suggestion tomorrow.
thank to all for the help

skyv

 

[skyv]

ok i've had a go at running the terminal prog and get
51 0
50 0
40 0
12 0
6 0
1 0
72 4
101 4
108 4
108 4
111 4
192 0
87 4
111 4
114 4
108 4
100 4
33 4

i then decided to have a play with this part of the code
MoveCursorToStartOfSecondLine:

byte = $C0
GOSUB SendCmdByte

i felt it didn't like $C0 so i changed it to $C1.
all the characters were now correct on the top and bottom line except the whole bottom line was moved one space to the right.
i then changed it to $C2 which moved the bottom line 2 spaces to the right so i subtracted 1 from c0 and made it bf,
the top and bottom lines are now both correct and in the right position.
the display is a 16x2 from oately (DL6 i think).
so it now appears to be working but i dont know why, which is quite annoying.

skyv

 

[hippy]

How truly bizarre. The $C0 obviosuly works in so far as it did select the first character position of the second line, $C1 and $C2 work as expected, but $BF acts as $C0 would be expected to !

I'll admit that I am completely stumped by this, and have no explanation at all.

One thing which I do recommend trying; the Rev-Ed LCD code in the manual. That's hardware compatible with my code, so should download and work. It would be interesting to see if that code works where mine doesn't, or if the problem appears with both sets of software.

I'm sure I've heard others on this Forum mention the DL6, so it would be nice to hear if they have had any similar problems.

 

[skyv]

i'll give Rev-Ed's code a go tomorrow, could be interesting.

skyv

 

[hippy]

Bingo - Got something. I'd been racking my brain trying to understand this or spot a pattern, and I guess spending a night hugging some rocks in Wiltshire (UK) waiting for the Sun to come up does pay dividends ...

Comparing what should have been put out when $C0 was used, and what was put out ( chars and hex values ) ...<code><pre><font size=2>Expected Observed

W $57 U $55
o $6F v $76
r $72 pi $F7
l $6C &amp; $26
etc </code></pre></font> Looking at this as a sequence of nibbles ...<code><pre><font size=2>Expected $57 $6F $72 $6C
| \ | \ | \ |
\ \ \ \ \ \ \
Observed $55 $76 $F7 $26 </code></pre></font> Somewhere it has got out of kilter with a nibble.

Looks to me like there's an extra nibble being added, but my brain is too addled to determine exactly what is going on, or more importantly why. A dropped nibble I could understand, but an extra one ... ?

I'd still recommend trying the Rev-Ed code, and after some sleep I'll try and fathom what is going on.

 

[ylp88]

What an observation, Hippy! I wouldn't have seen that in a million years - not in a long time, anyway. But is there a realtionship between the upper and lower nibble of a hex number? Is there a way to &quot;shift&quot; the digits in a hex number (like nultiplying a binary number by 2)?

If not, could this be an interpreter problem?

skyv, check your progeam that you have not pulsed the &quot;E&quot; line twice to get your $55.
Half of the binary nibble for $55 is %0101. If you clocked this nibble 2 times, you would get %0101. This is a &quot;symmetrical&quot; byte. This would explain Hippy's observation.

ylp88

 

[ylp88]

Trivial - try clocking in %0101 onto your data lines after the display has finished this routine. Do you get &quot;R&quot;. This would constitute the upper binary nibble of the &quot;!&quot; in &quot;World!&quot; and then the %0101 addsd on the remaining upper nibble resuting in an &quot;R&quot;... This could support my above suspicion that you may have double clocked a nibble.

ylp88

Argh! I feel your headache, Hippy! Enough for tonight - time to study Calculus and Chemistry... (as if that won't give me a headache, anyway...)

Edited by - ylp88 on 6/21/2005 1:27:57 PM

 

[skyv]

i'll make the suggested checks in the morning and get back with the results

skyv

 

[andrewpro]

YLP says:
&quot;But is there a realtionship between the upper and lower nibble of a hex number? Is there a way to &quot;shift&quot; the digits in a hex number (like nultiplying a binary number by 2)?&quot;

I says:

Hex is just a representation of a binary number created to make it easier for humans to look at (just like Octal though I'd like to kick whomever invented that one. It racked my brain all through college). It repesents an 8 bit byte, the 4 LSB's are the first character, the 4 MSB's are the second character. You can work with it just like a binary number programatically.

F0=11110000
F1=11110001
0F=00001111
etc. etc. etc.

 

[Technical]

Observation:

The only difference with $CO to the others is that the second nibble is 0 - so for some reason the 0 (all data lines low) is becoming the lost nibble?

Still doesn't explain $BF working though.

Remember this 'Oatley special' is a end of line 'surplus stock' item preassembled onto a carrier board, it may have been discontinued by the original user for a reason...

 

[hippy]

Back in the 'awake world', and I agree with the conclusion of ylp88 - double clocking the E line would add the extra nibble, and that is technically possible with my code ...<code><pre><font size=2>SendDataByte:

pins = byte &amp; %11110000 | rsbit ; Put MSB out first
PULSOUT E,1 ; Give a 10uS pulse on E
pins = byte * %00010000 | rsbit ; Put LSB out second
PULSOUT E,1 ; Give a 10uS pulse on E

rsbit = RSDATmask ; Send to Data register next

RETURN </code></pre></font> If the E bit in the 'rsbit' variable were set when the routine was called, this could cause an E pulse in the 'pins=' commands as well as the PULSOUT's.

Why it appears that only the MSB was being double clocked is a mystery at present, and especially so as previous debugging shows 'rsbit' has correct values when the routine is called.

That $BF works could also be explained away by this phenomena; the cursor is set wrong, extra E clocking forces a byte to be written in the non-displayed part of the LCD's memory, when the &quot;W&quot; comes to be displayed, the cursor will have moved to where it should have been using a $C0 command.

One would expect other occurances of double E clocking, and that would be expected to have also shown up as problems, and there's no logical reason as to why there's only a noticeable problem with $C0 and a posibly hidden problem with $BF.

Technical may be right that there is some problem with the module, although I'm not at present entirely convinced of this. There could be other interactions going on which we aren't identifying yet, maybe some low resistance or capacitive short, but I'm only guesing wildly.

Faced with such a problem in a commercial environment the next course of action is to get a scope or logic analyser and start observing and analysing exactly what is being put out on the bus to the LCD. Without that, I'm not sure how to proceed, as we're only seeing half the picture.

 

[skyv]

i spent a few hours looking at this today and although i'm using a good quality lab power supply, i decided to put a capacitor (10uf) across the power supply terminals. i changed the code back to $C0 and reprogrammed.the display now behaves as it should. this is quite strange as the picaxe has decoupling capacitors across it and i have used this setup for many picaxe projects sucessfully. the only thing i havn't done yet is to have a look at the power supply output with an oscilloscope. perhaps tomorrow time permitting.
although hippy's code seems to be working well now, Rev-Ed's code seem a a bit unstable in that it is intermittantly dropping characters. i won't pursue this until i've had a closer look at this power supply as i now feel that it might be related.
thanks to all for comments/advice it has been very helpful and a valuable learning experience.

skyv