Multiple LCD's?

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm interested in sending characters to 3 lcd's that will be independent of one another. . .I've managed to print to 1 easy enough, just not too sure how to designate which lcd to fprintf. . .any suggestions would be appreciated

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You will need to post way more details about your setup before anybody can provide helpful information.

--
"Why am I so soft in the middle when the rest of my life is so hard?"
-Paul Simon

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, I'm using the LCD.C and LCD.H found here:[

url]http://homepage.hispeed.ch/peter...

and I've 1 lcd functioning properly but what I want is to be able to send different data to 2 other(for a total of 3) lcd's. . .

I've the pins available, so what I initially tried was to #undef LCD_PORT and then redefine it to the appropriate port(lcd's are connected to port a,b,c). . .that way, seemed like the quickest solution but even though it returns no error, it doesn't function as it should. . .data just goes to one lcd regardless of the new definition. . .

I was thinking of going the "same data lines, different enable lines" but it would seem that if I can't get around the re-definition of the PORTA, I'm not entirely sure how I'd be able to toggle the different lcd E lines with much success...any advice would be surely appreciated. . .thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

#define and #undef are compile time directives - they only make sense to the compiler when it is doing its job, when the code is executing, these have no effect!

There is no reason why you can't have 3 or more displays sharing the same data and control bus excepting E - as long as you only access one display at a time. If you were using a RTOS or accessing the displays under interrupts then you need to be REAL careful about making sure only one display gets accessed at one time. There's a variety of ways you can access the three displays - have an array of bytes for each display, have a timer tick copy each byte of the array to the required display and you can sprintf to the required array for each display. Using fprintf you need some way of telling output routine which display you want to talk to - maybe write a routine called 'select_display' that sets a variable that the output routine uses to determine which display to use.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DEpending on the i/o size of the micro you can multiplex the lcd's several ways

First is to take the enables of each lcd and connect them to a dedicated i/o pin for each enable - cost is three i/o pins, tie all the r/w's to a common pin, and connect the datalines together. Then set the r/w for the write function, place the data on the bus and pulse the appropriate enable for the desired lcd.

That would be the simplest

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman:
Your post beat mine!! I see we are on the same page

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I assume that you are talking about the HD44780 text based LCD displays. Based on what I know, if you are just writing and not reading the three LCD displays, drive all of the lines, DATA CS & R/W common to each display. You would then send a separately controlled E clock to each display as, the E clock is what actually clocks the information into and out of a particular display.

If you are reading the LCD displays, as well, things get more complicated as, each display will need, either separately controllers R/W control lined or tri-state buffers to prevent data line contention at the common display data outputs.

Even if you are only writing two or three displays and not reading from them, you should probably use a buffer for each display to control transmission line properties - especially if the displays are some distance from each other.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

Last Edited: Mon. Oct 1, 2007 - 12:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Writing yer own library for LCDs is really simple. I always thought that modifying someone elses code is HARDER than coding the thing your self in a lot of cases. What's more, you get to learn more and taylor the code exactly to your means.

Depending on the app, it might be best to define all of the LCDs as seperate files and then use say

fprintf(lcd1,"Hi!");
fprintf(lcd2,"Hi!");
fprintf(lcd3,"Hi!");

On the connection:

AVR
|
|EN3--------------------|
|EN2-------------|      |
|EN1-------|     |      |
|        LCD1  LCD2    LCD3
|          |     |       |
|DATA(0-3)===============|
|And all other common signals (RS,RW)      


There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yep, what David said. I grow my own, every time. Whenever I want to rip someone else's code, I invariably find they wrote it for a different processor anyway :D

Thinking about it, multiple LCDs is effectively what you're doing anyway on graphics LCDs with multipler controllers; use the CS or the E line as required to select only the one you want to talk to.

What you should be able to do, if all your controllers are the same, is select all of them for the initial configuration. *Writing* to multiple places is not a problem, assuming you want the same data in each place, it's *reading* more than one at once that will break.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
*Writing* to multiple places is not a problem, assuming you want the same data in each place, it's *reading* more than one at once that will break.

Hmm, did anyone ever read anything from an LCD ? ;-)

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Hmm, did anyone ever read anything from an LCD ?

Yes, I do. As a "system diagnostic", I'll read back a sent character from the LCD memory as an indication that it is working properly.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

daqq wrote:
Quote:
*Writing* to multiple places is not a problem, assuming you want the same data in each place, it's *reading* more than one at once that will break.

Hmm, did anyone ever read anything from an LCD ? ;-)

Yes, I've read the CG and DD address counters to see where the cursor was located. And obviously, the BUSY flag - eliminating the long delays associated with writing some commands to the display.

Also, using the BUSY flag and, padding the nanosecond delays between control line transitions (rather then using function derived delays) with a few extra NOPs, allows for greater flexibility with crystal selection.

I currently have one of ZoomCityZoom's Mega644 controller boards running at 18.432MHz, driving an HD44780 based text display. The only delay that is used is for the LCD to boot up at power up. The rest of the delays are implemented using the BUSY flag and a few padded NOP instructions. Oh, and this is in 4 bit mode, as well.

When I designed the "My_LCD Serial Backpack ", the goal was to be able to communicate with the LCD via RS-232 at 115.2K BAUD. Using the BUSY flag and NOP padding for delays allowed this to happen.

The goal for the 4 bit system is the same (115.2K BAUD) but, I predict that it will be a bit more difficult having to transfer data to the display twice per character., hence, the reasoning behind the increase in operating frequency from 14.7456MHz to 18.432MHz.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh, sorry, should have came to me! System checks and waiting.
The uni (and getting up at 5:30AM) must have a negative influence on me. :-D

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

Hmm, did anyone ever read anything from an LCD ?

Yes, I do. As a "system diagnostic", I'll read back a sent character from the LCD memory as an indication that it is working properly.

Thanks Lee! :wink:

I hadn't thought about actually checking the display for proper operation at initialization. Could you more specific as to the types of checks you do?

Do you check each address location for proper character read-back?

Do you check cursor functions, such as proper cursor movement, line selection, and other status bit operation?

What other types of checks do you think is worthy?

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Could you more specific as to the types of checks you do?

Do you check each address location for proper character read-back?

What other types of checks do you think is worthy?


It is really quite rudimentary. After the startup sequence, the app "logo" is put out as a string. Then I select one character to read back. If it matches than I consider it "good".

Another thing that I have done in apps that I want to keep running even if the display is busted or missing: I made the normal wait loop(s) "soft" with a counter of the number of wait-loops. I check that, and bug out after reaching a magic value that should never be exceeded. On the way out I "log" the info to global status variables.

That cures a couple of problems: the app does not hang forever with no display, and I can check the status periodically to "know" that the display is malfunctioning and take any desired action. For example, LEDs can blink and re-inits can be tried.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

Could you more specific as to the types of checks you do?

Do you check each address location for proper character read-back?

What other types of checks do you think is worthy?


It is really quite rudimentary. After the startup sequence, the app "logo" is put out as a string. Then I select one character to read back. If it matches than I consider it "good".

Another thing that I have done in apps that I want to keep running even if the display is busted or missing: I made the normal wait loop(s) "soft" with a counter of the number of wait-loops. I check that, and bug out after reaching a magic value that should never be exceeded. On the way out I "log" the info to global status variables.

That cures a couple of problems: the app does not hang forever with no display, and I can check the status periodically to "know" that the display is malfunctioning and take any desired action. For example, LEDs can blink and re-inits can be tried.


Thanks! Good suggestions. I'll try the BUSY flag hanging loop counter check. That's a good fail-safe.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston