Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

LCD module docs don't match canonical example #81

Closed
marcoscaceres opened this Issue Oct 16, 2012 · 24 comments

Comments

Projects
None yet
5 participants

(...mostly documentation related... sorry it's a bit of a ramble)

Trying to get the LED working with the hacktronics tutorial for the 4x4 Blue, the pins in the docs do not match what the tutorial is set to. It would be nice if they did.

I tried to get the board working with pins: [ 12, 10, 5, 4, 3, 2], but had no joy :( I'll keep playing till I get it going and post here once it's working. I confirmed the board was working correctly by running the sample code in the hacktronics tutorial. I also tested that the firmata was ok by turning on an LED when the LCD fires its on event.

An enhancement (in the docs) might be to allow the LCD pins to be set explicitly. I can see from debugging that there is a an object representing the pins: { rs: 12, en: 11, data: [ 3, 4, 5, 10 ] }.

Also, note that in the table of the hacktronics website (and on the board itself) there is no pin labelled "EN" (I assume that this is "E"?).

Also, it's not clear to me which pin controls the backlight? On my Arduino (and in the tutorial), that's set to pin 13. I can turn that on as an LED, but that seems like a bit of a hack.

Contributor

haugstrup commented Oct 16, 2012

I don't quite understand what it is you are having trouble with. I assume you are talking about the example at https://github.com/rwldrn/johnny-five/blob/master/docs/lcd.md ?

The LCD constructor for johnny-five isn't tied to any specific LCD module. It will work with any HD44780 type LCD. The hacktronics LCD you link to is just one of many such LCDs. The johnny-five documentation just uses different arduino pins for the example. If you hook up your arduino and LCD the same the breadboard is set up in the johnny-five documentation you should be good to go. The order of pins for the constructor is in the comment above: RS, EN, DB4, DB5, DB6, DB7 -- As the breadboard shows you can simply connect the RW pin to ground as it's not used.

In the johnny-five LCD example the contrast is not controlled by an Arduino pin since you don't usually need to adjust is programmatically. You can see a potentiometer on the left side of the breadboard. The potentiometer is connected to the LCD contrast pin (LCD pin 3) and this is what controls the contrast. Adjust the potentiometer to adjust contrast.

Does that help at all?

@haugstrup yes, sorry, that was the document I was referring to... I was thinking out loud and the bug was not very clear.

Yes, I am aware that it will work with any generic LCD module, but it would be nice to have a list of generic ones in the documentation (BTW, pins: [ 12, 10, 5, 4, 3, 2] does work for the hacktronics one :) ).

There might be a good reason to control the contrast with a potentiometer, but contrast is still part of the unit itself, so it' would be nice if it was controlled as part of the API (and I can then intercept the current to control it with a potentiometer if I so choose).

Contributor

haugstrup commented Oct 17, 2012

Just for kicks: What happens when you wire up your LCD exactly as it is in the johnny-five example?

I must admit I don't really see a need for adding the contrast and backlight pins to the LCD constructor. Hardly anyone will want to control them programmatically and those who do knows how to hook it up themselves and it would come at the cost of adding two more pins to the constructor. The Arduino LiquidCrystal library doesn't provide an interface for contrast and backlight either: http://www.arduino.cc/en/Reference/LiquidCrystal

Owner

rwaldron commented Oct 17, 2012

@haugstrup I'm not opposed to it, but I'd segregate them initially and if there was enough interest to use them, we could migrate them to the pins[] array...

{
  pins: [ ...Number ],
  contrast: Number,
  backlight: Number
}

?

On Wednesday, 17 October 2012 at 19:06, Andreas Haugstrup Pedersen wrote:

Just for kicks: What happens when you wire up your LCD exactly as it is in the johnny-five example?

Vomit on the LCD screen… and my indicator LCD pulsating like mad :)

I must admit I don't really see a need for adding the contrast and backlight pins to the LCD constructor. Hardly anyone will want to control them programmatically and those who do knows how to hook it up themselves and it would come at the cost of adding two more pins to the constructor.

That seems a bit strange ( also, there are no "costs", see below). Firstly, you can't read the LCD without turning on the backlight. Secondly, it's a standard part of the LCD display. Seems like a non-argument to say you should not be able to control something that you need to programmatically control regardless (I don't intend to power the backlight through a wall socket, but through the Arduino… which is controlled by johnny-five).

The Arduino LiquidCrystal library doesn't provide an interface for contrast and backlight either: http://www.arduino.cc/en/Reference/LiquidCrystal

With all due respect, that doesn't mean they are right. I'm just pointing out that I experienced difficulties getting started and it seems like something rather trivial to add (i.e., the API does not provide as good a user experience as it could, for a JS API).

Also, it does not mean adding more things to the constructor in a way that burdens developers: it could be an optional set of parameters. IMHO, what makes johnny-five a pleasure to work with is that it's not the cumbersome/processing Arduino APIs (not just a clone of them!). We should be aiming to do better to make sure more people can create new and innovating things by limiting the barriers of entry (and not debating what is in the Arduino core APIs … if those APIs were any good, we would not need johnny-five, right?).

Owner

rwaldron commented Oct 17, 2012

It's safe to say we all agree with this:

Also, it does not mean adding more things to the constructor in a way that burdens developers: it could be an optional set of parameters. IMHO, what makes johnny-five a pleasure to work with is that it's not the cumbersome/processing Arduino APIs (not just a clone of them!).

What do you think about my suggestion above?

@rwldrn I would personally find those additions really helpful.

Owner

rwaldron commented Oct 17, 2012

@haugstrup what do you think? (see above)

Contributor

rmurphey commented Oct 17, 2012

I'm +1 on a pull request to add brightness control to the API -- wasn't part of my focus at the time, but it would be a nice addition.

@rwldrn, FWIW, I would prefer to be able to specify the pins by name whenever possible.

Having to look up the pin positions is a cumbersome exercise and match them against the table you provided in the comments was a bit unnatural and error prone (see comment code below): In practice, I had to copy/paste the table from the comments in the docs, and then match the positions of items in the array to the position in the table in my own code comment (and make sure they lined up!).

In other words, seems bad to have the position of items in an array be significant. So my code ended up looking like this (i.e., I had to include the table into the actual code to be able to work with it ... and the comment table would have to stay there for ever for the code to be legible to other humans... that seems kinda bad):

...
// LCD pin name  RS  EN  DB4 DB5 DB6 DB7
// Arduino pin # 7    8   9   10  11  12
// My Arduino  # 12  10   5    4   3   2
pins: [ 12, 10, 5, 4, 3,  2],
... 

It would be more natural to just be able to copy and paste an object structure and replace the values:

{
 RS: 7, 
 EN: 8, 
 DB4: 9,
 DB5: 10, 
 DB6: 11,
 DB7: 12,
 A: 13
 ... 
}

or:

var pins = {}; 
pins.RS = 7
...

I know capitalisation sucks there (it's not a proposed solution), it's just to show you an example of what I mean.

Owner

rwaldron commented Oct 17, 2012

For the sake of providing the easiest possible paths, I think this makes a nice addition, not replacement. So from here it's a matter of detecting that pins is either an array or a plain object and assigning the values in the constructor accordingly.

Patch Welcome!

Contributor

haugstrup commented Oct 17, 2012

I'm with marco in that I prefer to pass an object literal rather than an array for constructors that have more than say... 2 pins. Would be nice to work out such a patch.

I'm not opposed to adding contrast/backlight, but I still don't really see the need (just more stuff to maintain instead of building new constructors...). In my mind contrast is a manual adjustment. I.e. you need someone to stand and look at the display until you find the right value. It's not a good candidate for automation since you have to manually look at it anyway. As for backlight I see that it would be always on for the vast majority of cases.

That's a really long way of saying: If implemented as optional parameters I wouldn't cry, but I don't see a need. :)

Contributor

rmurphey commented Oct 17, 2012

I can envision a case where you might adjust the contrast via up/down buttons though, in which case you would want an interface other than a manual potentiometer.

Not sure if I will have enough time to do it (I'm just starting to learn what is under the hood of johnny-five), but here is a little initial research.

All 16 pins are as labelled as follows on my LCD board:

  1. VSS
  2. VDD
  3. VO
  4. RS
  5. RW
  6. E
  7. DB0
  8. DB1
  9. DB2
  10. DB3
  11. DB4
  12. DB5
  13. DB6
  14. DB6
  15. A
  16. K

(Do these labels match other LCD boards?)

I can see that in other code files in the project there is already a convention for the names of pins. Ideally, the ones I have provided can just be used in lowercase form (with substitution with already established conventions in johnny-five).

@rmurphey good point. That's a nice separation as you then you would not need to wire the buttons and the LCD display into each other.

Contributor

haugstrup commented Oct 17, 2012

@marcoscaceres All HD44780 LCD displays are the same by definition. If you buy a character LCD with 16 pins you can be 99.999% certain it's an HD44780.

These two PDFs contains an excellent description of these types of displays. It's what I read to make the LCD constructor with @rmurphey and @rwldrn

@rmurphey thanks for the links and confirmation!

Contributor

tdd commented Sep 9, 2013

Hey, sorry to barge in when this thing's been as-is for 11 months (although it's still open!)

Just wanted to say that my own LCD (16-pin and working with the basic Johnny-Five example, the I heart Johnny-Five one) has mega trouble dealing with special characters from LCD.Characters. Almost all calls to createChar (either directly or through useChar) throw a RangeError : Maximum Memory Limit or something…

I use this LCD which is based on a Tinsharp display and Sitronix ST7066U controller.

What I don't get is the basic heart character creation in the example I mentioned works reliably, but other characters (e.g. the running man, but also those enumerated in another example) reliably throw.

Any idea?!

Owner

rwaldron commented Sep 9, 2013

I've had trouble as well, but not a lot of time to work on it :(

Contributor

tdd commented Sep 9, 2013

Hey Rick,

Well if you had trouble that sorta comforts me 😉

I'll def try and work on this this Fall, if nothing's done in the meantime. Would be a nice dip-your-toe-in-the-water before trying to figure out ConfigurableFirmata and its feature classes to bring IRQs to Johnny-Five 😄

Owner

rwaldron commented Sep 9, 2013

@tdd I just nailed it down, patch coming.

Contributor

tdd commented Sep 9, 2013

Wh00t! 👍 ✌️ 👏 well done you! Do link the commit from here so I can dive into it. Interested to see what gave and how you went about it.

Owner

rwaldron commented Sep 9, 2013

@tdd I'm publishing v0.7.3 right now with the LCD improvements. Please test it out :) Any issues you come across, let's file new bugs.

@rwaldron rwaldron closed this Sep 9, 2013

Contributor

tdd commented Sep 10, 2013

Hey Rick,

Saw it. Will look into it and test it out ASAP (likely tomorrow).

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment