Let’s step back for a moment and review the big picture of what we’re trying to accomplish:

The goal is to receive periodic “pings” from a remote wireless node and see the results as plain text on the Raspberry Pi command line. What we have already is:

• a working Raspberry Pi setup, using either keyboard + monitor or a network login
• a working FTDI programming adapter, as used in the Getting Started series
• a way to connect to the I2C bus from the command line, using “i2cdump“, etc.
• a working example of the LPC810 acting as I2C slave
• all the hardware setups, both on the Raspberry Pi side and on the remote node side
• a tentative implementation of the remote node and the I2C bridge

Now is probably a good time to point out that the above setup is actually quite amazing: building a multi-bus / multi-platform / ultra low-power / embedded RF configuration like this can nowadays be done with a hardware investment of well under €100! The wide availability of free and open source tools, very low-cost hardware, and the wealth of information we can find on internet is unprecedented in history.

It’s unlikely (read: impossible) that the code will work on the first try, and there are lots of places where things can go wrong. Our best bet is to dramatically simplify things, and try and get each of the steps working one by one. Since we can’t see whether the RF side is working before I2C works, we’ll need to address that very early on.

We can test the I2C slave logic by simply returning some fixed data, but this time – unlike the previous slave code – we’ll include the new RequestHandler class.

Once the slave access works, we’ll insert some dummy data periodically into the new PacketBuffer class, and verify that it can all be retrieved from the Raspberry Pi host.

But first… let’s write some host-side code to access this imaginary new slave device.

[Back to article index]