I2C Sensor in python - PyComms library


10 posts
by cTn » Tue Oct 09, 2012 4:53 pm
github repo: https://github.com/cTn-dev/PyComms

Hi guys, i was recently asked (by multiple people) for sensor source codes that i am currently using in my quadcopter project, i have some "initial" but 100% pure python support for
MPU6050 (with 6 axis DMP)
PCA9685 pwm/servo driver from adafruit (no real work there, just slightly modified code from adafruit guys)
HMC5883L (raw magnetometer data output)
i am planning to add support for BMP085 barometric sensor

I also created simple example file for each i2c device.

There is plenty of really well written i2c libraries for arduino, but basically none of those "exists" for python and as people use RPi to do various things, they require same level of sensor support that people have on arduino, so this is my first "crack" on getting some of the sensors that people use on arduinos to work on RPi (for those who use python of course), my libraries are still little rough around the edges, but they should give you a nice starting point for your project (because lets face it, not everyone has the skills or time to rewrite an 3000 long c++ library, am i right?)

I really hope that some of the skilled programmers can pitch in and make this library even better.
I am trying to get at least few of the libraries "under one roof", like i2cdevlib does, where people can download finished and fully working library for their respective sensor.

I really hope that at least a few individuals rise up and help make this a reality.

Well that's pretty much it, let the coding begin !

Good luck with your project and have a nice day.
Posts: 49
Joined: Sat Aug 11, 2012 4:11 pm
by quantalume » Thu Oct 11, 2012 5:23 pm
The problem with anything based on the Python smbus library is that SMBus is a subset of I2C that was created for managing devices on a PC motherboard. Many devices, including the CO2 sensor that I'm currently working with, interface via I2C but do not conform to the SMBus subset protocol. I'm using the Quick2Wire library discussed <here>, but I will reserve judgement on it until I've completed testing. :)
Posts: 4
Joined: Tue Oct 02, 2012 3:52 pm
by techpaul » Thu Oct 11, 2012 6:22 pm
quantalume wrote:The problem with anything based on the Python smbus library is that SMBus is a subset of I2C that was created for managing devices on a PC motherboard. Many devices, including the CO2 sensor that I'm currently working with, interface via I2C but do not conform to the SMBus subset protocol. I'm using the Quick2Wire library discussed <here>, but I will reserve judgement on it until I've completed testing. :)

Ahem SMbus is a SUPERset of I2C as it has extra signals, reset and timeouts.

I2C could least for years on a single byte transfer and still conform to the spec.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/
Posts: 1509
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
by quantalume » Thu Oct 11, 2012 6:46 pm
techpaul wrote:Ahem SMbus is a SUPERset of I2C as it has extra signals, reset and timeouts.

I2C could least for years on a single byte transfer and still conform to the spec.


Well, I guess it depends on your perspective. From a low-level, data transfer perspective, SMBus only uses a few of the possible packet types that you could conceivably construct using the I2C protocol definition. If you're relying on SMBus libraries, you won't be able to communicate with all the I2C devices out there.

From the <Wikipedia article> on SMBus:
Each message transaction on SMBus follows the format of one of the defined SMBus protocols. The SMBus protocols are a subset of the data transfer formats defined in the I²C specifications. I²C devices that can be accessed through one of the SMBus protocols are compatible with the SMBus specifications. I²C devices that do not adhere to these protocols cannot be accessed by standard methods as defined in the SMBus and ACPI specifications.
Posts: 4
Joined: Tue Oct 02, 2012 3:52 pm
by techpaul » Thu Oct 11, 2012 7:16 pm
quantalume wrote:
techpaul wrote:Ahem SMbus is a SUPERset of I2C as it has extra signals, reset and timeouts.

I2C could least for years on a single byte transfer and still conform to the spec.

Well, I guess it depends on your perspective. From a low-level, data transfer perspective, SMBus only uses a few of the possible packet types that you could conceivably construct using the I2C protocol definition. If you're relying on SMBus libraries, you won't be able to communicate with all the I2C devices out there.
I2C does NOT have packet types, it has various transfer methods, the standard 7bit addressing is commonly supported and is what SMbus is transmitted over. I suggest you read the SMbus spec here and what the options for python-smbus are.
Please be aware as in the OSI 7 layer networking model I2C is layer 1 and layer 2 levels,. the higher levels are software interpretation beyon python-smbus. With a few additions of reset detection.
From the <Wikipedia article> on SMBus:
Each message transaction on SMBus follows the format of one of the defined SMBus protocols. The SMBus protocols are a subset of the data transfer formats defined in the I²C specifications. I²C devices that can be accessed through one of the SMBus protocols are compatible with the SMBus specifications. I²C devices that do not adhere to these protocols cannot be accessed by standard methods as defined in the SMBus and ACPI specifications.
Please don't rely on Wikipedia as a definitive reference.
From SMBUS Spec link

"The System Management Bus (SMBus) is a two-wire interface through which various system component
chips can communicate with each other and with the rest of the system. It is based on the principles of
operation of I2C*."

Packets is a higher level interpretation of the data transferred.

Amazing how many folks have i2c working fine even with python-smbus
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/
Posts: 1509
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
by quantalume » Thu Oct 11, 2012 8:51 pm
techpaul wrote:I2C does NOT have packet types, it has various transfer methods, the standard 7bit addressing is commonly supported and is what SMbus is transmitted over. I suggest you read the SMbus spec here and what the options for python-smbus are.
Please be aware as in the OSI 7 layer networking model I2C is layer 1 and layer 2 levels,. the higher levels are software interpretation beyon python-smbus. With a few additions of reset detection.

I didn't say that the I2C protocol defined packets, what I said (or at least meant to say) was that it's possible to construct packets which are not in violation of the I2C specification but which are not defined in SMBus. If you look at section 5.5 of the spec you cited, those are the only frames/packets/protocols supported by SMBus.
Posts: 4
Joined: Tue Oct 02, 2012 3:52 pm
by techpaul » Thu Oct 11, 2012 9:10 pm
quantalume wrote:
techpaul wrote:I2C does NOT have packet types, it has various transfer methods, the standard 7bit addressing is commonly supported and is what SMbus is transmitted over. I suggest you read the SMbus spec here and what the options for python-smbus are.
Please be aware as in the OSI 7 layer networking model I2C is layer 1 and layer 2 levels,. the higher levels are software interpretation beyon python-smbus. With a few additions of reset detection.

I didn't say that the I2C protocol defined packets, what I said (or at least meant to say) was that it's possible to construct packets which are not in violation of the I2C specification but which are not defined in SMBus. If you look at section 5.5 of the spec you cited, those are the only frames/packets/protocols supported by SMBus.

Which are all I2C communications it is the interpretation of the data bytes that is the matter for the higher level software. I2C has Read and Write Nbytes, with Start, address byte, Stop, repeated start, and ack phase.

Other than the quick command which is used in i2c bus scans, the read data and write are just standard I2C exhanges, the rest are just higher level interpretations of what the data means.

python-smbus supports basic I2C transfers, it works like others have done.

You have not said anything that says it cannot work when it is a I2C controller in hardware, and you are reading too much into the name python-smbus as this is used by higher functions in operating systems with smbus software for ACPI compatibility which is not relevant here.

I suggest that you check what python-smbus actually does.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/
Posts: 1509
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
by quantalume » Fri Oct 12, 2012 6:18 pm
Let me give you a real-world example. I have a device that requires an I2C transaction like this:
Code: Select all
Start | I2C adx | sdata1 | sdata2 | sdata3 | sdata 4 | Stop
The I2C master only sends I2C adx (the device address); sdata1-4 (4 bytes) are returned by the sensor. There is no SMBus-style "command code" byte associated with the transaction. Aside from the single-byte read protocol (SMBus spec 5.5.3), all other SMBus read protocols involve sending a command byte after the device address before allowing the device to send its data. Since python-smbus interfaces to ioctl through the I2C_SMBUS function only, there is no way around this limitation (see the python-smbus documentation <here> and <here> and the kernel docs <here> and <here>). We need to set up a call to the ioctl I2C_RDWR function in order to properly access the device I'm describing. That is exactly what the Quick2Wire library I referenced earlier does.

techpaul wrote:
quantalume wrote:From the <Wikipedia article> on SMBus:
Each message transaction on SMBus follows the format of one of the defined SMBus protocols. The SMBus protocols are a subset of the data transfer formats defined in the I²C specifications. I²C devices that can be accessed through one of the SMBus protocols are compatible with the SMBus specifications. I²C devices that do not adhere to these protocols cannot be accessed by standard methods as defined in the SMBus and ACPI specifications.
Please don't rely on Wikipedia as a definitive reference.
The wikipedia paragraph was taken directly from the SMBus spec, Appendix B. SMBus is a subset of all possible I2C protocols just like TCP/IP is a subset of all possible protocols that could be implemented with a switch and a piece of wire.
Posts: 4
Joined: Tue Oct 02, 2012 3:52 pm
by techpaul » Fri Oct 12, 2012 6:38 pm
quantalume wrote:Let me give you a real-world example. I have a device that requires an I2C transaction like this:
Code: Select all
Start | I2C adx | sdata1 | sdata2 | sdata3 | sdata 4 | Stop
The I2C master only sends I2C adx (the device address); sdata1-4 (4 bytes) are returned by the sensor. There is no SMBus-style "command code" byte associated with the transaction. Aside from the single-byte read protocol (SMBus spec 5.5.3), all other ....

So what you are saying is that all the I2C devices that people use does not work but all the people using python-smbus successfully that makes calls to the i2c_smbus driver

See for example
http://wiki.erazor-zone.de/wiki:linux:python:smbus:doc that lists all sorts of smbus and i2c functions.

That is the last I will say as you believe I2C devices will not work, and lots of people have it working.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/
Posts: 1509
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
by jwatte » Mon Oct 15, 2012 8:57 am
What's the disconnect here?
There exists I2C devices that work fine with smbus.
There also exist I2C devices that don't work with smbus.
If smbus implements the kernel API as SMbus and not just raw I2C, then the former kind of device will work, and the latter will not.
What's there to argue about?
Posts: 87
Joined: Sat Aug 13, 2011 7:28 pm