Writing a MicroPython Driver for an I/O Expander

The ability to design and implement a driver is an important skill in embedded software development. Whether the driver is for an internal peripheral or for external sensors and input/output (I/O) capabilities, developers need to design and construct drivers that are flexible and scalable.

In this chapter, we will explore how to properly design drivers by implementing a project that uses an external I/O chip to interface with an RGB LED pushbutton. We will design a MicroPython driver to perform I/O using the external chip and to drive the RGB LEDs using the pyboard's Pulse Width Modulation (PWM) channels.

The following topics will be covered in this chapter:

• The RGB pushbutton I/O expander project requirements
• The hardware and software architecture design
• Creating the class outline
• Project construction
• Testing and verification...

Technical requirements

The example code used in this chapter can be found at the following GitHub location: https://github.com/PacktPublishing/MicroPython-Projects/tree/master/Chapter03

To be able to run the examples and build your own scheduler, you will need to have the following hardware and software:

• Pyboard revision 1.0 or 1.1
• A RobotDyn I2C 8-bit PCA8574 I/O expander module, or equivalent
• An Adafruit RGB pushbutton PN: 3423, or equivalent
• A breadboard
• 6" jumpers
• A Terminal application (PuTTy, RealTerm, Terminal, or one of many others)
• A text editor, such as PyCharm

The RGB pushbutton I/O expander project requirements

The primary goal for this project is to gain experience with developing a driver for external chips using MicroPython. In order to gain this experience, we will select hardware that allows us to expand the I/O capabilities of the pyboard and connect an RGB pushbutton to the expanded I/O. Before we jump into selecting components or writing any code, we first need to define the requirements for this project. We have two different sets of requirements that need to be considered: hardware and software. Let's look at each set of requirements individually.

Hardware requirements

The hardware requirements for this project are relatively loose. As we saw in the last chapter...

The hardware and software architecture design

At this stage in the project, we've discovered the requirements for the project. We are now going to develop the hardware and software architecture. The best way to picture an architecture is through a map that is general enough to provide directions to where we need to head but does not provide enough details to restrict how we get there. The architecture should be flexible so that we can deal with any changing requirements on the fly.

For our purposes, we will use this section to first explore the high-level architecture and then develop the detailed design that we can use to construct the project in the next section.

The hardware architecture

When it comes to the hardware...

Project construction

Now that the design for the hardware and the software has been thought through, we are ready to start building. There are different ways that we can go about building the project.

First, we could assemble one piece of hardware at a time and develop the software for that piece and, once it's working, add additional pieces. This is a great approach and one that I often use on more complex projects because it allows us to focus on just a single feature. Each feature can be developed and tested, with integration coming later.

Second, we can fully assemble the hardware and then develop the software. This approach is often used for smaller projects that may not have a bunch of moving pieces. For this project, we will use the second approach since we only have the external I/O expander and the pushbutton.

...

Testing and validation

At this stage in the project, we have created the basic drivers that will control all the low-level hardware devices in our project. We have drivers that allow us to generate PWM signals to drive RGB LEDs and a driver to access the I/O expander chip to write and read its status. At this point, we would normally develop a test harness that could fully test the drivers. This would allow us to discover issues we might have with functionality or boundary conditions. Since developing a test harness is an entire project in itself, we will save the test harness discussion for the next chapter. For now, we will jump ahead and create a test application that meets our project requirements and develop a few simple test cases to make sure that the high-level system meets those requirements.

...

Summary

In this chapter, we defined a simple test project that allowed us to expand the I/O capabilities of the pyboard while gaining experience in developing drivers. We integrated these drivers together to control an RGB LED pushbutton, whose color status was controlled by pressing the button. Throughout this chapter, we also discussed the software development life cycle and have been trying to adhere to its principles and major stages to ensure that we create a robust project.

In the next chapter, we are going to explore how we can create a test harness to fully test and integrate drivers. We will be leveraging the drivers that we just created in this chapter to develop and test our harness.

Questions

1. What is a high-level system diagram called?
2. What is a detailed hardware diagram called?
3. What three diagrams did we use in this chapter to define our software architecture?
4. What is it called when two classes are connected together without the use of an inheritance mechanism?
5. What information should be included in test cases?
6. How can a developer create a constant in Python?
7. What line of code should a developer write to find out which addresses have slaves present on the I2C bus?
8. What can be used to catch an exception and print it out?
9. What statement can be written to force an application to exit?
10. What type of setup can be used to fully test and validate the drivers created in an application?

Further reading

1. www.UML.org
2. https://www.computer.org/education/bodies-of-knowledge/software-engineering