Trevinlc1997
Posts: 13
Joined: Mon Nov 28, 2016 11:44 pm

Reading busy flag on LCD

Sun Nov 26, 2017 2:36 am

I am creating my own C++ library for the LCD display, because I noticed everything is for the arduino.

Anyways I came across something I just can't seem to read the busy flag correctly. Here is what I am currently doing

i2c IO expander is setup like this (in binary format)
B7 B6 B5 B4 BL EN RW RS

Steps:
Initialization steps for my specific LCD.
Write char to screen.
Flash enable pin.
Writing 0x00 data with EN and RW high;
Reading 1 byte.

The byte that I read ends up being the lower half of the character I am trying to output, and EN / RW high. (I checked by reading multiple times but B7 never goes high (High because its in busy state) so obviously I am doing something wrong considering if I continue without waiting my LCD spits out garbage data)

If you could give me the basic run down on the abstract steps you should do to read the busy flag effectively I would really appreciate it.

User avatar
DougieLawson
Posts: 39796
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Reading busy flag on LCD

Sun Nov 26, 2017 8:00 am

Most of us pull the R/W pin permanently low and don't both reading for busy.

You simply send a command, wait for a short delay to allow the LCD to process it, then send the next command.

Read the code at: https://github.com/adafruit/Adafruit_Py ... CharLCD.py
and you'll see where they have a delay to allow the LCD to complete processing.
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

Criticising any questions is banned on this forum.

Any DMs sent on Twitter will be answered next month.
All fake doctors are on my foes list.

User avatar
FTrevorGowen
Forum Moderator
Forum Moderator
Posts: 5800
Joined: Mon Mar 04, 2013 6:12 pm
Location: Bristol, U.K.
Contact: Website

Re: Reading busy flag on LCD

Tue Nov 28, 2017 9:04 pm

DougieLawson wrote: Most of us pull the R/W pin permanently low and don't both reading for busy.
You simply send a command, wait for a short delay to allow the LCD to process it, then send the next command.
Read the code at: https://github.com/adafruit/Adafruit_Py ... CharLCD.py
and you'll see where they have a delay to allow the LCD to complete processing.
+1, and, FWIW, I've documented the typical strobe pulse lengths and delays (command completion wait times) I've found either "documented" or by "trial & error", for various circuit configurations here:
http://www.cpmspectrepi.uk/raspberry_pi ... gData.html
Trev.
Still running Raspbian Jessie or Stretch on some older Pi's (an A, B1, 2xB2, B+, P2B, 3xP0, P0W, 2xP3A+, P3B+, P3B, B+, and a A+) but Buster on the P4B's. See: https://www.cpmspectrepi.uk/raspberry_pi/raspiidx.htm

julyjim
Posts: 117
Joined: Tue Jan 31, 2017 5:04 am

Re: Reading busy flag on LCD

Tue Apr 17, 2018 5:18 pm

Geez, ask a straight and very valid question and get "don't do that" as reply.
Really?

It seems common approach to fudge delays by trial and error instead of following HD44780
datasheets.

RTFM - if you do not check BF it takes LONGER to access the LCD for whatever purpose.

Setting up to 4 bit mode steps won't complete until a delay is introduced.
The question is where?
It would make more sense if I check the BF instead of trying to find WHERE I need the delay.

Does anybody care to really discuss this ?

PS Using Linux ioctl to control I2C interface - so I REALLY want this BF checking to work.

User avatar
FTrevorGowen
Forum Moderator
Forum Moderator
Posts: 5800
Joined: Mon Mar 04, 2013 6:12 pm
Location: Bristol, U.K.
Contact: Website

Re: Reading busy flag on LCD

Tue Apr 17, 2018 7:07 pm

julyjim wrote:
Tue Apr 17, 2018 5:18 pm
Geez, ask a straight and very valid question and get "don't do that" as reply.
Really?
It seems common approach to fudge delays by trial and error instead of following HD44780
datasheets.
RTFM - if you do not check BF it takes LONGER to access the LCD for whatever purpose.
Setting up to 4 bit mode steps won't complete until a delay is introduced.
The question is where?
It would make more sense if I check the BF instead of trying to find WHERE I need the delay.
Does anybody care to really discuss this ?
PS Using Linux ioctl to control I2C interface - so I REALLY want this BF checking to work.
W.r.t. "if you do not check BF it takes LONGER to access the LCD for whatever purpose": since you're using an I2C device to convert from serial to parallel (what I2C device?) you've already "slowed things down" quite a bit compared to direct GPIO usage (4-bit or 8-bit) - have you looked properly at the observed/inferred timings here:
http://www.cpmspectrepi.uk/raspberry_pi ... gData.html ? The longest "wait for the command to complete" delay is well-documented in the HD44780 datasheet and is only needed for the command(s) that require that delay - easily handled in software. To be able to read the BF you have to switch (part of) your I2C device into read mode (and, later, back into write mode) in "synch" with your R/¬W control - whilst that's very simple with a micro-controller can be some what trickier with GPIO's (ie. timing issues). Using the device as "write-only" simplifies the connecting hardware and, to some extent, the code. The only real loss is that you are not able to recover the written data from the LCD's ram. Not a problem for a Pi - it has plenty of buffer storage space to "remember it" in (could be an issue for a micro-controller with limited storage though). It's a case of "horses (methods) for courses". NB: My timings were inferred from datasheet info., potential I2C or SPI "blocking"** where it applies and observed behaviour of device samples, some of which used HD44780 "compatible" controllers. W.r.t. "Setting up to 4 bit mode" "delay" - that's a "one-time only" initialisation process (unless you accidentally reset back to 8-bit). It's also why it appears as a "stand-alone" option (usually -F4T) in my 'C' demo codes for various LCD controlling circuits (GPIO and/or I2C or SPI based)****
Trev.
**Since, at the time, I couldn't confirm or deny such, I assumed that once an I2C or SPI byte/word was sent I needed to wait for the associated serial transmission times - that may not always be the case.
**** The ones with (usually) lcd in their name with their "self-generated help" here: http://www.cpmspectrepi.uk/raspberry_pi ... tware.html
Still running Raspbian Jessie or Stretch on some older Pi's (an A, B1, 2xB2, B+, P2B, 3xP0, P0W, 2xP3A+, P3B+, P3B, B+, and a A+) but Buster on the P4B's. See: https://www.cpmspectrepi.uk/raspberry_pi/raspiidx.htm

julyjim
Posts: 117
Joined: Tue Jan 31, 2017 5:04 am

Re: Reading busy flag on LCD

Tue Apr 17, 2018 8:40 pm

I have no time to really digest your post.
But it follows the original reply - does not answer the HOW question.
Have been busy making my I2C work and just finished sending "The quick,,,," test message.
To a casual observer likes me - I do not notice any speed issue getting the full text to the LCD.
So your comments are nice , but again - do not tell how to check BF and the rest of it is academical - "what if" kinds of points.

Back to the OP
I think that one need to instruct the expander to enable access to the Hitachi controller first and then t read the controller itself.

I have not fully implemented ioctl "read" function , not yet , I am only checking the ioctl buffer and having same results as OP. It "reads" the last data send to ioctl - not the LCD response.

User avatar
FTrevorGowen
Forum Moderator
Forum Moderator
Posts: 5800
Joined: Mon Mar 04, 2013 6:12 pm
Location: Bristol, U.K.
Contact: Website

Re: Reading busy flag on LCD

Tue Apr 17, 2018 9:45 pm

julyjim wrote:
Tue Apr 17, 2018 8:40 pm
...
But it follows the original reply - does not answer the HOW question.
...
That's because there's no "generic answer" - it depends upon HOW (ie. by what circuitry**, may be including an I2C device) the Pi is connected to the display also. Whilst the O.P. did provide some limited info. on his setup, that's something you have not. Your reference to "ioctl" also suggests that you're working at a "lower software" level than many other Pi users who use library routines/methods to control/use the GPIO's such as those provided in wiringPi or pigpio both of which are now "pre-installed".
Trev.
** The most common I2C to LCD interface uses a PC8574 to provide both 4-bit data and control signals. That device does not have separate inputs and outputs or a "tri-state-like bus", but requires output pins to be set high so they can be "pulled-down" low by a connected device, unlike a micro-controller (or the old 8-bit microprocessor's I worked with many years ago) may have. Hence the less complicated (hardware-wise) "write only" approach.
Still running Raspbian Jessie or Stretch on some older Pi's (an A, B1, 2xB2, B+, P2B, 3xP0, P0W, 2xP3A+, P3B+, P3B, B+, and a A+) but Buster on the P4B's. See: https://www.cpmspectrepi.uk/raspberry_pi/raspiidx.htm

julyjim
Posts: 117
Joined: Tue Jan 31, 2017 5:04 am

Re: Reading busy flag on LCD

Tue Apr 17, 2018 11:31 pm

OK, I own you an answer.
Indeed I am using "low level" approach to my development - for few reasons.
First and most intriguing is that Linux has "low level" function "ioctl", secondly because as the OP said - there are oodles of "libraries" written for Arduino. Nice, but... These resources , I have an issue with Arduino calling them "libraries" , are "open source" . That to me means anybody feels free to make his own. Few things wrong with that approach - it generally includes header files no longer under active development, and second - they generally lack documentation.
IMHO they are build for "cut and paste " crowd. Fine with me.

It seems logical to use ioctl functions implementing I2C - Linux software running on Linux OS.
As you pointed out PCF8574 works nicely as I2C "expander " and Hitachi HD44780 controller documentation (!) has been around few years.
I get no real thrill from running wire. begin.... x.clear() - can do BOTH using generic file. write(...).
Matter of choice.
However, you are correct in assessment of interfacing PCF8574 in "read from Hitachi controller mode.

User avatar
PeterO
Posts: 5958
Joined: Sun Jul 22, 2012 4:14 pm

Re: Reading busy flag on LCD

Wed Apr 18, 2018 6:59 am

FYI. when I was programming these types of displays form PIC microcontrolers I found that the behaviour of the busy bit was at best inconsistent across different manufactures if it worked at all. I eventually took the simple way out of ignoring it and using the delay solution mentioned above.
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

julyjim
Posts: 117
Joined: Tue Jan 31, 2017 5:04 am

Re: Reading busy flag on LCD

Wed Apr 18, 2018 5:24 pm

Yes, sometime KISS works best.
I finally got the "set up for 4 bits" working , but some steps seems to be candidates for usleep.
I believe it is partially due to ioctl "write" so maybe I'll put the usleep there.
It really does not follow the " write data when valid " - just assumes the data is set during the output of the first part of the two cycles. The second cycle sends the data again - which should not change the data output of the expander - and the missing "enable" actually writes to the HD44780 controller.
The hardest part was to figure out how the expander sets its ports from the I2C, I suppose if I manage to trigger the scope from the SCL and check the expander output then.
Time to replace my ancient 464 with digital...

julyjim
Posts: 117
Joined: Tue Jan 31, 2017 5:04 am

Re: Reading busy flag on LCD

Thu Apr 19, 2018 2:10 pm

Just in case there is an interest.
Still believe I should be able to use ioctl - per HD44780 setting the R/W to just read should make the HD44780 controller to "output" BF plus "address (?)". PCF8574 is pretty transparent to switch form write to read.
So using ioctl "write " to set the R/W and then ioctl "read" should work.
The "4 bits" interface makes this little complex, but since BF is bit 7 etc.

But this is all not necessary when one does not use commands requiring wait for BF in succession anyway.

User avatar
FTrevorGowen
Forum Moderator
Forum Moderator
Posts: 5800
Joined: Mon Mar 04, 2013 6:12 pm
Location: Bristol, U.K.
Contact: Website

Re: Reading busy flag on LCD

Thu Apr 19, 2018 6:50 pm

julyjim wrote:
Thu Apr 19, 2018 2:10 pm
Just in case there is an interest.
Still believe I should be able to use ioctl - per HD44780 setting the R/W to just read should make the HD44780 controller to "output" BF plus "address (?)". PCF8574 is pretty transparent to switch form write to read.
So using ioctl "write " to set the R/W and then ioctl "read" should work.
The "4 bits" interface makes this little complex, but since BF is bit 7 etc.
But this is all not necessary when one does not use commands requiring wait for BF in succession anyway.
And, in fact, there's only one, "Return Home" that has a significant execution time ie. 1.52ms cf. 37us for all the rest, excluding invoking 4-bit mode during the initialisation process. (p24 & pp45-46 of the datasheet)
Trev.
Still running Raspbian Jessie or Stretch on some older Pi's (an A, B1, 2xB2, B+, P2B, 3xP0, P0W, 2xP3A+, P3B+, P3B, B+, and a A+) but Buster on the P4B's. See: https://www.cpmspectrepi.uk/raspberry_pi/raspiidx.htm

Return to “Interfacing (DSI, CSI, I2C, etc.)”