Parallax LCD Problems

[jpanhalt]

Problem 1: Working on custom character for the degree sign. Whatever I do, there are two darkened pixels where they don't belong as shown here:



Here is the code for the character:

degree0
	MOVLW	0xF8			; Accesses lcd ram char location 0
	CALL	put232
	MOVLW	B'00000110'		; 8 bytes define custom degree symbol
	CALL	put232
	MOVLW	B'00101001'
	CALL	put232
	MOVLW	B'01001001'
	CALL	put232
	MOVLW	B'01100110'
	CALL	put232
	MOVLW	B'10000000'
	CALL	put232
	MOVLW	B'10100000'
	CALL	put232
	MOVLW	B'11000000'
	CALL	put232
	MOVLW	B'11100000'
	CALL	put232
	RETLW	0

The main program simply calls degree0 during initiation to create the character in LCD ram or ASCII character 0x00 during the print routine. No other problems with the program. I have tried various delays, but to no avail. Note the two pixels are in line 8 of the character, which is blank for the other characters too.

Problem 2: I can't make the thing shut up. Notice that the last line of the character definition is dec. 224, which is also the code for C#. It plays that note at start up, then I can make it stop by wiggling and resetting the accelerometer that is reading what you see in the screen. Everything is fine until I move the accelerometer again. I do the character definition during init, not after "start." Most important, if I comment the definition call out, no noise and the thing works as expected.

Any ideas on the problem? I have no problem sharing the rest of the code, as I will be putting it in my blog once it is finished. It is just a little lengthy (7 pages) for this question, I believe.

John

 

[alec_t]

Re problem 1, have you used the 'Function Set' command to set the dot format to 5x10 or 5x7 ? Also, are you loading address F8 (a display address according to my info)? The CGRAM addresses are 40 to 7F.

 

[AGCB]

Working on custom character for the degree sign

Is the degree sign in ascii different than what you want b'11011111' ?
Aaron

 

[jpanhalt]

I don't believe my version of the Parallax has that command. Here is what the current manual for it says:

Custom Characters
The Serial LCD has the capability to store up to eight user-defined custom characters. The custom characters are stored in RAM and so they need to be redefined if you turn off the power. You can display the custom characters by sending the commands Dec 0 to 7, as shown in the command set table. The custom character will display at the current cursor position.

The custom characters are five pixels wide by eight pixels high. Each of the characters is stored as a series of eight data bytes where the low five bits of each byte represent a row of pixels in the character. The high three bits of each byte are ignored. A bit value of one turns that pixel on (i.e. makes it black). The bottom row of pixels is often left blank (all zeros) to make it easier to see the cursor.

To define a custom character, you will send a total of 9 bytes to the Serial LCD. The first byte needs to be a valid define-custom-character command (Dec 248 to 255) and must be followed by eight data bytes that define the pixels of the character. The Serial LCD will always use the next eight bytes it receives to
set the pixels of the character. The data bytes define the character starting at the topmost row of pixels, as shown in the example code.

John

 

[AGCB]

John
I'd give it a try just to see what happens. And if you do, let us know too.
Aaron

 

[jpanhalt]

@AGCB
I tried that. It gives the note C. That is part of problem #2, I think.

Here's a link to the Parallax datasheet/manual:
https://www.electro-tech-online.com/custompdfs/2013/02/27976-7-9-ParallaxSerialLCD-v30.pdf

John

 

[AGCB]

I'll be!! I learned something new. An LCD with built in sound. They made a lot of substitutions hey?
Aaron

 

[jpanhalt]

I figured someone might want to see the init part. This snippet begins after setting the oscillator and comes just before "start."

<snip>
	MOVWF	OSCCON			; Not applicable with xt						|b1
	BTFSS	OSCCON,2		; Check oscillator stable                          |b1
	GOTO	$-1			; |b1
	CLRF	PIE1			; Disable timer1 interrupt					|b1
	BCF	STATUS,RP0		; Bank0									|b0
	BSF	SER_OUT			; Lcd reqires input high before delay			|b0
	DELAYCY	(100*msecs)		; Delay needed by lcd after power on reset		|b0
	DELAYCY	(100*msecs)		; Extra delay for lcd after power on reset(extra)	|b0
	MOVLW	0x16			; Display on, cursor off, no blink                 |b0
	CALL	put232			; |b0
	DELAYCY	(5*msecs)		; Extra delay for lcd after power on reset(extra)	|b0
	CALL	degree0			; Character 0 definition                           |b0
	DELAYCY	(100*msecs)		; Extra delay for lcd after power on reset(extra)	|b0
start
	CLRF	H_CTRH			; Ensure data bytes are cleared
<snip>

I was pretty generous with unnecessary delays. They made no difference.

John

 

[AGCB]

John
From the Smart Sensors book I get
00001110
00001010
00001110
00000000
00000000
00000000
00000000
00000000

 

[jpanhalt]

I don't think that will work with this LCD. The leading 3 bits are needed to call the proper row. I did, in fact, try an all zero row, and it crashes the custom character. The display works great without the special character and stays quiet too.

This is just a little polishing I wanted to do -- now about 5 hours worth. It is no longer a question of polish. It has become a matter of learning how to use the device.

BTW, the Memsic accelerometer seems surprisingly accurate and reasonably stable once it warms up, at least to me. It reads accurately to ±1 LSB when tested with precision angle blocks for both negative and positive tilts (total tilt each direction <9°). An LSB is either 0.1 or 0.2° depending on the angle because of rounding.

John

 

[AGCB]

It has become a matter of learning how to use the device.

I know the feeling very well. About 12 hours learning to 15 minuts polishing.

 

[jpanhalt]

Yes, back when things were actually printed on paper, we used to advise new students that two weeks in the lab could save you an hour in the library easily.

Somehow, I wonder whether modern students understand what that means.

John

 

[AGCB]

I agree

 

[jpanhalt]

The easy solution may be this: https://www.digikey.com/scripts/DKSearch/dksus.dll?Detail&itemSeq=126091816&uq=634961139908157124

I wonder how much my time is worth?

John

 

[killivolt]

The easy solution may be this: https://www.digikey.com/scripts/DKSearch/dksus.dll?Detail&itemSeq=126091816&uq=634961139908157124

I wonder how much my time is worth?

John

John, I didn't see anything from the link, say's part not found.

Edit: Maybe a screen shot.

 

[jpanhalt]

Odd, works for me (Chrome). I usually test all links I give. Here's the Digikey part number: NHD-0216B3Z-FL-GBW-V3-ND

It is $20, and has "standard" serial commands. No built-in noise either.

John

 

[Mr RB]

Since they have chosen their own way to write custom characters they may have some bug etc on the last row.

Have you tried just sending 7 bytes, ie just send the top 7 rows?

 

[killivolt]

Since they have chosen their own way to write custom characters they may have some bug etc on the last row.

Have you tried just sending 7 bytes, ie just send the top 7 rows?

Must be a glitch.

.

 

[jpanhalt]

Problem Solved

At 0100 local time, I awoke with an epiphany. I loaded the special character immediately after initialization of the display and before any screen commands. That helped, but wasn't perfect. After more monkeying around, here is what I found to make it work:

1) Added an extra 100 mS delay after initialization of the LCD (total delay 200 msecs). The other delays I had inserted appear to be unnecessary.
2) Immediately called the custom character definition.
3) Changed the character definition to use only the lower 5 bits, i.e., the high 3 bits that define line are not needed and seem to be part of the problem.

I have tried so many things since noon today that it is hard to say exactly the effect of each. I don't intend to test all the possible combinations. Nevertheless, here are some general impressions.

Regarding the use of only the 5 lower bits for definition, I had actually tried doing that early on, and when it didn't work, I went to the full 8-bit definition, which seemed to help. I got the character, but also got the noise and extra pixels. I guess the high three bits may not truly be ignored.

After reading the example code (Basic), I wondered whether immediately displaying the character was needed. When an immediate display was added to the definition, the screen filled with the character. Even with the extra delay, that still happens. Whether that is a product of the rest of my program or a function of the display will remain unknown.

Thank you all for the input. The problem was multifactorial, and those always waste a lot of time. Not being able to simulate the display was a pain.

John

Edit#2:

@MrRB : Yes, I tried not sending the last row early. Got no character.

@SHC (stochastic hill climbing): What if in putting together incremental randomly selected improvements, an early improvement actually blocks the final and best solution?

 

[alec_t]

Post deleted