LeafLabs Garden » Topic: Problem with WH1604B and LiquidCrystal

LeafLabs Garden » Topic: Problem with WH1604B and LiquidCrystal http://forums.leaflabs.com/topic.php?id=1023 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:18:24 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php suso-mc on "Problem with WH1604B and LiquidCrystal" http://forums.leaflabs.com/topic.php?id=1023#post-11790 Tue, 17 Jul 2012 14:54:33 +0000 suso-mc 11790@http://forums.leaflabs.com/ Is there a LiquidCrystal Library version supporting serial port communication (UART)? crenn on "Problem with WH1604B and LiquidCrystal" http://forums.leaflabs.com/topic.php?id=1023#post-6293 Sat, 10 Sep 2011 19:00:51 +0000 crenn 6293@http://forums.leaflabs.com/ I haven't seen any, but there could be. There could be a lot of variations that we don't know of, however, at this present stage, we haven't had a request for anything more than 4 lines. Does the Arduino Liquid Crystal Library cater for larger screens? gbulmer on "Problem with WH1604B and LiquidCrystal" http://forums.leaflabs.com/topic.php?id=1023#post-6286 Sat, 10 Sep 2011 12:08:24 +0000 gbulmer 6286@http://forums.leaflabs.com/ crenn - Are you saying all (practical) LCD controllers only need 3 numbers: line 0 offset, line 1 offset and cols? Are there no 8 line LCD controllers in the same family of devices? crenn on "Problem with WH1604B and LiquidCrystal" http://forums.leaflabs.com/topic.php?id=1023#post-6281 Fri, 09 Sep 2011 19:11:41 +0000 crenn 6281@http://forums.leaflabs.com/ The values currently passed to the library through begin are enough to be used for the offsets. Either chip uses Line 1- offset 0x00 or 0 in base 10, Line 2- offset 0x40 or 64 in base then. When you change have the 16 character wide variation, you get Line 3- offset 0x10 or 16 in base 10, Line 4- offset 0x50 or 80 in base 10. If you have the 20 character wide variation, you get Line 3- offset 0x14 or 20 in base 10, Line 4- offset 0x54 or 84 in base 10. Currently it's a minor bug in the library which doesn't involve a major redesign of it, it's an easy fix. I'd suggest having the offset data moved as a private data member of the class, and at when begin is called, it sets up the offset: offset[0]=0x00; offset[1]=0x40; offset[2]=offset[0]+cols; offset[3]=offset[1]+cols; That should fix the bug which minimal changes. gbulmer on "Problem with WH1604B and LiquidCrystal" http://forums.leaflabs.com/topic.php?id=1023#post-6263 Fri, 09 Sep 2011 11:32:35 +0000 gbulmer 6263@http://forums.leaflabs.com/ robodude666 - I absolutely agree that there should be meanignful names for the default values provided by the library. What did I write to cause you to think that? I wasn't suggest anything as opaque as: <pre><code>uint8 row_offsets[] = { 0x00, 0x40, 0x10, 0x50 }; // What does this mean??? lcd.begin(&row_offsets, 20, 2);</code></pre> IMHO, that is tasteless and unhelpful. <blockquote>is extremely confusing to anyone who doesn't know that those are the beginning address of each row. A user may attempt to change them, and will wonder why the LCD stopped working as expected. </blockquote> If they understand so little, why would they NOT use a definition provided by the library? I was thinking along the lines of: <code>uint16 LCD_WH1604B_ROWS[] = { 0x00, 0x40, 0x10, 0x50 };</code> which could be syntactically identical to your proposal, or even <code>uint16 LCD_20x4_WH1604B_ROWS[] = { 0x00, 0x40, 0x10, 0x50 };</code> to make it more explicit. I'd consider: <pre><code>struct _LCD_DEVICE_ { uint8 width; // number of columns uint8 height; // number of rows uint16 row_offsets[0]; // row offset values }; typedef struct _LCD_DEVICE_ LCD_DEVICE; LCD_DEVICE LCD_20x4 = { 20, 4, { 0x00, 0x40, 0x10, 0x50 }};</code></pre> So that it is all wrapped up behind one name. <blockquote>At least half of the Arduino community doesn't know how to read a datasheet to extract the required offset values </blockquote> So in your estimation, almost half of Arduino community could find the necessary information, and hence code up something to use an LCD all by themselves if the API gives them that facility? Excellent. I am all in favour of making it easy for people to reuse code beyond its original (tested) intent by providing open solutions. <blockquote>it would only create the circulation of 3 sets of boiler-plate code that will be copy+pasted. </blockquote> No. That would only be true if we didn't provide definitions for the default cases, which is NOT what I propose. I think we should provide definitions for the hardware we can test. The code used for the supported cases would be syntactically identical. Of course, the user would have to write code for a case not supported, but they have the option to do that if they need to. <blockquote>other derivatives exist but they're only clones which feature the same instruction set </blockquote> So, how does someone figure out which clone their LCD uses? How do they define the properties so that the library works, and so that the parameter to <code>begin</code> is correct? On a slightly different tack, if they are all the same controller anyway, and it is only the size and row offsets which vary, why should we make the name of the controller matter at all? robodude666 on "Problem with WH1604B and LiquidCrystal" http://forums.leaflabs.com/topic.php?id=1023#post-6258 Fri, 09 Sep 2011 10:45:35 +0000 robodude666 6258@http://forums.leaflabs.com/ These LCDs feature an included table of 256 character table, and all commands sent to the LCD are 8-bit (the LCD can be used in 4-bit or 8-bit parallel mode). These are three of the most popular controllers on the market, other derivatives exist but they're only clones which feature the same instruction set. I haven't heard of any variants that feature an extended character table, though some may exist. It can be left as a 16-bit value, it doesn't really matter - it's only 4 out of 20 thousand bytes of ram. I'm against the need for a person to pass in an array of GRAM addresses into a wirish class. The point of the wirish class is to simplify the use of peripherals and devices. At least half of the Arduino community doesn't know how to read a datasheet to extract the required offset values, and it would only create the circulation of 3 sets of boiler-plate code that will be copy+pasted. Instead we could have a simple begin statement such as: <code>lcd.begin(LC_HD44780U_CONTROLLLER, 20, 2);</code> which will configure the library to support a 20x2 LCD that uses the HD44780U's GRAM addresses. This features no "magic numbers" that get passed in. It's very clear that the LCD is using a HD44780U controller. Where as something like: <pre><code>uint8 row_offsets[] = { 0x00, 0x40, 0x10, 0x50 }; // What does this mean??? lcd.begin(&row_offsets, 20, 2);</code></pre> is extremely confusing to anyone who doesn't know that those are the beginning address of each row. A user may attempt to change them, and will wonder why the LCD stopped working as expected. While I understand the need to decouple the library from specific controllers, it would only end up making the public APIs more confusing to use for beginners. If we want to make everyone happy, the LiquidCrystal library can have a private member that holds the offset values. The begin method will accept either a controller's name or a special "NONE" value. If a known controller is passed in, the member will be populated with the corresponding values for that controller/row/col configuration. If a special "NONE" value is passed, the user has the right to update the offset array using a setter method. This will allow easy use for common LCDs, and if a less common controller is used, the library can still be used once the user gets the correct offset address from the datasheet. -robodude666 gbulmer on "Problem with WH1604B and LiquidCrystal" http://forums.leaflabs.com/topic.php?id=1023#post-6255 Fri, 09 Sep 2011 10:30:48 +0000 gbulmer 6255@http://forums.leaflabs.com/ robodude666 <blockquote>All commands sent to the LCD will be 8-bit, so there's no reason to dedicate a 16-bit int; it's just a waste of 4 bytes of ram.</blockquote> I am not talking about the commands in general, just the row-offset values. I realise that this controller takes 8-bit commands, but I don't see a need to make that a feature of the public LCD API, and hence how the row offsets are defined, unless you are saying *ALL* LCD controllers which map onto the existing LCD library API have less than 256 character displays. It only takes one which needs an offset bigger than 255 to break that assumption, and hence break the API. <blockquote>I think it would be wise to include ALL of the possible row_offsets array in the Library. </blockquote> I am a big fan of KISS. I am not a fan of pushing changes which are not tested. Let's fix what is broken, and can be tested, and wait to see what else is needed? We could modify <code>begin</code> to take a row-offset map along the lines suggested by Xavier. We could change <code>begin</code> so that a row offset map is a required parameter, and have no default. We could provide a row offset map for the two LCDs being used, and hence they can be tested before the changes are pushed. A tiny amount of documentation to explain how to set up for a different LCD would be enough to support all other LCDs which would otherwise work with the existing library. Of course, if you are volunteering to test "ALL of the possible row_offsets array" combinations on real hardware, then that is fabulous. Do you posses an example of them all? robodude666 on "Problem with WH1604B and LiquidCrystal" http://forums.leaflabs.com/topic.php?id=1023#post-6252 Fri, 09 Sep 2011 10:09:59 +0000 robodude666 6252@http://forums.leaflabs.com/ All commands sent to the LCD will be 8-bit, so there's no reason to dedicate a 16-bit int; it's just a waste of 4 bytes of ram. However... There's nothing wrong with the library. There are dozens of these kinds of LCDs on the market. They all look identical, and their controllers are extremely similar but they all have slight variations to the address mapping based on the configuration of the LCD. The LiquidCrystal library included with libmaple is configured for a 20x2 or 20x4 LCD, for example the <a href="http://www.sparkfun.com/datasheets/LCD/GDM2004D.pdf">GDM2004D</a> (see page 8 of 9). The other common LCD used is the <a href="http://www.serialwombat.com/parts/hd44780.pdf">HD44780U</a>. The controller used by the <a href="http://www.winstar.com.tw/UserFiles/ProductImages/125231465401825465505.jpg">WH1604B</a> in the OP's post is the <a href="http://www.asix.cz/download/pvk40/ks0066u.pdf">KS0066</a>. As you can see, the GRAM addresses for the last two rows are slightly different between the GDM2004D and the WG1604B's KS0066 controllers. Each LCD configuration (16x2, 16x4, 20x2, 20x4) will have slightly different GRAM address mapping. Because of this, I think it would be wise to include ALL of the possible row_offsets array in the Library, and require a value to be passed to the LiquidCrystal library that states what LCD is being used so that the correct offsets are selected. -robodude666 gbulmer on "Problem with WH1604B and LiquidCrystal" http://forums.leaflabs.com/topic.php?id=1023#post-6246 Fri, 09 Sep 2011 09:23:37 +0000 gbulmer 6246@http://forums.leaflabs.com/ Xavier - I was pondering having an <code>initialiseRowOffsets</code> function, but maybe initialising at <code>begin</code> is better. Are those LCD's less than 256 characters? In that case, the row-offsets could be: <code>uint8 row_offsets[] = { 0x00, 0x40, 0x10, 0x50 };</code> which would make for less initialisation. Xavier on "Problem with WH1604B and LiquidCrystal" http://forums.leaflabs.com/topic.php?id=1023#post-6245 Fri, 09 Sep 2011 06:15:05 +0000 Xavier 6245@http://forums.leaflabs.com/ It works fine as it is for 20x4 LCDs. So maybe row_offsets shoud be initialized in the lcd.begin(...) function... Xavier gbulmer on "Problem with WH1604B and LiquidCrystal" http://forums.leaflabs.com/topic.php?id=1023#post-6244 Fri, 09 Sep 2011 05:46:42 +0000 gbulmer 6244@http://forums.leaflabs.com/ Roma - Cool! Your reply will help future user too. (PS - I took the liberty of adding backticks to pretty print your code, I hope that's okay) Roma on "Problem with WH1604B and LiquidCrystal" http://forums.leaflabs.com/topic.php?id=1023#post-6243 Fri, 09 Sep 2011 04:04:31 +0000 Roma 6243@http://forums.leaflabs.com/ I found the problem. in LiquidCrystal.cpp this is correct addresses for 4-lines LCD int row_offsets[] = { 0x00, 0x40, 0x10, 0x50 }; accoding Datasheet <pre><code>void LiquidCrystal::setCursor(uint8 col, uint8 row) { // int row_offsets[] = { 0x00, 0x40, 0x14, 0x54 }; THIS IS NOT CORRECT int row_offsets[] = { 0x00, 0x40, 0x10, 0x50 }; if ( row > _numlines ) { row = _numlines-1; // we count rows starting w/0 } command(LCD_SETDDRAMADDR | (col + row_offsets[row])); }</code></pre> Roma on "Problem with WH1604B and LiquidCrystal" http://forums.leaflabs.com/topic.php?id=1023#post-6238 Fri, 09 Sep 2011 00:49:15 +0000 Roma 6238@http://forums.leaflabs.com/ result the same as above gbulmer on "Problem with WH1604B and LiquidCrystal" http://forums.leaflabs.com/topic.php?id=1023#post-6231 Thu, 08 Sep 2011 20:12:14 +0000 gbulmer 6231@http://forums.leaflabs.com/ Have you tried any other tests? It is helpful to try a few tests to gather more evidence. For example, do you get the same result if you do: <pre><code>lcd.setCursor(0,3); lcd.print("Line4"); lcd.setCursor(0,2); lcd.print("Line3"); lcd.setCursor(0,1); lcd.print("Line2"); lcd.setCursor(0,0); lcd.print("Line1");</code></pre> or <pre><code>lcd.setCursor(0,0); lcd.print("L"); lcd.print("i"); lcd.print("n"); lcd.print("e"); lcd.print("1"); lcd.setCursor(0,1); lcd.print("L"); lcd.print("i"); lcd.print("n"); lcd.print("e"); lcd.print("2"); lcd.setCursor(0,2);lcd.print("L"); lcd.print("i"); lcd.print("n"); lcd.print("e"); lcd.print("3"); lcd.setCursor(0,3); lcd.print("L"); lcd.print("i"); lcd.print("n"); lcd.print("e"); lcd.print("4");</code></pre> Roma on "Problem with WH1604B and LiquidCrystal" http://forums.leaflabs.com/topic.php?id=1023#post-6226 Thu, 08 Sep 2011 13:16:33 +0000 Roma 6226@http://forums.leaflabs.com/ I was try to use LiquidCrystal and WH1604B (16x4) with Maple Rev 5 This is my code: #include <LiquidCrystal.h> LiquidCrystal lcd(5,6,2,3,9,11); void setup() { lcd.begin(16,4); lcd.clear(); lcd.leftToRight(); lcd.home(); lcd.setCursor(0,0); lcd.print("Line1"); lcd.setCursor(0,1); lcd.print("Line2"); lcd.setCursor(0,2); lcd.print("Line3"); lcd.setCursor(0,3); lcd.print("Line4"); } void loop() {} and result not good <a href="http://meteo.pajero4x4.ru/wp-content/uploads/2011/09/08092011222.jpg" rel="nofollow">http://meteo.pajero4x4.ru/wp-content/uploads/2011/09/08092011222.jpg</a> Why