Go Down

Topic: Problem With (millis()/1000) (Read 113 times) previous topic - next topic

Mar 23, 2015, 03:25 pm Last Edit: Mar 23, 2015, 03:28 pm by XboxVillain1
Really not sure what I am messing up here.  Following the LiquidCrystal guide and have encountered a seemingly unique issue.  The problem lies in the line "lcd.print(millis()/1000)"  If I use this with no cursor position I get it counting on every block of my display, but if I add in the cursor position it begins counting symbols?  Starts with a block with 4 lines in it, then on to #, 3, C, S, c, s, and so on.











Code: [Select]


#include <LiquidCrystal.h>              // Library for LCD

LiquidCrystal lcd(12, 11, 5, 4, 3, 2);  // interface pins

/*
Circuit Setup is as follows for LCD
 * LCD RS pin to digital pin 12
 * LCD Enable pin to digital pin 11
 * LCD R/W pin to Ground
 * LCD VO pin (pin 3) to PWM pin 9
 * LCD D4 pin to digital pin 5
 * LCD D5 pin to digital pin 4
 * LCD D6 pin to digital pin 3
 * LCD D7 pin to digital pin 2
 * LCD K to GND and LCD A to +5V with RES for backlight
*/

void setup() {
  pinMode(9, OUTPUT);
  analogWrite(9, 100);             // Second # controls contrast
  lcd.begin(16, 2);                // Sets number of blocks on LCD
  lcd.print("Testing LCD");       // lcd.print makes the message
  lcd.blink();                        // Makes Cursor location blink
  lcd.setCursor(0, 1);              // sets cursor by (column, row) count starts with 0
  lcd.print("Since Reset:");
             
}


void loop() {
  lcd.setCursor(12, 1);
  lcd.print(millis()/1000);
}




floresta

#1
Mar 23, 2015, 04:54 pm Last Edit: Mar 23, 2015, 04:59 pm by floresta
Quote
... I get it counting on every block of my display...
Quote
Starts with a block with 4 lines in it...
I don't understand what you are trying to describe here.  Every time around the loop you should be overwriting the characters following your "Since Reset:" label.

You have to understand how the LCD controller works in order to evaluate what you are seeing.

The LCD controller is expecting to get a legitimate displayable ASCII code which is a hex number between 0x20 and 0xFF (not counting the 8 user definable codes).  

When you send it one of these codes it looks up the corresponding bit pattern in it's ROM and sends the appropriate signals to the display so that you see what looks like a normal letter, number, or symbol.

If you see something other than what you are expecting it is because you sent the display an incorrect ASCII code.

Now take a look at the hex codes for the characters that you did see.  Here they are:

#  0x23
3  0x33
C  0x43
S  0x53
c  0x63
s  0x73 ... and so on


Do you see the pattern?

The next problem is to figure out why these codes are being sent to the display instead of those you expect.

At first glance the only thing out of the ordinary I see is the (typically unnecessary) PWM code for the contrast so I would start by getting rid of that.   I would also remove the cursor blink command as well.

Another problem is that you are going around the loop pretty quickly.  I don't know why the LCD controller should have any more problem with positioning the cursor to (12,1) than (0,1) but who knows?  Try putting a delay in the loop and see what happens.

Don

#2
Mar 24, 2015, 04:49 am Last Edit: Mar 24, 2015, 05:07 am by XboxVillain1
I will have to get a potentiometer to control contrast before I can try taking out that part of the code or I can see nothing on the screen.  Putting a delay in as small as 100ms is enough to get it to count up to 40 before it begins switching to symbols again.


What I meant by it counting on every block of the display is that it counts up as it should, but since I take out the cursor position it simply counts everywhere.  I felt it necessary to mention as it would not count properly if the cursor position is set, but seems to with no cursor position.


Edit: I bumped the delay up to 1000ms and now have it counting much higher.  Currently at 200.  Hoping it will continue to work, but this should suffice for now.  Thanks for your help.
Lowering my contrast also allows it to count higher.  At 100 it caps at 132 and at 75 it caps at about 260.

floresta

The delay is only getting rid of the symptom you still have not determined the cause.

Don

floresta

I don't know why I didn't recognize the problem sooner since I have seen it before, old age I guess.  The clue is in the pattern I mentioned back in reply #1.

The ASCII codes for the arabic numbers 0 - 9 are 0x30 - 0x39.  In your case they appear to be reversed, but they are actually 'slipped' by half a byte.  Somewhere along the line one nybble (half a byte) was lost so the display is getting the second half of one byte followed by the first half of the next one.

The LiquidCrystal library has trouble dealing with some displays when running in the 4-bit mode.  Most likely these displays are out-of-spec, their processor is running too slow.  This is how your nybble is getting lost.

You can fix this by running your display with all 8 data wires or you can use a library that is designed to handle these slow displays.  One such library is called LiquidCrystal1.0.  It was really developed to run the rare 40x4 displays but it can also deal with the smaller standard ones.

To get a copy start here:--> http://code.google.com/p/liquidcrystal440/ and follow the Downloads link to get to the latest version.

Don

#5
Mar 25, 2015, 03:09 pm Last Edit: Mar 25, 2015, 05:58 pm by XboxVillain1
I appreciate the help, but unfortunately the library you suggested isn't working either.  If it is an issue with the LCD I should be fine, was worried about my arduino more than anything.  I can always run more code in the loop if I do need it to count so long as it is under three minutes.

All should be well though, thanks for the help again.



Edit:  Seems you were exactly right.  I connected it with 8 bits and it is running exactly as it should, no delays or additional code.  I also hooked up a 10K pot for contrast, but it seemed to make no difference.

Go Up
 


Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

Arduino
via Egeo 16
Torino, 10131
Italy