MCP20317 Driver (I2C)

I would like to tackle this but does anyone have a generic I2C driver for P2-FB? @JRoark?
I think it would be a good idea to list drivers, as they are developed in the Discussion Title(?)
Also attaching the datasheet for convenience(?)
Comments
This is Spin1, so you'll have to translate it, but if you've got a handle on I2C you'll see that it's quite simple. I haven't used this code in ages, but when I did it was on a client project (commercial HVAC system).
This is Spin1, so you'll have to translate it, but if you've got a handle on I2C you'll see that it's quite simple. I haven't used this code in ages, but when I did it was on a client project (commercial HVAC system).
Well... I tried to share my Spin1 driver for the chip that has been used in commercial products, but the forums tells me I am not allowed to upload files here. If you'd like that code you can send me a PM.
Here's the source (needs an I2C driver).
My Spin1 I2C driver
Now that we can attach files... here they are.
Thanks for the alert Jon.
Uploads are allowed now on all the new categories.
Testing Jon's files.
@JonnyMac
Many thanks, Jon

Very nice coding, as usual
I have only just gotten back to this and quite surprised to find that the I2C driver appears to be bit-banging and not a special smartpin function, correct?
Edit: Ah, it's P1 I see.
Here's my P2 I2C driver. There is no smart pin I2C mode, but the pin configuration bits allow for optional pull-ups which the code can use.
Cheers! I had already grabbed it from github
The one I attached is the latest. Added a constant called PU_EXT the other day.
Not sure if it was the P2 but I remember reading somewhere that external pull-ups were recommended(?)
Not to steal the thread, but... With flexprop, I'm not able to compile code that uses this version of jm_i2c.spin2 (the one in this thread as well as the one from the Spin 2 Beginner Series Part 12 download).
flexprop doesn't like the line (the addition of '#0,", within the enum):
compile example:
To compile, I had to modify the line:
A difference in how flexprop handle enumerators, I suppose.
dgately
That's a feature of Spin going back to Spin1. Hopefully, @ersmith can adjust FlexProp to handle that. In the meantime, I suggest modify your local copy like this.
Yep! Thanks!
@dgately and @JonnyMac : I think flexprop's error in this case is legit, and I'm surprised PNut didn't give at least a warning. The case statement starting at line 57 of jm_i2c.spin2 reads:
but PU_NONE and PU_EXT are both equal to 0, so there are indeed two case statements with the same label. Is that legal in Spin? At the very least it seems like it should be a warning.
In this case it does not, in fact, matter, since both cases do the exact same thing (set pullup to P_HIGH_FLOAT) but one can certainly imagine other cases where it could create unintended consequences.
My mistake -- I thought Dennis was suggesting the enumerated constants definition was the problem. Propeller Tool doesn't complain about the redundant value in case, but maybe it should. Since PU_NONE and PU_EXT has the same value, I will put the case structure back to the way it was.