A Great I/O expansion Shield for RaspberryPi based on I2C

Today we introduce a I/O expansion shield for Raspberry Pi which allows you to extend the number of digital inputs and outputs available for our applications. [See also our previous I/O expander for Arduino]

After having published the LCD display and GSM expansion shield we add to the collection a new shield, based on the MCP23017, which allows you to increase the number of digital inputs/outputs to be used by your applications. This I/O Expansion shield provides eight inputs and eight digital outputs. On the eight inputs, LEDs show the status of visually. Each of the eight digital outputs pilots a relay which can be connected to external loads. Also on each output is an LED that makes visible the state.

To access the I/O shield you take advantage of the I2C bus. The address of the shield is customizable via a DIP switch with three positions. In this way, up to eight shield can be simultaneously used, each with a different address, for a total of 64 inputs and 64 outputs individually drivable. In this article we present also the Open Source Wiring-PI library, a Python library for licensed under GNU LGPLv3, which allows access to individual inputs and drive it very easier. Recall that the expansion shield presented in this article coexists peacefully with the other shield that we have presented, and also with those of third parties on the market. A wealth of connectivity options that allows for the creation of applications that can handle even highly complex environments. The implementation of such applications requires a quantum leap compared to what we have presented so far. Mainly it’s because is necessary to design and implement software architectures that are able to decouple the use of external devices from processing modules themselves. In particular, we must build programs that can respond to “events” generated by external inputs from the sensors connected to them, which occur asynchronously. It is also necessary to properly design the programs to manage devices that are attached to the same communication resources. For example, several applications may want access to different devices, but using the same I2C bus. This is the case of the expansion shield we present in this article.

If an application already uses the bus, to read or write the state of an I/O’s it controls, other applications that require to bind the same bus to manage the I/O pertaining to them, finding it busy can not do anything but go wrong. The first solution that might come to mind is to make one huge application that manages all the features in a monolithic way, a bit ‘like a huge microcontroller. It’s intuitive, by the way, that this approach leads to more negative than positive aspects: application rigidity, complex design, construction, maintenance and renovation, difficulty in timing between the different parts, fragility (if a party, even insignificant, it must be in error falls throughout the application). To resolve a need for this type of application, seek architectures that can support concurrent applications collaborating and managing communications between the different actors, based on that orchestrate the use of server resources to be shared and where the different application requirements must be implemented as clients that require the use of resources “centralized” by requests based on shared protocols. There are many possible alternatives, TCP / IP sockets, functionality, databases, flat files, and so on. The important thing is that the communication mechanisms are able to properly manage the phenomenon, such as generating code or managing “semaphores” to properly coordinate client requests. Clients, finally, when need to access a centrally managed resource, must avoid direct accessed but use the default communication channel for that resource with the protocol and the procedures laid down. In summary, in the world of embedded design does not have to be paid to the individual application, but must take into account the architecture that you want to accomplish as a whole.

The circuit is designed around the MCP23017 integrated circuit, from Microchip, offering 16 inputs / outputs that can be driven through the I2C bus. In this way, we can drive the eight inputs and eight digital outputs of our shield engaging the only two pins of the Raspberry Pi connector headed to the I2C bus. Obviously the bus is not used exclusively by our shield, but you can connect other devices, of course configured with different addresses.

MCP23017 provides 16 I/O divided into two banks of eight lines each called GPA and GPB. Each line of the IC is individually configurable as an input or output. In our shield the bench GPA is entirely dedicated to the management of the outputs with relays while the tour GPB is dedicated to the management of the digital inputs. The lines of digital output from the integrated bank GPA MCP23017 are connected to the input pin of the IC U2, a ULN2803, specially designed to drive inductive loads such as relay coils. Inside the IC there are eight darlington transistor stages with emitters in common, and an output current up to 500mA. The inputs 1-8, characterized by a high input impedance, can be driven directly from the ports of the I / O of a microcontroller or integrated as the MCP23017.

The digital inputs are headed to the pins of GPB the bank the IC. The pull-up resistances maintain the high level input. The diode serve to protect input of the IC, limiting the maximum voltage that can arrive at the input pin to 5V. All digital inputs have a common ground, which corresponds to a negative power supply; negative and positive are also present on a double contact of the terminal, so as to have easily available to 5V with which you can supply power to the external circuits. The shield requires an external power supply with a voltage between 9 and 12V, as opposed to a separate Raspberry Pi, since the 5V output of the latter is not able to provide the current needed to power the shield . The shield, however, is capable of powering the Raspberry Pi. If you want to keep the powers of the shield and the Raspberry Pi board separated, JP5V jumper must be placed between the center pin and the pin 5VR. To ensure that the shield power supply also supplies the Raspberry Pi board, the JP5V jumper must be placed between the center pin and the pin 5VRPY.

INTB output, which allows you to manage the interrupt inputs coming from the GPB bank can be connected, by means of the INTR jumper, to RaspberryPi’s GPIO22 or GPIO17, so as to make it available to applications. The Dip Switch connected to pins A0, A1 and A2 of the integrated, allows you to set the I2C address to be assigned to the integrated.

The possibility of “packaging” is the fact that the MCP23017 integrated is connected to Raspberry Pi GPIO only with the needed pins for I2C communication and for the eventual power. All other Raspberry Pi pins are just passers-by.

 

 

For more detail: A Great I/O expansion Shield for RaspberryPi based on I2C

Current Project / Post can also be found using:

• expand io on rasberry pi
• raspberry for direct isp emmc