HD44780 Based LED Display: Scrolling Text False Start

EPAIII

Member
I have been experimenting with using a PICAXE for scrolling text on some HD44780 based LED displays of various sizes. The commands I talk about below are those for that device, not any PICAXE code.

I first clear the display and home the cursor sending a 01 command to the display. Then I change to One Line mode with a 48 command. A long text message is then sent to the display using the data mode in a loop to send all the characters. This message is 72 bytes long and should be going into LCD RAM locations 128 through 199.

At this point I have tried a number of commands to reliably reset the active window to the start of my message, but none of them seem to work for all the different displays I have tried this on. On some of the displays nothing works.

Then the text is scrolled using the Pan Right command: 24 in a loop that repeats it 136 times to display the complete message two times. The scrolling does work, but some times it starts at the beginning of the message and other times it starts at the 41st character. This action seems to be random.

As I stated above, I have tried inserting several different commands just before the scrolling routing but none of them have worked. These commands include repositioning the cursor to position 128, the start of the first line, homing the cursor (2), and adding a cursor right and a cursor left command after that. None of these measures seems to have any effect.

Does anybody know of a reliable way to have this scrolling message always start at it's beginning? If possible, I need a solution that works on all HD44780 based displays. I know that is a tall task.
 

hippy

Technical Support
Staff member
Perhaps post your full code then others can try and see if they can produce the same results.

What you describe would appear to be correct for what you want to achieve. The random start is a bit of a mystery but depends on what the circumstances are in how you are starting. Not always starting from a power-on can cause issues with some displays.
 

Bill.b

Senior Member
This is code I used to scroll from right to left on a axe134Y OLED 2 x 16 display.

Code:
#picaxe 08M2

symbol baud 	= N2400_16
symbol OLED		= c.2		'Serial output to display

setfreq m16
pause 5000
serout OLED,Baud,(254,1)		'Clear screen
pause 30

main:
	 
	serout OLED,Baud,(254,128)	'first message to line 1    
 	serout OLED,Baud,(" WELCOME TO THE")
	serout OLED,Baud,(254,192)
	For b0 = 34 To 0 STEP -1
 		  SerOut OLED,Baud,( 254, 172 )  'second line message scrolled
  		  Gosub AddSpaces
  		  SerOut OLED,Baud,( "BEAR'S AMUSMENT PARK           " )
 	Next B0 
	PAUSE 5000
	serout OLED,Baud,(254,1)	'second message displayed
	PAUSE 3000
	serout OLED,Baud,(254,128)
	serout OLED,Baud,("MERRY CHRISTMAS")
	serout OLED,Baud,(254,192)
	serout OLED,Baud,("    TO ALL     ")
	PAUSE 12000
	serout OLED,Baud,(254,1)	'Clear screen
	PAUSE 3000
	serout OLED,Baud,(254,128)	'third message
	serout OLED,Baud,("  DONATE TO THE")
	PAUSE 10
	For b0 = 32 To 0 STEP -1
   		SerOut OLED,Baud,( 254, 175 )  'scroll second line
    		Gosub AddSpaces
    		SerOut OLED,Baud,( "RESCUE HELICOPTOR         " )
	Next B0 
	PAUSE 5000
	serout OLED,Baud,(254,1)	'Clear screen
 	PAUSE 3000
 	
 		serout OLED,Baud,(254,128)
 	serout OLED,Baud,("CAROL AND BILL'S")
	PAUSE 10
	SerOut OLED,Baud,( 254, 192 )
     	SerOut OLED,Baud,( "CHRISTMAS LIGHTS" )
     	PAUSE 12000
     	serout OLED,Baud,(254,1)
 	PAUSE 3000
    	serout OLED,Baud,(254,128)
 	serout OLED,Baud,(" VOTE FOR US AT")
	PAUSE 10
 	For b0 = 42 To 0 STEP -1
   		SerOut OLED,Baud,( 254, 166 )
    		Gosub AddSpaces
    		SerOut OLED,Baud,( "www.santaswharehouse.com.au         " )
  	Next B0 
	PAUSE 5000
	serout OLED,Baud,(254,1)
 	PAUSE 3000
 	goto main
	
AddSpaces:			'routine to add spaces before message

  	If b0 > 0 Then
   		For b1 = 1 To B0
      		SerOut OLED,Baud, ( " " )
      		PAUSE 50
    		Next B1
  	End If
  	return


Bill
 

EPAIII

Member
Hippy,

Here is precisely what I send to the LCD:

LCD Command 01 (Clear and Home Cursor)
LCD Command 48 (8 Bit Mode/1 Line)
LCD Data "Now we demonstrate scrolling a message that is too long for the display."
LCD Command 24 (Pan Right)

The Pan Right command is sent 136 times in a For/Next loop with a 250 ms Pause following each one to allow the message to be read as it scrolls. This scrolls it across the screen two times.

The correct message is displayed. I have confirmed that it is loaded at the correct LCD memory positions. The scroll does work and does actually scroll all of Line 1, including the unused memory positions, a full two times, stopping at the proper point when it starts at the beginning.

My question has more to do with the displays than the PICAXE. I was just wondering is anybody else had had scrolling problems and found a way to solve them.


Perhaps post your full code then others can try and see if they can produce the same results.

What you describe would appear to be correct for what you want to achieve. The random start is a bit of a mystery but depends on what the circumstances are in how you are starting. Not always starting from a power-on can cause issues with some displays.
Bill.b

You are using a serial display. I am working with parallel input ones. Perhaps I should have stated that more clearly, but the HD44780 is the parallel interface chip used on those parallel input displays. I am not sure how the two compare.
 

Technical

Technical Support
Staff member
Don't assume that the home cursor position is set on command 1 (clear display), add a specific address command (128) as well first. Some OLEDs we have used require this. Also make sure you leave the appropriate delay after the clear display command.

If nothing else correctly aligns can't you simply remember how many shift rights you have done and then 'undo' them with shift left to reset, possibly hiding the display first?
 

EPAIII

Member
Technical,

I have tried repositioning the cursor between the data and the Shift Right commands and it did not seem to help. The 01 command is listed as "Clear Display AND Home Cursor" in all the data sheets I have read. The 02 command is supposed to just home the cursor to the beginning of Line 1. I can not use 01 at that point as it would erase the message I have just sent, but I can try a 02 (which I believe I already have). I just tried that and also a 12 command which is supposed to turn the display on with on cursor. Neither of them helped.

I was not aware that any delay was necessary after the 01, Clear Display and Home Cursor command. How long should I have to wait? And what is your source for this? I tried a one second wait and it made no change.

Could this be a bug in the displays?
 

Technical

Technical Support
Staff member
We've never had heard of any problem scrolling with any LCD/OLED . However you have not given us the brand of LCD you are using or your full PICAXE code - we need both to help any further.

The Winstar OLEDs we sell do not use genuine HD77480, they use custom chips designed to work 'exactly like' HD77480. Hence the very slight differences in functionality of some commands such as home '01'.




[h=2][/h]
 

EPAIII

Member
I am going to need a day or two to get a list of displays that exhibit this behavior. I will have to test all the displays that I have again and a holiday looms. I have at least six different displays and several have shown this behavior while others have not. But that may have been coincidence from too few tests. I am going to need several hours, undisturbed.

I am hesitant to post my code as I am working on a project that I do not want publicized until it is finished. If you can assure me that it will be held in confidence and provide a private method of sending the code, I can do that. It is a bit long, 619 lines at this point. And, without my hardware, which is in breadboard form now, the code will do nothing.

I will say this about the code, it does faithfully send all the other commands and data that the displays are capable of using. It consists of a group of subroutines that are essentially hardware specific drivers and a main loop that demonstrates all the capabilities of the LCD displays, using those subroutine/drivers. The section for the scrolling text demo is the only one where any problems have been observed. All other functions of the LCD work perfectly.

One thing that I did notice last night (early AM actually) is that my For ... Next loop that is supposed to send the Pan Right command 136 times is only sending around 120 of them when the display starts at the wrong position. Here are those lines of code:

b0 = PanR ; PanR is a Symbol set to 24 at the top of the program
For b2 = 1 to 136
GoSub LCDCmd ; LCDCmd is a subroutine that sends the word in b0 to the LCD
Pause ScrollRate ; ScrollRate is a Symbol presently set to 250 at the top of the program
Next b2

So the scroll starts at the 41st position in the text and pans 120 times instead of 136 times. The false start point seems to be fairly constant, but I have not counted the Pans enough times to be sure of the 120 figure. This seems strange and perhaps points back to the PICAXE code. But how can a simple For ... Next loop not execute the proper number of times? There are no conditional statements in the LCDCmd sub or in the additional sub that it calls. Just straight code. So I still do not see any fault in my PICAXE code. I suspect that the "missing" 16 or so Pans are being sent but the display is not visible for them. That would mean it is actually starting the pan on position 41 - 16 = 25. ?????

I am also working on Arduino code to do the same things. It will be interesting to see how the scrolling works there.
 

Technical

Technical Support
Staff member
We think you are just mistaken in your assumption of what the LCD will do.
One line mode on a 2 line screen just means one line is displayed/visible, it doesn't mean you can use all the RAM for that single line.

The LCDs and controller encoding system are designed for a maximum of 64 characters on 2 lines. So line 1 starts at 128 and line 2 at 192 (64 more than 128). But we think only 40 of those 64 are actually ever used.

So it would be logical to us to assume the maximum number of valid shift left or shift rights that ever need to be supported would be 64. Or possibly even 128, but no reason to have any more than that (and assuming smallest screen size is 8 characters, 128-8 = 120, so that's another possibility). So assuming overflow and then using 136 shifts could well be causing your issues?

The PICAXE will always send the correct qty in the for..next loop. But if you are overflowing the LCD's maximum allowed number of shift left/rights that would explain your strange unreliable behaviour, and also different brands may react in different ways because you are doing something simply not expected.

Have you tried a much shorter msg, under 40 characters. Does that work?
 
Last edited:

EPAIII

Member
No interrupt handlers. The subs use b0 and b1. So I used b2 for the loop variable. I don't see any possibility of a conflict there, but am I wrong? I thought I was very careful there.

Something else could interfere with the loop counting variable. Perhaps a subroutine that is called, perhaps an interrupt handler.
 

EPAIII

Member
First, I appreciate your working with me. Thanks!

So I may have overstepped here with a 72 character message. OK, I will try a shorter one, but still longer than the display width.

My intention with 136 shifts was to display the message two times. It does repeat with about ten blanks between the two times it shows. When it does start at the beginning, it does display twice and stops with the last 15 or 16 characters left on the screen. So it does appear to go round and round with more shifts. I suspect it could be run in an infinite loop. Another thing to test.

My real problem is not in how many times the Pan Right command can be issued, but in where the scrolling starts, JUST BEFORE the first Pan Right command is issued. Another test coming on. What if I end the routing before the shift loop starts? What will be displayed? I have to try that.


We think you are just mistaken in your assumption of what the LCD will do.
One line mode on a 2 line screen just means one line is displayed/visible, it doesn't mean you can use all the RAM for that single line.

The LCDs and controller encoding system are designed for a maximum of 64 characters on 2 lines. So line 1 starts at 128 and line 2 at 192 (64 more than 128). But we think only 40 of those 64 are actually ever used.

So it would be logical to us to assume the maximum number of valid shift left or shift rights that ever need to be supported would be 64. Or possibly even 128, but no reason to have any more than that (and assuming smallest screen size is 8 characters, 128-8 = 120, so that's another possibility). So assuming overflow and then using 136 shifts could well be causing your issues?

The PICAXE will always send the correct qty in the for..next loop. But if you are overflowing the LCD's maximum allowed number of shift left/rights that would explain your strange unreliable behaviour, and also different brands may react in different ways because you are doing something simply not expected.

Have you tried a much shorter msg, under 40 characters. Does that work?
 

EPAIII

Member
Some more information.

For all of the below I inserted a go to just after the display is initialized and a simple, two line opening greeting is displayed. It then skipped directly to the scrolling routine. This was mainly to save time in observing the results, but also eliminates all the other manipulations of the display that occurred between those points.

I tried a shorter message, 32 characters and only 70 Pan Rights. It still randomly starts at character 41, which is now blank. The message shows up after a long blank screen as most of the memory positions are blank so it has to shift all the way around to the start. Only a part of the message appears with these numbers.

I tried a wait command just after loading the message and BEFORE any Pan Rights. It still randomly displays at character 41 (a blank screen) or at the real start. I then used a goto to skip over the Pan loop so that never occurs here. I don't think we can blame the Pan commands.

I tried loading the full, original message and created an infinite loop of Pan Rights. It started on position 41 and has been scrolling by for at least an hour and a half now. There does not appear to be any limit to how many times you can Pan the display window. The message just rolls by again and again.

I am really starting to think that this is just a bug in some of these displays.

I will compile a list of the displays I have tried and the results on each as soon as I can. They are not well marked so I will have to research my purchases.
 

hippy

Technical Support
Staff member
I tried a shorter message, 32 characters and only 70 Pan Rights. It still randomly starts at character 41, which is now blank.
It is not clear how mean "starts at character 41", or how you know it is character 41. It is also not clear how you mean by "starts". Is this "start" from a power-up or is it immediately after a download or on a hardware reset with an already powered display ?

It is not uncommon for a display to behave oddly immediately after a download or reset when an initialisation sequence is sent to an already powered and initialised display. This may because a write to the display was interrupted by the download or reset, the initialisation sequence is confusing it when already initialised or perhaps for some other reason.

It would be best to strip your code down to something simpler; enough to demonstrate the behaviour but does not disclose what the rest of your code does, something you can post in public. That will allow others to examine your code or test with their own displays.
 

EPAIII

Member
SOLUTION!

First, hippy on the the "character 41" thing, I am sending a message that consists of 72 ASCII characters to the display. That message is, "Now we demonstrate scrolling a message that is too long for the display." When I started the scroll, the "h" of the word "that", which is the 41st character in that message, is at the upper left position of the display so it reads "hat is too long for" on a display that is 20 characters wide. The rest of the message from that point on, then scrolls across the top line in the screen.

Anyway, I believe I have found the problem. I was using an initialization routine that was a combination of several documents that I have on these displays. As I said, I have several displays and am trying to write code that is as universal as possible. I attempted to make my initialization incorporate all of them. Apparently I did not look far enough and the initialization I was using was not ideal. It appeared to work for all other functions, but produced varying results for this demonstration of scrolling text.

Then I found this:

http://web.alfredstate.edu/weimandn/lcd/lcd_initialization/lcd_initialization_index.html

It is by far the best document I have found on this subject. It talks about the real importance of delays between the steps in initialization and I would assume in your program too. It also talks about what is happening with some of the steps.

I set up a spread sheet with all the recommended initialization routines for the various devices I have and from other sources. Then I did a new one of my own, with heavy reliance on the Alfred State document. When I tested it, most of the devices now scroll properly. One of the ones which still do not is a large, four line display that uses five different driver chips so I am not surprised. I do not have the OEM's data sheet on it so I am just winging it. I am surprised it works at all. And it does work better with my original initialization for the other functions. I think a lot of work would be required to get it working with that one. There are probably some extra commands to address the additional driver chips.

The other one that does not scroll properly does do it properly with my original initialization. There are definitely differences in the various "compatible" versions of the HD44780.

So it is not possible to use a universal initialization routine for these LCD devices if you want to use the more advanced features, like scrolling. I tried to reach too far.
 

EPAIII

Member
I have downloaded, printed, and read another document on the same website titled LCD Addressing. It is also an excellent read for anybody working with these displays. It sorts through the various sizes of displays that all use the same control chips and explains how the memory addresses in the controllers are mapped to the displayed character positions. Basically the internal memory is 80 characters, but is broken into two 40 character lines. Since my scrolls started either on character 1 or on character 41, it would appear that they were starting on the first character of one or the other of these two lines. The choice appeared to be random, but perhaps there was a further, hidden mechanism at work here.

I will read through the section on 20 x 4 displays again, slowly to see if I can gain an insight into my problems there. Perhaps a clue on the correct initialization for it. From the first reading, I do not think a scrolling message is a good idea with it as all 80 characters are displayed at all times so it would just go round and round, but with a weird line order (1 - 3 - 2 - 4).
 

hippy

Technical Support
Staff member
Don't forget that LCD controllers had their command sets designed when only one line displays were common and microcontrollers were limited in capability and controllers often don't know the size of display which is actually attached.

What that means is, though they are implemented to maintain compatibility, some commands may not be that useful in some implementations.
 

EPAIII

Member
hippy, quite true. This is explained very well in one of the pages of the Alfred State U. site I referred to above. It is an excellent read on the subject.
 
Top