I2C on non ARM instruction sets

[Timeless]

Hi,

Today I received the: CJMCU HTU21D BMP180 BH1750FVI Temperature Humidity Barometer Light Brightness Sensor

I've build Domoticz for LEDE on a MIPS_24kc instruction-set. (platform: GL.inet 6416) I included the I2C drivers and have a /dev/i2c-0 device which is detecting my sensors:

Code: Select all

root@lede:~# i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- 23 -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: 40 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- 77

So I went ahead and included the BMP180. Which went fine, no errors and got my first sensor values. Unfortunately I quickly discovered that this value was not changing. So I looked at the source code:

Code: Select all

#ifndef __arm__
	temperature = 21.3f;
	humidity = 45;
#ifndef _DEBUG
	_log.Log(LOG_ERROR, "%s: Only supported on ARM architecture!...", szI2CTypeNames[m_dev_type]);
	return;
#else
_log.Log(LOG_ERROR, "%s: Only supported on ARM architecture!... Debug: just adding a value", szI2CTypeNames[m_dev_type]);

Which seems to be correct because there is no __arm__ defined. And that's why I'm getting those default values.

However I do not see the "Only supported on ARM architecture!" sentence in the logs. And also having those fake values seems strange to me? why having fake values instead of just none?

My actual question:
Could it be me or is there no ARM specific dependency in the i2c library?

According to this piece of code:

Code: Select all

I2C::I2C(const int ID, const _eI2CType DevType, const int Port):
m_dev_type(DevType)
{

	m_stoprequested = false;
	m_HwdID = ID;
	m_ActI2CBus = "/dev/i2c-1";
	if (!i2c_test(m_ActI2CBus.c_str()))
	{
		m_ActI2CBus = "/dev/i2c-0";
	}
}

It should just use the /dev/i2c-0 or /dev/i2c-1 port. Which could be present on any instruction set as long as it is running Linux. There is no specific ARM dependency there.

Could someone explain why this could not run on another instruction-set than ARM?

Regards,
Timeless

[Timeless]

Ok good news!
I added the

Code: Select all

#define __arm__ 

and everything seems to be working. I get my Barometer sensor readings and they seem accurate. No more fake values for me
Proof:

Code: Select all

2017-01-11 21:44:12.553 BMP085: Worker started...
2017-01-11 21:44:12.555 EventSystem: reset all device statuses...
2017-01-11 21:44:12.569 EventSystem: Started
2017-01-11 21:44:17.649 Error: BMP085: Failed to open the i2c bus!...
2017-01-11 21:44:17.649 Error: BMP085: Check to see if you have a bus: /dev/i2c-0
2017-01-11 21:44:17.650 Error: BMP085: We might only be able to access this as root user
2017-01-11 21:45:17.829 (System Sensors) Temp + Baro (Unknown) 

Code: Select all

Temp + Baro	BMP085 I2C	22.1 C, 1002.4 hPa

The "Failed to open the i2c bus!..." is correct. I disabled this specifically for testing. See if having the /dev/i2c-0 device actually mattered this time. And it did.

As a side note, maybe this could be changed? We could add a message like "not running on arm, results cannot be promised" or something like that.

Please let me know

[Timeless]

There is still a issue with non Raspberry platforms see #1188. I'm currently debugging what is going wrong. I know that both the Raspberry and my Gl.Inet are using a software GPIO implementation of I2C. So maybe the hardware I2C port of my a PC engines Alix is faster/(slower) which could cause issues.

For a complete introduction please read my Github issue report. From now on I'll update this topic so the Github issue report stays clean(orderly).