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.
It seems common approach to fudge delays by trial and error instead of following HD44780
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)****
**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