Power & Source of Big Ideas

I2C support on NanoPi Fire3 with FriendlyCore Xenial

Moderators: chensy, FATechsupport

Hi,

I just received my Fire3 in the post today and have successfully installed Ubuntu Xenial from the zip file, configured WiFi, etc. All is working fine. On idle it runs pretty hot at 64-65 degrees celcius, this with the default heat sink installed.

When I run npi-config and try to enable I2C (or actually any of the advanced options) I see:

Only allwinner boards with mainline kernel support this option.


As I purchased the board to use on a robot whose sensors are all I2C I'd like to get the bus enabled. Am I using the wrong OS, or is there some way to update the kernel so that it can support I2C?

Thanks very much.
Hi, I've managed to locate what the problem I'd been seeing was,which is basically that the I2C bus on the Fire3 uses bus 0 rather than bus 1 as the device default. This is not the norm on a Raspberry Pi or Arduino.

When I plug an I2C device with address 77 into the bus I can see it show up on bus 0, not bus 1 as would be expected. The software libraries I'm using all expect devices to use bus 1 and cannot be altered to use bus 0 as that is not recommended, i.e., it is considered an internal bus. Below is shown my device on bus 0:

Code: Select all

 ▸ sudo i2cdetect  -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- 77


Bus 1 (where I'd normally see my I2C devices) shows a bunch of internal devices that would normally be on bus 0:

Code: Select all

 ▸ sudo i2cdetect  -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- 31 -- -- -- -- -- -- -- -- 3a -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- 4a 4b -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --


Is there some way to alter this default arrangement on the Fire3 so that it uses bus 0 and my devices use bus 1? As things stand, it is currently useless to me as I cannot attach and use I2C sensors, such as sold by Pimoroni, Adafruit, etc.

Thanks for your help.
Both I2C0 and I2C1 are available on the GPIO header so you should be able to make the software work but changing pins.

http://wiki.friendlyarm.com/wiki/index.php/NanoPi_Fire3
Ahh, I hadn't noticed that on a Raspberry Pi pins 3 and 5 are I2C bus 1, 27 and 28 are I2C bus 0. And that on the Fire3 this is reversed, i.e., pins 3 and 5 are I2C bus 0, 27 and 28 are I2C bus 1.

Is there a reason for this change? Yes, I could rewire my robot but all of the Raspberry Pi compatible GPIO HATs keep the I2C bus 0 and 1 as per the Raspberry Pi specification. I'm currently using the Pimoroni Breakout Garden HAT, so this would be therefore incompatible with the Fire3. The only way I can think of making this work would be to hand-wire a Fire3-GPIO-to-Pi-GPIO conversion board, or something like that.

Do you know of any way to swap (in software) the I2C busses on the Fire3 so that it would be compatible with the Raspberry Pi HATs? Or is this fixed entirely in the hardware? If so, it'd be a shame since I bought the Fire3 as a replacement for a Pi on the robot.

Thanks very much for your help!
It should be possible to swap them in software at the kernel level as they are allocated based on register settings. I don't even think you have access to the FriendlyCore Xenial source to do this. If the OS uses a device tree, you can swap them very easily by simply making changes to the tree.

This page details how to do this for different kernel methods.

https://www.kernel.org/doc/html/latest/ ... vices.html
Thanks, I'll give that a try as it seems by far to be the simplest of the options.
Be aware that changes to the I2C bus assignments might upset the system although most drivers do a probe to try and locate which bus they are present on.

Who is online

In total there are 4 users online :: 0 registered, 0 hidden and 4 guests (based on users active over the past 5 minutes)
Most users ever online was 5185 on Wed Jan 22, 2020 1:44 pm

Users browsing this forum: No registered users and 4 guests