Parallel LCD display

When you are not using RW, are you grounding this pin? You should.

Yes, this RW is also soldered to ground. And when using the seven parameter, I've been keying in NULL for it's place.

Post a hi-res picture and the code that doesn't work. I'll take a look.

As I have a simple fix; I'm not all that worried about it now. But the one of the sketches I tried was from here http://arduino.cc/en/Tutorial/LiquidCrystal. The one that started working for me was:

/*
  LiquidCrystal Library - Hello World
 
 Demonstrates the use a 16x2 LCD display.  The LiquidCrystal
 library works with all LCD displays that are compatible with the
 Hitachi HD44780 driver. There are many of them out there, and you
 can usually tell them by the 16-pin interface.
 
 This sketch prints "Hello World!" to the LCD and shows the time.
 
  The circuit:
 * LCD- 1 Gnd
 * LCD- 2 Vcc
 * LCD- 3 Wiper of 10K varible resistor
 * LCD- 4 RS pin to digital pin 12
 * LCD- 5 R/W pin to ground
 * LCD- 6 Enable pin to digital pin 11
 * LCD-11 D4 pin to digital pin 5
 * LCD-12 D5 pin to digital pin 4
 * LCD-13 D6 pin to digital pin 3
 * LCD-14 D7 pin to digital pin 2
 
 Library originally added 18 Apr 2008 by David A. Mellis
 library modified 5 Jul 2009 by Limor Fried (http://www.ladyada.net)
 example added 9 Jul 2009  by Tom Igoe
 modified 22 Nov 2010      by Tom Igoe
 
 This example code is in the public domain.

 http://www.arduino.cc/en/Tutorial/LiquidCrystal
 */

// include the library code:
#include <LiquidCrystal.h>

// initialize the library with the numbers of the interface pins
//LiquidCrystal lcd(12, 11, 5, 4, 3, 2);
//                RS  R/W   EN D4 D5 D6  D7
//LiquidCrystal lcd(11, NULL, 12, 7, 8, 9, 10);
LiquidCrystal lcd(3, NULL, 4,A0,A1,A2,A3);

void setup() {
  // set up the LCD's number of columns and rows:
  lcd.begin(16, 2);
  // Print a message to the LCD.
  lcd.print("hello, world!");
}

void loop() {
  // set the cursor to column 0, line 1
  // (note: line 1 is the second row, since counting begins with 0):
  lcd.setCursor(0, 1);
  // print the number of seconds since reset:
  lcd.print(millis()/1000);
}

pin numbers were changed so I could use the analog pins but I started with the initial setup pin numbers and then the second and then the third. All three work here - with the 7 parameters.
I haven't been able to post photos of anything yet. I'm sure I'll learn soon enough.

NULL is 0 so you are using pin 0 as RW. You might have trouble with grounding the RW pin.

As I have a simple fix; I'm not all that worried about it now

Well maybe you should be worried.

NULL is 0 so you are using pin 0 as RW. You might have trouble with grounding the RW pin.

I think you mean "You might have trouble with grounding pin 0". Let me try to clarify this.

Here is the problem with your 'simple fix'. By using seven parameters you are telling the library that you want it to drive a certain pin low. By using a 0 (NULL) for the second of those parameters you are telling the library that it is digital pin 0 that you want driven low. You aren't using digital pin 0 right now so you don't notice any problems, but if you were to try to use it you could run into unexpected errors.

Don

ok, I looked through the LiquidCrystal.cpp listing and saw that if the RW line was tied to ground, then to use 255 as the pin number. So I'm changing my programs to use 255 since I intend on using D0 and D1 for another serial device.

WinstonP:
ok, I looked through the LiquidCrystal.cpp listing and saw that if the RW line was tied to ground, then to use 255 as the pin number. So I'm changing my programs to use 255 since I intend on using D0 and D1 for another serial device.

Why go to that trouble when you can just use six parameters (like everyone else) and be done with it?

Don

as per the initial post, I could never get the 6 parameters to work. That's why I decided to use 7 parameters.

WinstonP:
as per the initial post, I could never get the 6 parameters to work. That's why I decided to use 7 parameters.

Wouldn't it be more prudent to find out why you couldn't get the six parameter technique to work? No one else seems to have reported any problem.

Don

eventually I will be cleaning up my code. I learned to program in Basic over 30 years ago and back in my college days, decided I didn't think 'C' was going to be worth while. (boy, was I wrong about that :D)
But working my program a bit at a time and getting most of the functionality working first is my first goal. then clean up. most of my teachers hated/tried to discourage my sitting at the keyboard and writing my programs off the top of my head versus coding on paper first.

WinstonP:
eventually I will be cleaning up my code. I learned to program in Basic over 30 years ago and back in my college days, decided I didn't think 'C' was going to be worth while. (boy, was I wrong about that :D)
But working my program a bit at a time and getting most of the functionality working first is my first goal. then clean up. most of my teachers hated/tried to discourage my sitting at the keyboard and writing my programs off the top of my head versus coding on paper first.

You need to really re-think your strategy/methodology.
When playing with Microcontrollers, really any type of hardware, it isn't like playing with software.
You can't always get away with using the trial and error method to stumble along until
something "works" or appears to work.
With hardware if you hook things up wrong, things can be damaged or burn up.
Complicating things further is that the hardware is driven by software in this type of environment.
So that means that software can actually damage the hardware.

I highly recommend that you slow down a bit and take a much more methodical approach.

--- bill

I learned to program in Basic over 30 years ago ...

That's about the right time frame ...
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." (Edsger W.Dijkstra, 18 June 1975)

Don

boy, was I wrong about that

You are not wrong at all: we all use products from a multi-billion company founded on BASIC.

dhenry:

boy, was I wrong about that

You are not wrong at all: we all use products from a multi-billion company founded on BASIC.

Magic of licensing. Don't ever sell!

dhenry:

boy, was I wrong about that

You are not wrong at all: we all use products from a multi-billion company founded on BASIC.

Well... Yes and No. The underlying code needed to actually implement the BASIC interpreter
was not written in BASIC.

Even more comical is that in the late 80's and early 90's when NT was being developed,
it was done in C, using GNU tools running on MIPs UNIX machines.

--- bill

WOW! after those previous comments, I feel like I've been chastised and redeemed at the same time.
So what do yall think of someone who took RPG instead of Pascal?

I wouldn't worry too much about that.

The key is if you can write superior code.

Some people mistake using good tools for writing good code (the "C worshipers"). For those people, no amount of good tools can compensate for their inability to write good code.

dhenry:
The key is if you can write superior code.

Actually, I think it is more about the design and algorithms in the overall system
rather than the coding itself.
And design/algorithms are completely independent of the language used.

Coding is a very small part of an overall project and
IMO the actual language used is pretty irrelevant.
You can have brilliant, excellent, fast, and superior code within individual components
but put the pieces together in a poor design and the system will not work very well.

I used to have a saying, I used quite a bit in the past:
"Better algorithms, beats faster code every time".

i.e. a much better algorithm or system design written in interpreted BASIC could potentially
outperform a poor design written in assembler.

The moral is spend time up front to examine the system as a whole
and deal with things at a system level (before coding)
rather than try to optimize things down at the function/coding level.

Sometimes there are unknowns where some experimental trial/error coding is necessary
but those are often not the norm.

--- bill