• We should probably have modules for at least one port expander - maybe something that comes in SPI and I2C versions. I would propose the MCP23008/23017/23S08/23S17 (S = SPI, 8 or 16 is number of ports) series. (the 23x16 series is not recommended for new designs per Microchip the 17 and 18 are the replacements)

    The nature of a port expander, however, requires more thought than a typical module, however, because people will want to have other devices on the other side of the port expander... such that we should, where possible, design it so that pins on the port expander could be used with existing modules, preferably without any special modifications.

    These MCP23xxx port expanders have:
    8 or 16 pins, arranged in 8-bit ports
    Pin can be input or output, and have a pullup that can be enabled
    Pins can be set to generate an interrupt on the INT pin.

    So a pin can be read, written 0 or 1, configured as input, output, or input_pullup, and enabled for interrupt.

    One of my first thoughts was to return a group of objects that act a lot like the pin class, which in turn would call a function in the port-expander object that actually translated them into a command to send over I2C/SPI

    {"A0":
    {
    "write":function(data){this.pe.write(thi­s.port,this.bit,data);},
    "read":function(){return this.pe.read(this.port)|1<<this.bit;},
    "mode":function (mode) {this,pe.mode(this.port,this.bit,mode);}­
    "bit":0, "port":0
    }

    This has a few problems, though:

    1. It'd be a little slow with all the I2C accessing going on.
    2. you can do digitalWrite([pin,pin,pin,pin]) and it will set them all almost at once. This wouldn't be possible.
    3. The real pin class doesn't have mode()
    4. most modules are currently written with arduino conventions (digitalWrite) not pin.write().

    What do people think on this? Is there a more sensible way?

About

Avatar for DrAzzy @DrAzzy started