Hi bbkiwi,
If you are going to fix the indentation, a noble cause in my opinion, then you should really be trying to get it in line with the python standard coding style (PEP8). That means 4 spaces, not tabs I'm afraid, but will look the same on everyone's system. To help you check the files there's a nice tool, also called 'pep8' that you can run. See http://pypi.python.org/pypi/pep8 or install via 'apt-get install pep8' if you are on Debian based distro.

Hope it helps,

Andrew

Hi Andrew, Thanks for the tip. I'm quite new to python, but have lots of experience with other languages. This all started with a Xmas present of a raspberry pi and a LCD display. Keeping me busy. I think the indentation muddle comes about especially on code where various people are editing it. On the WebIDE supplied by Adafruit there is no way to 'see' tabs or spaces. I'll check out pep8.

Hi, I have a problem using MCP230XX library.

I configure a pin to INPUT and when I read this value I receive error message that the pin is not in input mode. The error message is print by line 118 in MCP230xx library.

This problem is present with GPB0-7 pin. It's ok with GPA0-7 pin.

I changed this line to

assert self.direction & (1 << pin) != 1, "Pin %s not set to input" % pin

and it works now.

I don't known the effect of this change

Hi, As I mention above, I found a number of bugs in MCP230xx.py. In your case the config rountine is the cause of your problem. As supplied by adafruit, config is changing the pin properly to input or output on the chip, but it is not keeping track in the variable direction. direction should keep 16bits corresponding to both GPA and GPB (1 for input and 0 for output), but it changes the low order 8 bits for both GPA and GPB, thus overwriting the GPA information and storing the GPB information in the wrong bits. In short - the bits of direction do not accurately reflect the I/O state of the pins. Thus when you try and read from GPB the input routine does not see that the pins have been set as input. I only play with electronics so I'm no expert, but from my reading of the specs on the chips, if you attempt to read an output pin you just get the wrong answer, so preventing reading of output pins can cause no damage. I'd recommend leaving input as it stands and correctiing the code for config which my push corrects. Here is a version of config that keeps track of the I/O state correctly:

   def config(self, pin, mode):        
        if self.num_gpios <= 8:
            self.direction = self._readandchangepin(MCP23017_IODIRA, pin, mode)
        if self.num_gpios <= 16:
            if (pin < 8):
                # replace low bits
                self.direction = (self.direction >> 8)<<8 |  self._readandchangepin(MCP23017_IODIRA, pin, mode)
            else:
                # replace hi bits
                self.direction = (self.direction & 0xff) | self._readandchangepin(MCP23017_IODIRB, pin-8, mode) << 8
        #print "config ", pin, mode, self.direction, bin(self.direction)[2:].zfill(16)
        return self.direction

Thanks BBkiwi,

I use your MCP230XX library now and all works fine

Glad to help. I'm hoping my pull request will be looked at and my changes
put into the adafruit repo.

nice work. really embarrassed that i haven't spotted that bit in config, but please...

 self.direction = (self.direction & 0xff00)  |  self._readandchangepin(MCP23017_IODIRA, pin, mode)

Hi mtbf0, Have fixed that, don't know why I coded it in such a silly way. Are you the original author?

m3m0ry, we want to keep the tone positive here - please edit and re-post your comment. Thanks!

ladyada, I think adafruit is doing a great job. I've enjoyed learning about the LCD Plate and LED strips - even though I've blown up one Pi :-) , and it's nice to be able to be part of the community to develop improvements. Cheers from New Zealand!

Thanks! We have plans to speed up this library considerably - still working on getting it perfect before committing :)

I'm sorry i didn't want to be rude. I did not choose my words well, what i meant was that adafruit does merge the other forkes, but a little bit slow. Which i completely understand, because it is important to test and read what the others have written. I didn't want to be critical or rude to adafruit. So sorry for that.

I wrote that i also have a repo, which i "forked" from bbkiwi, but because you apparently cannot fork a fork on github (or with git???) i created my "own" repo. I will merge it with bbkiwi's fork. My goal is to write some useful functions (like the status of the CPU, or memory, or whatever in my opinion could be useful for anybody), related to the Char_LCDPlate.
I started today, and it's my first time with python, so i have not much yet. I write it here, because i didn't find any other way to communicate on github.
Repo:https://github.com/m3m0ry/Adafruit-Raspberry-Pi-Python-Code (but the only interesting file is https://github.com/m3m0ry/Adafruit-Raspberry-Pi-Python-Code/blob/master/Adafruit_CharLCDPlate/raspberryLCD.py )

Thanks for understanding! We like to make sure we always have completely tested and working code in our repositories to avoid problems with the many customers who are following our tutorials.

Can't automatically merge this request due to the extent of the change, so I'll be making the changes 'manually' and will mention your contribution in the commit comments. Thanks!

Hi PaintYourDragon,

  I see the NewLCDTest.py is now in Adafruit_CharLCDPlate. It is a very rough draft and not documented very well. I will try and get something better soon.