GpioProviderBase: cache array too small when passing MCP23017 pins, even with the dynamic improvments done (see Fix #224)

10 views
Skip to first unread message

GeertVc

unread,
Aug 21, 2016, 10:29:17 AM8/21/16
to Pi4J
Hello,

I'm facing an issue with the size of the cache array in GpioProviderBase.java when using the MCP23017 IO expander.  In the past, the size of the cache array was fixed to 100, but that gave a problem:

When using the MCP23017 device, the pins are created in MCP23017Pin.java through the createDigitalPin() method.  This method accepts 2 params: an address and a string.  The address goes from 1 up to 1128 (in a kind of "OR"-able fashion, not completely true...) depending on the GPIO pin given (from GPIO_A0 to GPIO_B7).

Problem is that this address is used as input parameter for the method getPinCache() in GpioProviderBase.java.  The "real" address is retrieved through a call to the method getAddress(), which will return, depending on the GPIO pin given, the associated address.  But it's easy to see that there will be already issues when entering the method getPinCache() with the pin GPIO_A7, as this will be assigned the address 128 in the createDigitalPin() method mentioned above.

Now, in the new implementation of GpioProviderBase(), this would be solved since the address (128 in the example given) is bigger than the initial cache array size (100) and because of that, an extra 100 locations will be added to the cache array through the check if(address > cache.length) in the method getPinCache().

But that fix is not sufficient.  What if I enter with the pin GPIO_B7?  This results in an address of 1128 (AFAICS, the file MCP23017Pin.java is not adapted and those high address numbers are still in place) and adding 100 to the initial cache array size of 100 won't help.  You WILL run against an array out of bound exception.

Or do I really overlook something here?

Question: is it really necessary to use kind-of "OR"-able addresses for the digital pins or can we simply use consecutive numbers (if so, that would solve the issue immediately).

Best rgds,
--Geert


GeertVc

unread,
Aug 21, 2016, 10:36:02 AM8/21/16
to Pi4J
I think I can already answer the question I asked at the end of the above post myself: I've seen in the file MCP23017GpioProvider.java that there's a bitwise AND applied using the pin address in the method evaluatePinForChangeA() (to give one example).  So, it won't be possible to implement consecutive numbers...

Remains the initial problem itself.

Best rgds,
--Geert
Reply all
Reply to author
Forward
0 new messages