Propeller IO access object

Erik "SPIN" J.

Hi everyone,

I made a little object that lets you transparently access both the Prop's internal IO pins, and IO pins connected through an I2C expander by simply numbering the pins higher (Pin 32 becomes the first pin on the first connected IO expander). I currently have support for the MCP23017, with PCA9555 support coming soon.

It's available on github here: https://github.com/ve4edj/propeller-io

Comments and criticism welcomed.

Erik

Electrodude

This looks interesting. It would be excellent for use with an optimizing Spin compiler that knew how to do common subexpression elimination, function inlining, and compile-time function execution, but unfortunately there are no such compilers right now, meaning it probably won't be terribly fast. Most of these function will be called very often, I imagine, so you should unfortunately probably optimize it yourself, and there are many optimizations you can do to it. For example, validPin can be optimized to

PRI validPin(pin)
  return 0 =< pin and pin =< totalPins

value &= 1 in PUB write and dir &= 1 in PUB direction are pretty much useless and just slow things down. PUB direction can use if dir ... else ... instead of if dir == INPUT ... if dir == OUTPUT. getExpIdx and getExpPin can be optimized by subtracting N_PROPPINS once as soon as it is determined that pin doesn't refer to a real pin in the calling function and then the / and // can be inlined into the calling function. I would also inline propPin and validPin. Also, the if validPin(pin) check should probably be removed from release code but is nice for debug code.

DavidZemon

What an awesome idea! I've added this as a new feature request in PropWare

David

JonnyMac

Something to consider: Your I2C access is part of the object -- you could put that into its own object that is common all of your I2C devices. I would also suggest not driving the SCL and SDA lines high; write 0 to the respective output bits and only pull the IO pins low (the pull-up will create the 1 state on the lines -- this is the I2C spec, anyway),

Like others, I think it's a great idea to virtualize pins beyond 31. Nicely done.