Get your Linux computer to communicate with a microcontroller —Part 1: Concept

There’s no more powerful tool for safety than communication.

— Artemis, Andy Weir

Introduction

There are multiple ways to get multiple electronic devices to communicate with each other and they are called communication protocols in technical language. These protocols spread across a wide range of spectrum where one protocol uses just 2 conducting materials (metal wires) to communicate with around 50 devices while another has 7 layers of protocol stack with custom made cables to enable communication among millions of devices. The factors that decide the communication protocol in a system are, but not limited to, device compatibility, latency tolerance, distance between the devices, operating voltage and cost.

I2C

Inter-Integrated circuit (I2C)[1] is a relatively simple yet powerful communication protocol invented by Philips Semiconductors (NXP) in 1982 to enable communication among multiple devices that are situated closer to each other, ideally on a PCB or IC. It is still used in millions of devices including smartphones, computers, drones etc. The two lines used for I2C communication are SDA (Data) and SCL (Clock). As you can see, one of the lines is clock which controls the clock cycle of the communication and hence the two devices communicating with each other could be running on different clock speeds. I2C does not discriminate based on the clock speed. Isn’t it cool?

Texas Instruments has done a wonderful job of putting together the basics of I2C in a shorter document[2] than the I2C specification[1] and I encourage those who are interested in I2C to read it. The key things to know about I2C are,

1. It is master — slave protocol where only the master could initiate the communication

2. Each device connected in the I2C system can be communicated to using its unique address

3. It is a half-duplex system

4. Master device can read from and write to the slave devices.

5. Multiple masters could exist in the same system and arbitration takes place if multiple masters try to initiate communicate at the same time.

Here is a simple step by step process of how the master communicates with a slave device. Consider that there are 5 slave devices connected to the system and the address of the slave device to which the master wants to communicate is 0x18.

1. Master pulls down the SDA line and then the SCL line to indicate that it wants to communicate to a slave device. (ref Fig 1)

2. For the next 7 clock cycles (clock cycles of SCL not the device clock cycle), master sends the address of the slave device to which it has to communicate as seven bit value. In our case, it would be 00011000 (0x18)

3. In the next clock cycle, the master would send a bit which would determine the mode of communication. 0 for write and 1 for read.

4. In the next clock cycle, the slave device will acknowledge the communication request of the master device by pulling down the SDA. This is called the ACK bit.

5. Now that the connection between the master device and the slave device is established, master device will send the data as an 8 bit or multiple 8 bits until the stop is initiated by the master.

6. Master initiates the stop by releasing the SCL and then the SDA. (ref Fig 1)

A pictorial representation of the complete communication cycle is given in Fig 2.

Linux Driver

It would probably take 5 minutes and 4 lines of code and to write a python3 program to send the data(command) to the microcontroller through I2C. Why write a linux driver?

Designing and writing a linux driver will introduce us to the modelling of hardware devices into software device drivers. In Linux OS, pretty much everything is a file, even devices. All these files have four main operations such as read, write, open and close. And, we as the device driver developers, have full flexibility to implement it, the way we want. This gives us more power and access to the low level interference. Linux device drivers[3] by Jonathan provides us with a detailed analysis and information about the same.

In my previous post,[4] I explained how an LED could be blinked using timers in a microcontroller, without using delays. The frequency of the LED blink could be altered based on the value of the timer overflow and it could be calculated based on the desired frequency. As the next step, let us design and implement a system in which the desired frequency is set by a computer through I2C protocol encapsulated in a Linux Device Driver.

Once the kernel driver is written and installed in the computer, merely writing 5 to a file will make the LED blink at 5 hertz in the microcontroller. The concept of this system is illustrated in Fig 3.

See you in the next one! Cheers!

The code pertinent to this article is available at https://github.com/rocheparadox/simple-integrated-system/

References

[1] https://www.nxp.com/docs/en/user-guide/UM10204.pdf

[2] https://www.ti.com/lit/an/sbaa565/sbaa565.pdf

[3] Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman. 2005. Linux Device Drivers, 3rd Edition. O’Reilly Media, Inc.

[4] https://medium.com/@rocheinside/blink-an-led-like-a-real-embedded-systems-engineer-e40b7dfae54f