Getting a steady output on a 1602 LCD display

Projects Programming
1

I am collecting output commands for a couple of 74HC595 output shift registers in form of integers corresponding with a bit in a 16 bit binary, add them up and send them as output command to the shift registers. I am using the same output command to display the pin states of the shift registers on a LCD display which works pretty fine. The only problem I have is that the display refreshes it self with every pass of the main program loop which results in kind of a blinking display output. Is there a way to refresh the display only if the output command has changed and if not just keep on using the old output state without refreshing the whole display in every program loop?
The LCD is controlled through a 74HC595 shift register and the shiftLCD library which I downloaded from herehttp://www.miselph.co.uk/arduino/ShiftLCD.zip

#include <ShiftLCD.h>

ShiftLCD lcd(9, 11, 10);                                                                                                                                 //initializing the LCD adapter pins
unsigned int lightOutput[17] = {1, 0, 0, 8, 0, 0, 64,0, 254, 512, 0, 2048,0, 0, 0, 0, 0, 0};    //for testing
unsigned int outputL = 0;

void setup() {
  // put your setup code here, to run once:
  lcd.begin(16, 2);
}

void loop() {
  // put your main code here, to run repeatedly:
  for(int i=0; i<17; i++) {                                           //loop through the light output array
       outputL += lightOutput[i];                            //adding up the numbers
  }

  lcd.setCursor(0,0);                                               
  printBinary16(outputL);                                  //sending  the result to dislplay

}

//function to keep a 16 digit display
void printBinary16(unsigned int iIn)  {
	//                       0b1234567812345678
	for (unsigned int mask = 0b1000000000000000; mask; mask >>= 1) {
		if (mask & iIn) {
			lcd.print('1');
		}
		else {
			lcd.print('0');
		}
	}
}

I have tried already with adding a outputOld variable and display the outputOld var which only got updated when outputL changed. with the same result, a kind of blinking display.
Thanks for any ideas to get a steady display which updates only if the value changes.

2

Its flickering because its printing 1 and 0 in the same spot very fast.

3

you should update the lcd screen only twice ( or ...) per second with the same technique as used in the famous
" blink without delay" example code here - http://arduino.cc/en/Tutorial/BlinkWithoutDelay -

update: the human eye cannot follow much more than say 10 updates per second.

4

For no flicker, just store the bits into a string. then display the string. If you use bitRead, you don't need to mask the value.

void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600);
  String Output;
  long x = 0b0101110101001100;
  //function to keep a 16 digit display
  Output = "";
  for (int i = 0; i < 16; i++) {
    Output = Output + bitRead(x, i);
  }
  Serial.println(Output); //Change for LCD

}

void loop() {
  // put your main code here, to run repeatedly:

}
5

NO, stay away from Strings, use C strings(char array) instead.

6

NO, stay away from Strings, use C strings(char array) instead.

How do you send it to the LCD?

7

Use a pointer or a simple FOR loop.

8

Use a pointer or a simple FOR loop.

That's what he is doing now. It will make it flicker.
If Strings are used properly they are safe. Witch reminds me I forgot something.
change:

 Serial.begin(9600);
  String Output;

to:

 Serial.begin(9600);
  String Output = "0000000000000000";

Then it will be OK

9

No a FOR loop to cycle through the array and change the cursor position.

If Strings are used properly they are safe.

There is an issue with the free() function, and the arduino does not have a way to clean the memory fragments the Strings make.

10

Show me an example code.
If the string is loaded when compiled and it's not expanded there are no fragments.
I don't use the free() or freeMemory()

11

steinie44:
Show me an example code.
If the string is loaded when compiled and it's not expanded there are no fragments.
I don't use the free() or freeMemory()

A C++ String object will copy itself and delete the old copy just to add 1 character.

C string arrays print the same as C++ String objects.
The flicker is not due to the storage used, it is due to changing the LCD far too often.
I'd go with a 250 ms print cycle and remember to print the whole line including spaces.
You can initialize a char array to all spaces memset( dest-addr, ' ', count ). Just be sure the array ends with 0.
The data can be set 1 char at a time or use strncpy( dest-addr, src-addr, count ) and not get a zero added to the end of the copy. The spaces from the memset() not copied over will be left alone to fill the line.

So get your data into variables/arrays but only print those as often as you can make sense of them.
Or maybe only get your data every so often.

Have you ever seen the bar graph LED displays? One of those might do.

12

Well, I use them all the time. Never had a problem. I will continue to do so.
Show an example code.

13

Do what you want. When your code starts crashing "for no reason" then maybe you will think again.
Or maybe you will always write small, well-behaved code and never have a problem in which case, fine.
But if you ever need to squeeze resources, you're going to have a bit of learning curve to get over first.

As for example code, the library sources are in your IDE if you want to see how String objects work or you can set up a loop that adds a char to a String then prints the String object address and if you really want, print a hex dump of RAM each time as well.

I can tell you it's not smart to jump off cliffs but no, I'm not going to demonstrate. I'm into my 3rd year here and have seen enough "demonstrations" in "help-help" threads anyway.

14

That's odd? All the examples in my IDE work just fine.

15

I don't have any examples to show, I deleted them all, unless I breakout my old computer from storage. That computer should have some sketches that used Strings, but I'm not going to drive to Florida or ask my brother to mail it either.

If Strings work for you then congrats, your one of the lucky ones, you and ZoomKat.

Edit:
I found one, it's not using Strings anymore, but it was at one point.

Please excuse the bad variable names.

/*
simple control test
 */
 
//#include<String.h>

volatile byte val[4];
byte x;
byte y;
byte z;
byte state;
byte speed1, speed2, speed3, speed4;

const byte ledpin = 13;
const byte Mopen = 2;
const byte Mclosed = 4;
const byte M1L = 3;// PWM
const byte M1R = 5;// PWM
const byte M2L = 9;// PWM
const byte M2R = 6;// PWM

void setup()
{
  pinMode(ledpin, OUTPUT);  // pin 13 (on-board LED) as OUTPUT
  pinMode(Mopen, OUTPUT);                                
  pinMode(Mclosed, OUTPUT);
  pinMode(M1L, OUTPUT);                                
  pinMode(M1R, OUTPUT);
  pinMode(M2L, OUTPUT);                                
  pinMode(M2R, OUTPUT);
  Serial.begin(115200);       // start serial communication at 115200bps

}

void loop() {
  if( Serial.available() )       // if data is available to read
  {
    for(int i = 1; i <=4;i++)
    {
      val[i]= Serial.read();
    }
    x = val[1];
    y = val[2];
    z = val[3];
    state = val[4];

    // read it and store it in 'val'

    if(z >=1 && x != 0 )//forwards               
    {
      speed1 = map(z,1 , 5, 0 , 255);
      Serial.println("Moving Forwards");
      analogWrite(M1L, speed1);   
      analogWrite(M2L, speed1); 
      digitalWrite(M1R, LOW);     
      digitalWrite(M2R, LOW);                 
    }
    if( z<=-1 && x != 0 )//backwards              
    {
      speed2 = map(z,-5 , -1, 0 , 255);
      Serial.println("Moving Backwards");
      digitalWrite(M1L, LOW);     
      digitalWrite(M2L, LOW);
      analogWrite(M1R, speed2);   
      analogWrite(M2R, speed2);                   
    }
    if( y <=-1 && x != 0)//Left         
    {
      speed3 = map(y,-5 , -1, 0 , 255);
      Serial.println("LEFT");
      digitalWrite(M1L, LOW);     
      analogWrite(M2L, speed3);   
      analogWrite(M1R, speed3);   
      digitalWrite(M2R, LOW);                
    }
    if( y >= 1 && x != 0)              
    {
      speed4 = map(y,1 , 5, 0 , 255);
      Serial.println("RIGHT");    
      analogWrite(M1L, speed4);   
      digitalWrite(M2L, LOW);
      digitalWrite(M1R, LOW);     
      analogWrite(M2R, speed4);                  
    }

    if(state = 1)
    {
      Serial.println("Claw Opening");
      digitalWrite(Mopen, LOW);
      digitalWrite(Mclosed, HIGH);
    }
    if(state = 2)
    {
      Serial.println("Claw Closing");
      digitalWrite(Mopen, HIGH);
      digitalWrite(Mclosed, LOW);
    }
    if( z = 0)
    {
      digitalWrite(M1R, LOW);   
      digitalWrite(M1L, LOW);
      digitalWrite(M2L, LOW);
      digitalWrite(M2R, LOW);
    }
    if(state = 0)
    { 
      digitalWrite(Mopen, LOW);
      digitalWrite(Mclosed, LOW);
    }     
  }
}
16

Unless you are using an old IDE, the bugs have been fixed.

17

I think I was using either version 19 or 20 at the time that sketch was written.

If they fixed it since then, great; if not, then i'm not surprised. But I am used to writing with C strings, so I'm not going back any time soon.

18

steinie44:
Unless you are using an old IDE, the bugs have been fixed.

The delete bug is fixed but that does not stop the String code from making copies of itself and deleting the original since THAT is not a bug but a feature fit for modern PC programming by people who want to code C like it's BASIC.

That's odd? All the examples in my IDE work just fine.

Or maybe you will always write small, well-behaved code and never have a problem in which case, fine.
But if you ever need to squeeze resources, you're going to have a bit of learning curve to get over first.

Stay in the wading pool then because it's just fine.

19

Stay in the wading pool then because it's just fine.

Don't cross the street, you may get hit by a car.
For me, to boldly go where other men are afraid to go.

20

And here's somebody who did that for a living for many years trying to give you advice about using String objects in code for small RAM environments.

They can work in limited ways. If you're very careful, you can get away with it.
But String objects are very poor tools that waste RAM badly compared to C string arrays.

If you ever get out of the shallow end, you may find out why you have been advised to learn better ways.

This ain't opinion or politics or personal. It's based on knowing how the hardware and software works.
It is advice to help you on your way as you learn what many of us are or have been doing as professionals.
It is advice borne out over and over on these boards and funny thing, it's the stubborn ones that take many pages of thread before they finally start to listen or just quit.

You really can't hold 5 gallons of water in a 1 gallon jug just because 1 pint of water fits. As long as you never fill that jug, you can believe whatever you want.