LCD module docs don't match canonical example about johnny-five HOT 24 CLOSED

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?

from johnny-five.

@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).

from johnny-five.

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

from johnny-five.

@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
}

?

from johnny-five.

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?).

from johnny-five.

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?

from johnny-five.

@rwldrn I would personally find those additions really helpful.

from johnny-five.

@haugstrup what do you think? (see above)

from johnny-five.

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.

from johnny-five.

@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.

from johnny-five.

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!

from johnny-five.

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. :)

from johnny-five.

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.

from johnny-five.

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).

from 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.

from johnny-five.

@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

• http://lcd-linux.sourceforge.net/pdfdocs/lcd1.pdf
• http://lcd-linux.sourceforge.net/pdfdocs/lcd2.pdf

from johnny-five.

@rmurphey thanks for the links and confirmation!

from johnny-five.

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?!

from johnny-five.

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

from johnny-five.

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 😄

from johnny-five.

@tdd I just nailed it down, patch coming.

from johnny-five.

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.

from johnny-five.

@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.

from johnny-five.

Hey Rick,

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

Thanks!

from johnny-five.