Allow to couple/uncouple CE pin

[jjtmp]

No description provided.

[platisd]

Hi Jonas, thanks for your contribution.

Can you explain how would the new functions would be used in practice with a bare minimum example?

[platisd]

Is couple(false) the same as uncouple?
If so, then let's keep only one.

[platisd]

Consistent styling:

Suggested change

	if (!coupled)
	digitalWrite(kCe_pin, LOW);
	if (!coupled) {
	digitalWrite(kCe_pin, LOW);
	}

[platisd]

Hmm, couldn't this be changed to something simpler, i.e.:

Suggested change

	if (yes && !coupled) {
	digitalWrite(kCe_pin, LOW);
	}
	else if (!yes && coupled) {
	digitalWrite(kCe_pin, HIGH);
	}
	coupled = yes;
	digitalWrite(kCe_pin, yes ? LOW : HIGH);
	coupled = yes;

[platisd]

Consistent styling:

Suggested change

	if (!coupled)
	digitalWrite(kCe_pin, HIGH);
	if (!coupled) {
	digitalWrite(kCe_pin, HIGH);
	}

[platisd]

The claims are that using these two new functions:

1. Improve speed
2. Allow accessing more than 1 display on the same pins

I can understand the 2nd point, but can you elaborate more on the 1st?

[jjtmp]

Two answer all your remarks and maybe more:

1. Why this proposal

I was experimenting with two displays. But they constantly resisted to work as expected. I suspect electrical interference between the CE lines. Another advantage is that the contrast setting menu can be shown on all displays the same time so if your application misconfigured one LCD but shows the contrast setting menu on the other LCD too you still can read what's going on.

2. How-to use

The key of couple() is to stop the send() method from modifying the CE pin. Obviously you have to manage it by yourself then.

The bonus of couple() is that you can switch from one display to another without changing all these lcd.print() invocations in main and subroutines. I use this - but to be frank it would be more clear to wrap a digitalWrite such as activate_lcd1() {digitalWrite(CEofLCD1, LOW);} - I probably will switch to this soon for sake of clarity.

3. Examples

See
a) Full http://z-info.jbechtel.de/srv/23kopierer_savev179web.ino
b) Reduced http://z-info.jbechtel.de/srv/23kopierer_web_short.ino
c) Mini http://z-info.jbechtel.de/srv/23kopierer_web_veryshort.ino

The a) example is an actually working one. But it contains lots of code which you don't need for LCD (and also lots of dead code).
The b) example is untested. I just took the a) example and removed everything which is not contrast setup menu/counter printer.
The c) example is pretty minimal, just has the initialization phase of b) example. Also untested.

Please don't mind the "lcd.uncouple()" in all a)b)c) examples initialization. It is wrong and most probably should be just removed.
Also please don't mind that it is not neccessary to instantiate lcdL and lcdR objects. lcd object is just enough. All lcdL and lcdR tasks could be surrounded by activate_lcd1() like wrappers (see above 2.).

4. Improve speed

It was just my feeling that on Arduino the PIN access is pretty slow, compared to directly coding for ATMega. Web search engine results support this. (digitalWrite() seems to switch off PWM first, etc.). So omitting digitalWrite(), even just the surrounding one for CE, helps a bit. Of course one could be pretty much faster when not-at-all using digitalWrite() but reducint calls is not so bad, either.

I have incorporated most of your suggestions and expanded the documentation comment in Nokia_LCD.h. Is it better than before?

[platisd]

I think we are getting somewhere :)

[platisd]

Sounds a bit farfetched but I haven't tried it so I guess you have a point.
However, it feels like not only the electrical engineering aspects are outside the scope of this library, but -more importantly- this isn't some information we should include in the API documentation.

[platisd]

I think I understand this one, but does it need to be in the API documentation?

[platisd]

While there are 10% less instructions that doesn't necessarily mean it's 10% faster, especially since branches have been introduced to the code.
Regardless, any performance claim should be backed up by data and I'd argue that even if there is a 10% performance boost, it isn't worth mentioning in the API. :)

[jjtmp]

It is right that the performance claim isn't from measurements and that the interface description is better brief than possibly wrong. One could argue how much access to inner variables should be possible, but of course it's not unacceptable to make access private.
I committed your suggestions.

[platisd]

👍 🎉

[jjtmp]

👍 Thank you! Makes exchange of the .ino file easier between my build pipeline (Makefile) and the project initiators build pipeline (Arduino IDE) without any explanation.
As soon as I have access to the hardware again I will check about the electrical interference topic, just to be sure.

[jjtmp]

As signalized I have checked the "electrical interference" issue. Maybe it isn't related to electrical interference, at least I couldn't reproduce this. It's probably just a question of reset pins. The begin() method does set reset pin to low (and high) and then writes makes necessary initialization bytes. So there are following variants to share pins of two LCDs:

• [hardware] either use distinct RST pins
• [software] or set RST pin to the same value as CE pin in instantiation of LCD object (for those later LCD for which you call begin() after you called it for the first LCD)

Nokia_LCD lcd10(13, 12, 11, 10, 9);
Nokia_LCD lcd7(13, 12, 11, 7, 7); // reset pin "7" = trick the constructor
lcd10.begin()
lcd7.begin()

• [software] or use couple(). the couple() must be called for all LCDs. It is not necessary for the LCD you call begin() on. Example:

Nokia_LCD lcd10(13, 12, 11, 10, 9);
Nokia_LCD lcd7(13, 12, 11, 7, 9); // reset pin irrelevant, never touched
lcd7.couple(); // new since version NokiaLCD 2.7.0
lcd10.begin();
lcd7.uncouple();

So now I'm done with that story.

[platisd]

Thanks for the follow-up @jjtmp 💯