Hi all,
I am new to Arduino programming. I was using Arduino to count the frequency of a pulse signal and then display it in a LCD module (LCD 1602A) following this link [https://circuitdigest.com/microcontroller-projects/arduino-frequency-counter-circuit.] Now it was working fine until the 5 V power to the Vdd pin of the LCD got disconnected by mistake. After that it is not working any more. I did some reading in this forum and understood from various posts that it is a nibble sync issue. For example, here [quote="bperrybap, post:14, topic:1119892"]
The only way to get back into nibble sync is to either power cycle the LCD and re-initalize the LCD, or have the host go back through the 4 bit initialization sequence.
The 4 bit initialization sequence puts the LCD into 8 bit mode regardless of what mode or state the LCD is in, and then it puts the LCD into 4 bit mode.
[/quote]
But I failed to get a clear idea of what I need to do. I mean what code I need to run to reset the LCD module? I am sure the solution is out there. So I will really appreciate if someone can direct me to the correct link. I have gone through these links but could not figure out exactly what I need to do.
I will take a SWAG: Close the IDE, power down, be sure everything is connected properly, start the IDE, power up and it should be working. If that 5V wire touched something else it could have damaged other parts of your system.
Not sure what you mean by "take a SWAG: Clower the IDE". I closed the IDE. Disconnected Arduino from the laptop. And then connected it back. Uploaded the code again. But it is not working. I think I need to run a initialization sequence as given here LCD_initialization. But can not figure out how. Thanks for your reply.
The display doesn't remember any commands/states over power cycles. It comes up in the same state each time. So if you display was working, and now it's not, it's not because of some command sequence you sent it before. If the 5V wire perhaps touched something else when it became disconnected, you may have fried something.
When you apply power to the Arduino and it's attached LCD the normal startup procedure occurs. Simply stated the LCD controller runs it's inherent startup procedure which sets it up for a (rare) 1-line display. The Arduino code then does the LCD initialization mentioned in the initial post and then sets it up as required.
When you subsequently remove and replace the power to just the LCD module it again runs it's own inherent startup procedure BUT the Arduino does not get the opportunity to set the LCD up the way it should be.
Therefore "the command sequence you sent it before", the sequence provided by the Arduino, is missing.
Examples using the LCD Initialization sequence mentioned in post #3 are shown at the links provided on the LCD Programming Examples page at the same site.
NOTE: I am the author of those pages. The email link shown there is obsolete, I retired a while ago.
Don,
It seems that what @van_der_decken meant was that the LCD doesn't remember any host commands sent to the LCD or prior state after a power cycle.
The LCD comes up in the exact same state each time it is powered up regardless of what the host sent to the LCD prior to the power cycle and regardless of what state it was in prior to being powered off.
So for clarification to @sambh the quote from me about nibble state, is referring to trying to restore the host (Arduino) and LCD communication without power cycling the LCD and system and without resetting the Arduino.
The LCD initialization sequence @sambh linked to is showing the state the LCD is in upon powering up and then shows the recommend initialization by instruction sequences used by the host (Arduino) to restore communication for both 8 bit and 4 bit interfaces.
My quote was saying the only way to restore host communication when when nibble sync has been lost without power cycling is for the host (Arduino) to perform the appropriate initialize by instruction sequence.
The LCD does not remember any sort of initialization or nibble synchronization state after a power cycle.
And even it did, the LCD library being used should restore the LCD to the proper state as part of its LCD initialization. i.e. lcd.begin(...) should get the LCD working again, as long as the h/w, wiring, and power are all still working and properly connected.
By power cycling everything, the LCD will reset to a known state and then the LCD library should re-initalize everything back to 4 bit mode so the host can communicate with the LCD.
Also resetting the Arduino (without a power cycle), the LCD library should re-initalize everything back to 4 bit mode so the host can communicate with the LCD regardless of what state the LCD is in.
So the question now becomes, what happened that caused the project to no longer work?
Did the removal of the power signal damage something or is there some sort of miswiring?
Have you a non-blocking version of the LCD1602 etc. library ? It is not critical that the init() / setup is non-blocking. Important only is that in normal use it does not block. I'm going to re-engineer an audio application and its buffers can underflow if there is a long wait, for example a clear screen on the LCD. I may do one myself if I can't find anything that easily fits.
This is going off topic but I'll briefly answer this with respect to the hd44780 library.
I'd recommend that for a more detailed discussion on this start a new thread, or PM me if you want more details on the hd44780 library inner workings.
The hd44780 library blocks for the initialization during begin()
After initialization, it will only block if there is an attempt to send an instruction to the LCD before the previous one is finished.
i.e. library sends an instruction to the LCD and the Arduino can run in parallel while the LCD is processing an instruction.
There are some other things that might not work for your timing and/or jitter requirements, like the Print class blocking until all characters are sent to the output device, and the overhead to get the instructions to the LCD, say in the use of a I2C backpack.
This seems to work. Although I am not fully sure if this was exactly the solution because I was randomly uploading codes which contained several commands like lcd.clear (), lcd.init(1,8,255,9,4,5,6,7,0,0,0,0); and lcd.home(). Something must have worked. Anyway thanks for your detailed explanation.