I2C

Nearby power and grounds:

To enable i2c development, use:

apt-get install i2c-tools libi2c-dev

This will make the system set the i2c devices to be read-writeable by the owner root and the group i2c. Then we can add the usernames of the users who are to be using i2c into the listing of the i2c group in /etc/group and /etc/gshadow. From then on, these users don't have to elevate permissions to root in order to be able to handle i2c devices.

/sbin/i2cdetect -y 1 generates messages in the system log for all the unconnected addresses,

sunxi_i2c_do_xfer()902 - [i2c1] incomplete xfer (status: 0x20, dev addr 0x77)

and it produces a different message

twi_start()370 - [i2c1] START can't sendout!

when there is nothing connected to the TWI1 pins (P3 and P5).

/sbin/i2cdetect -y 0 generates similar messages:

twi_start()370 - [i2c0] START can't sendout!

since there probably isn't anything connected to it at ports PH0 (TWI0_SCL) and PH1 (TWI0_SDA).

Further investigations show that these TWI0_SDA and TWI0_SCL here have pull-up resistors connected, (R96 and R97 on page 16 of the schematics) and are connected to two of the pins on the TP connector, pin T3 is TWI0_SCL, and pin T4 is TWI0_SDA. Other pins here provide +3.3V and GND, the entire set is listed in the section on GPIOs.

Thus, it seems that we can use this bus as well, at least when not needing the LCD screen, as the Touch-sensitivity parts of that is what this TP port was originally made for. So for non-standard uses, either fabricate a suitable adapter or connector (from flat-cable with 6 conductors) or solder wires onto the test-pads on the underside of the card.

Pins P27 and P28 are driven by the S_TWI port, which doesn't seem to have support in the kernel as of now (2016-08-23).

The TWI1 / i2c-1 buss on P3 and P5 only shows evidence of a weak pull-down resistor, and in order for i2c to work here we need to insert pull-up resistors for the two lines, from each of these to +3.3V. Raspberry Pi has 1.8 kΩ here; I have been using 3.3 kΩ to 10 kΩ resistors with good results. According to the schematic (page 17), there is made space for a pair of resistors, nominally 2 kΩ but the locations are unpopulated.

Programs for communicating with i2c devices here worked right away when ported across from the Picotuxes and Raspberry Pi using the i2c_smbus_ series of functions declared in #include <linux/i2c-dev.h> from the libi2c-dev installation.

This includes the different include and linkage settings to be used with Debian Buster.

As of june 2019, the necessary details for using i2c_smbus_write_byte_data() and siblings, require the following include statements:

#include <unistd.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/i2c-dev.h>
#include <i2c/smbus.h>

When linking, the -li2c library reference has to be added, as here is where these functions exist.

Prior to this, there were no i2c/smbus.h required.

Powering TWI0

The TWI0 /dev/i2c-0 buss is not powered on by default. Looking at /sys/devices/platform/axp81x_board/axp-regulator.30/regulator/regulator.21/name shows the regulator named axp81x_gpio0ldo and /sys/devices/platform/axp81x_board/axp-regulator.30/regulator/regulator.21/state shows that it disabled.

By the way, there is a useful overview of the various regulator channels in /sys/class/regulator/dump.

There was a forum post about a driver for the Touchpad, and looking at the initialization source for that, there is a number of calls to kernel functions named things like: regulator_get(), regulator_is_enabled(), regulator_enable(), and even regulator_set_voltage(). There is a large set of these functions, as evidenced by man -k regulator (when having the section 9 kernel functions documentation installed, (apt-get install linux-manual-3.16).

#include <linux/regulator/consumer.h>

Seems that we can turn these regulators on and off via these functions, notably, regulator_get() to access a regulator, then regulator_enable(), regulator_disable(), regulator_get_voltage() to see the set output voltage. And regulator_put() to release it afterwards. Initial attempts at the reading functions indicate that the names of the regulators are the ones found in the file name in the sysfs locations above. Thus the name of interest here is axp81x_gpio0ldo or ldo-io0.

Here is the source of a kernel-module that contain the necessary calls to turn the power on.

And indeed, connecting a pcf8574 and a ds1621 here, then once power is turned on, we see that it is working, both units appear in the i2cdetect -y 0 listing, and they work as expected.

On the Armbian system, the /sys/class/regulator lists symbolic links to the various regulators (/sys/class/devices/platform/soc/1f03400.rsb/sunxi-rsb-3a3/regulator/regulator.*), and similarly, /sys/device/platform/soc/1f03400.rsb/sunxi-rsb-3a3/regulator maps to the same set of subdirectories.

Interesting files under each of the regulator.* are the name, state, and microvolts information.

For here, the name of the interesting regulator is ldo-io0

On the 5.10 kernel (2021-05-07) this turns out, is the regulator.20.

To Pine 64+ main page