Inconsistency between Python code & wiring for Raspberry LCD

[protz]

Hi,

I'm talking about the Raspberry Pi LCD + Backpack + Keypad, which is the product available here: http://learn.adafruit.com/adafruit-16x2 ... spberry-pi

I've been looking at the wiring diagram http://learn.adafruit.com/system/assets ... 1360171818 which, as far as I can tell, is consistent with the wiring on the plate. The diagram tells me that the LCD's DB7 (Busy Flag) is connected to GPB1. However, the Python source code "Adafruit-Raspberry-Pi-Python-Code/Adafruit_CharLCDPlate" (which http://learn.adafruit.com/adafruit-16x2 ... y-pi/usage points to) seems to think that DB7 is connected to GPB4.

Code: Select all

        # If pin D7 is in input state, poll LCD busy flag until clear.
        if self.ddrb & 0b00010000:

which polls GPB4, which is connected to DB4, not DB7.

Similarly, the code contains the following comment:

Code: Select all

        self.porta, self.portb, self.ddrb = 0, 0, 0b00010000

        (...)

        # Brute force reload ALL registers to known state.  This also
        # sets up all the input pins, pull-ups, etc. for the Pi Plate.
        self.i2c.bus.write_i2c_block_data(
          self.i2c.address, 0, 
          [ 0b00111111,   # IODIRA    R+G LEDs=outputs, buttons=inputs
            self.ddrb ,   # IODIRB    LCD D7=input, Blue LED=output

Which, as far as I can tell, sets, again, DB4 as an input, not DB7 (self.ddrb would have to be 0b00000010 for that).

Similarly, that bit seems wrong:

Code: Select all

            # Polling complete, change D7 pin to output
            self.ddrb &= 0b11101111

However, there is:

Code: Select all

                if (bits & 0b00000010) == 0: break # D7=0, not busy

which *does* seem to read the right bit.

At this point I'm fairly confused and I'm pretty sure that I'm missing something. Does someone have any idea about that?

Thanks,

~ jonathan

[adafruit]

we dont use the busy bit from what I recall, if you post an issue on the github repo we'll try to get to it- the code *does* work so you can continue your project

[protz]

Thanks for the reply! I'm actually trying to figure out how the code works which at least as interesting as playing with it

[spivey]

I agree with you, protz: the code is wrong, and that makes the loop to poll the busy flag ineffective. It doesn't really help for the Adafruit people to say that it works, because many people will not want to build on top of it but to replicate the same function in another way. Copying wrong code is a frustrating process. It seems to me that the polling loop ought, as you say, to look at a different bit, but also because the Hitachi controller will enable all four data bits as outputs, all four should be configured as inputs on the MPC chip.

It looks like the polling loop is not really needed, and the slowness of the I2C bus spaces commands out enough that each has time to complete. That's been my experience with an implementation written (for the moment) in C -- except that it is apparently necessary to poll the device at least once before the initial reset sequence, something that's acheived in the Adafruit code by initialising the data direction register for port B so that it is set up for polling. The polling then happens on the first command. If I delete this, then the device doesn't get initialised properly; I have no idea why.

Can anyone else shed any light on this?

[spivey]

Addendum: the initialisation problem disappears if I configure all pins of the MCP23017 as inputs initially, then enable the relevant pins as outputs once the output latches contain zeroes. I suspect a problem if the R/W pin on the LCD is randomly asserted during initialisation.

Happy to share code!

-- mike at cs.ox.ac.uk