Shop OBEX P1 Docs P2 Docs Learn Events
Parallel LCD with BS2?! — Parallax Forums

Parallel LCD with BS2?!

RGuyserRGuyser Posts: 90
edited 2006-06-03 06:43 in BASIC Stamp
So, I have tried 2 different Hitachi-type 2x16 parallel displays using the schematic from http://www.parallax.com/dl/docs/prod/audiovis/lcd2x16par.pdf

I am not having any luck. Both displays have 14Pins. When I give the things my Vin, which is about 9V they get black bars, when i give them VDD, I get nothing.. The contrast pot does adjust the contrast, but it is jumpy and not super linear. I am using a 1k pot that came with the homework board kit...

I have used one of the dispalys before with a pic micro.. It does emulate the popular hitatchi displays..

Any really good tutorials on this or other guidance?

Comments

  • Bruce BatesBruce Bates Posts: 3,045
    edited 2006-06-02 07:37
    RGuyser -

    The nominal input voltage for an HD44780U Hitachi compatible display is 5 volts! What you may be seeing is the liquid inside the LCD BOILING!

    Regards,

    Bruce Bates

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    <!--StartFragment -->
  • RGuyserRGuyser Posts: 90
    edited 2006-06-02 07:41
    Geeze. That actually sounds about right. It would linger a bit after power was removed...

    So, once boiled, destroyed? ive got 1 more lcd.. 1x16, i think.. grrr!

    the schematics provided by parallax work, yeah?
  • RGuyserRGuyser Posts: 90
    edited 2006-06-02 09:02
    Ok!

    So I probably killed my other, superior LCDs, but I got this small 2x16 parallel LCD working with the previously linked code..

    questions!

    - can the bs2 only read to the lcd out of the eeprom, or can i have it display the contents of arrays\variables somehow
    - does anyone know of an example of a simple "OS" using a 2x16 parallel LCD (code example)
    - is there a usefull set of libraries or routines somewhere to make the LCD easier to use?

    I saw another document, a nuts n voltz article that had a 4x20 lcd doing an OS, if i recall, it was using the eeprom as a buffer between the BS2 and the LCD? Yes?

    Thank you!
  • Tom WalkerTom Walker Posts: 509
    edited 2006-06-02 13:32
    RGuyser,
    A "standard" LCD is a device that basically "shows what you send it". That being said, there are several examples in these fora and on the Parallax site that illustrate how you can "encapsulate" common functions (common to your application, anyhow), such as clearing the LCD and positioning the cursor to a specific place, to make it easier to use the LCD.

    As for your question about an "OS", since the LCD generally doesn't have any higher function capacity, I'm going to assume that you mean some kind of menuing system. There are examples of this floating around, as well. If I'm way off about what you mean, I apologize...but OS and LCD are terms that don't generally go together.

    HTH

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Truly Understand the Fundamentals and the Path will be so much easier...

    Post Edited (Tom Walker) : 6/2/2006 1:38:11 PM GMT
  • RGuyserRGuyser Posts: 90
    edited 2006-06-02 23:46
    GUI then..

    I have dug through the parallax site extensively. i am not excessively lazy. i was just hoping someone might say "oh, ive got the perfect code - you put the subs down at the bottom of your program and callthem to clear\write\change lines...

    ive almost got this working now anyways... i know forpicbasic there are very nice LCD routines.. i was getting irritated with using the eeprom all the time. my application probably wouldnt ever exceed the eeprom write limit, but i am not positive. i dont know for sure, as it isnt detailed anywhere i have found how the eeprom writes. is each bit a write cycle? etc. tyhe questions were simplemr tom. let me ask again, so it is clear.

    1. CAN THE BS2 COMMUNICATE WITH A PARALLEL LCD WITHOUT USING THE EEPROM?

    2. IS THERE A USEFULL SET OF LIBRARIES SOMEWHERE TO MAKE IT MORE SEAMLESS?



    GUI, OS, INTERFACE, what have you... call a menu system what you want.
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2006-06-03 00:41
    [noparse][[/noparse] Maybe consider getting a serial adapter for your LCD jobs.· It costs less money to just use one in its native-state, but it costs you more in time, programming, program space, stuff like you're going on about. ]

    If you can prototype, then·get this IC-kit --
    http://www.phanderson.com/lcd106/lcd107.html

    or get a serial back-pack here --
    http://www.wulfden.org/k107/

    or get a Serial-LCD from PARALLAX --
    http://www.parallax.com/detail.asp?product_id=27976
  • HarborHarbor Posts: 73
    edited 2006-06-03 00:59
    rguyser said...

    1. CAN THE BS2 COMMUNICATE WITH A PARALLEL LCD WITHOUT USING THE EEPROM?

    2. IS THERE A USEFULL SET OF LIBRARIES SOMEWHERE TO MAKE IT MORE SEAMLESS?

    1. Yes. I'm not sure where you heard about using the EEPROM as a 'buffer'. It certainly is not a buffer in any hardware sense, so I assume the author of that comment meant it in the software sense. In that sense, you might well have other parts of the program generating information that must be displayed, but to simplify your code, you create an area of the EEPROM where all thos parts of your code store the text they want displayed. Then you use a common routine to move the text to the display, possibly doing things like scrolling the information if it won't fit on one screen.

    You can send information to the LCD by computing a value, changing it to character form and sending the characters immediately. That is practical only for small examples. So yes, it is possible to avoid the EEPROM, but generally not useful.

    2. Yes, but you're working at the hardware level here. So·when you choose an LCD, you are compelling yourself to recode the details of any such library unless you choose the library first and then buy the LCD that matches the existing code. In general, the changes are trivial and painless, like which pin is the clock and which the I/O data line, but they are essential.

    Look at Nuts and Volts articles 31 and 62 for examples of simplifying the LCD interface and the use of menus.
  • RGuyserRGuyser Posts: 90
    edited 2006-06-03 02:00
    harbor - thank you.

    i have been using this code from parallax http://www.parallax.com/dl/docs/prod/audiovis/lcd2x16par.pdf.

    it writes a phrase into the buffer at startup, and then reads it out bit by bit. i dont see why it has to be into the eeprom when it could be into a variable. however, i am (clearly) a neophyte and am not exactly sure how to a)convert alphanumeric phrase into the same format as the buffer does, b)read that phrase bit by bit into the lcd.

    the parallax supplied code has absolutely no commentary, and the nuts n voltz articles i could find were for a 4x20 LCD, and they still used the eeprom as a "buffer". i am the one calling it a buffer. it seems to me if you use it as temporary memory space before sending information to another location, that is a 'buffer'.

    it is ok. i am going to just do more homework. it is surprising to me that noone else has encountered this same exact question... i have designed a set of menus now that are all the same length, 32 characters, so i dont need to have code for changing lines or for detecting the length of a string to send... i was really hoping someone had written a 'debug' command emulator type thing to make using the parallel LCD simple..


    and yes, i know about the serial convertor chips and serial LCDs. I just have many projects. Adding 5-10$ per LCD for this specific project is not a good option. Especially when I dont need the extra IO lines.

    thanks for the help... also, harbor, in response to #2, i am under the impression that the hitachi-type(14 pin) 2x16 LCDs are pretty much basic, hence this reasonably sized paralax code probably works with dozens and dozens of different chipssets and devices.. ive use a few hitachi type LCDs, no 2 exactly the same, probably, and they almost always work with generic hitachi code ive found...


    except when i boil them.
  • RGuyserRGuyser Posts: 90
    edited 2006-06-03 02:04
    a last note: these $80 serial LCD displays from parallax seem absurdly priced. i use these little guys when a PC is either too expensive or to cumbersome...

    the thing is, a miniature 486 1-board computer can be found for roughly the same price. coding is far easier, its far faster, etc...

    i hope prices on the MCU stuff are forced down eventually. i would purchase far more of this stuff if it didnt seem priced at a 500% profit margin...

    this is why picbasic is so nice seeming.
  • ForrestForrest Posts: 1,341
    edited 2006-06-03 02:25
    >>a last note: these $80 serial LCD displays from parallax seem absurdly priced<<

    What $80 serial LCD display from Parallax are you referring to? This one is $29.95 www.parallax.com/detail.asp?product_id=27976 and the backlit version is $5 more. I think if you check the prices on serial LCD displays from other companies, you'll find the Parallax displays are much less expensive.
  • HarborHarbor Posts: 73
    edited 2006-06-03 02:39
    rguyser said...
    it writes a phrase into the buffer at startup, and then reads it out bit by bit. i dont see why it has to be into the eeprom when it could be into a variable. however, i am (clearly) a neophyte and am not exactly sure how to a)convert alphanumeric phrase into the same format as the buffer does, b)read that phrase bit by bit into the lcd.
    Sorry, I thought this part was more evident than it seems to be. You only have 32 bytes of RAM memory for variables and you have to use that for everything. So if you put your phrase to display into a byte array in the RAM, you wouldn't have room left to do anything else in your program. So that's why you put the information into the EEPROM. The 'buffer' is a good term for that, but the EEPROM isn't doing any conversion. The program code is doing that.·The code would achieve the same result if it were reading the character codes from RAM. You just don't have enough RAM in a Basic Stamp to waste that way.
  • RGuyserRGuyser Posts: 90
    edited 2006-06-03 05:14
    harbor.

    thank you for your logical and concise answer! now I understand why the eeprom is always used. but a question.. if i wanted to have 5 or 6 menus. each 32 characters, can i write a routine that loads them bit by bit in and out of an array or something, thereby avoiding the eeprom read\write time penalty, and the perishability of eeprom writes?


    another questions - has anyone seen PIC code to make a 18f84a or similar act as the parllel LCD to serial convertor?

    Also, when i use the write command to send data to the eeprom, does that count as 1 write, or does each bit count? should i attempt to limit how much i write in at a time, as well as how often i write?

    thanks!

    robert
  • HarborHarbor Posts: 73
    edited 2006-06-03 05:48
    Well, that was a pain in the neck. Just wrote an extended answer of a page or so, hit the wrong key and it disappeared. Not my favorite editor in this forum software. Will write one off line and post it in a while.
  • RGuyserRGuyser Posts: 90
    edited 2006-06-03 06:40
    a shame. i would certainly appreciate information... thanks!
  • HarborHarbor Posts: 73
    edited 2006-06-03 06:43
    rguyser said...
    if i wanted to have 5 or 6 menus. each 32 characters, can i write a routine that loads them bit by bit in and out of an array or something, thereby avoiding the eeprom read\write time penalty, and the perishability of eeprom writes?
    Loading the value into RAM from EEPROM won't speed the process of writing to the LCD. First,·the string·still has to start in the EEPROM, and second, we can fetch from EEPROM a lot faster than an LCD will accept the characters over a serial line. Now if we were preparing a transmission packet for a very high bandwidth device like a gigabit LAN, then we certainly would compose the packet in fast memory. Some Stamp models have "scratch-pad RAM" that·we can use for such applications.·Ones·where we want to compose the data and send it in a high-speed burst (though we wouldn't use a Basic Stamp as the direct controller for a gigabit LAN). But in this case, you shouldn't worry. The EEPROM is faster than the interface to your LCD so it isn't a bottleneck.

    rguyser said...
    Also, when i use the write command to send data to the eeprom, does that count as 1 write, or does each bit count? should i attempt to limit how much i write in at a time, as well as how often i write?
    That counts as one write for each address that receives data. The life of an EEPROM is determined by the individual cells. They wear out from the process used to change their state when writing, but it is not the write circuit that wears out, it is actually the bits at each address. So the write lifetime of the complete chip is determined by the number of times the most used address has been written. With a Basic Stamp, the first few cells would be the limiting factor in a Stamp used for development work, but even as much as we change our code, it would take a very long time to reach the chip life limit. In a production design, the most often written EEPROM variable will be the design limit, and of course some purposes could reach ten million writes (or whatever the current limit is) fairly soon. If you have an application like that, I can teach you some programming tricks to distribute the write load over a region of EEPROM instead of a few cells. But it is rare, and it won't happen with a display routine.

    For practical purposes, don't worry about it. The EEPROM in most applications will have a lifetime longer than your own. (Or than mine, at least.<g>) And chips are cheap. If you live long enough to need another one, a replacement will cost even less than they do right now. Guaranteed. So just use the EEPROM like memory, or like a disk to be more accurate, since we read and write to access the data.

Sign In or Register to comment.