|Exploring Edison - I2C Bus|
|Written by Harry Fairhead|
|Monday, 23 November 2015|
Page 3 of 3
This raises for the first time the question of how we cope with the speed that a slave can or cannot respond to a request for data.
There are two broad approaches to waiting for data on the I2C bus.
The first is simply to request the data and then perform reads in a polling loop. If the device isn't ready with the data then it sends a data frame with a NAK bit set. The mraa read functions return a zero if it fails or the data if it doesn't. Of course the polling loop doesn't have to be "tight". The response time is often long enough to do other things and you can use the I2C bus to work with other slave devices while the one you activated gets on with trying to get you the data you requested. All you have to do is to remember to read its data at some later time.
The second way is to allow the slave to hold the clock line low after the master has released it. In most cases the master will simply wait before moving on to the next frame while the clock line is held low. The Edison I2C bus implements this clock stretching protocol and it will wait until the slave releases the clock line before proceeding. This is very simple and it means you don't have to implement a polling loop but also notice that your program is frozen until the slave releases the clock line.
Many devices implement both types of slow read protocol and you can use which ever suits your application.
There is also the small matter of the speed of the I2C clock. In principle the clock can run at almost any speed but in practice this usually isn't the case. Most slave devices don't have strict clock rate that have to be used with them as they are designed as static devices synced to whatever SCL clock rate the master cares to use. If it turns out to be too fast then most will use clock stretching. In extreme cases it may be necessary to slow down or even speed up the master's clock.
There is an mraa function to do this:
This works with the Edison if you are using the latest mraa library. You can set one of three modes:
• MRAA_I2C_STD Standard mode 100Kb/s
By default the Edison works in Fast mode and you can select standard but at the time of writing high doesn't seem to work.
FSYS Linux I2C Commands
As with most Linux hardware, the necessary drivers represent the hardware as files. This is how it is with I2C and a collection of I2C tools that you can use from the command line are available. Sometimes these are useful, but in the case of the Edison they tend not to work as well as you might hope - and particularly so with I2C 6.
My advice is not to rely on the information you get back from the Linux tools because they often fail to detect devices that actually exist on the bus.
The commands available are:
To scan the bus report devices connected:
To dump registers:
To read a device register:
For example, to scan the buses installed you can use:
This will list eight possible I2C buses on the Edison. Of course, for hardware reasons ,you can only use 2, I2C-1 and I2C-6.
To list all of the devices connected to a bus you can use:
which scans bus 1. Notice this often results in a crash.
To dump all the registers in a particular device on I2C-1 use:
To read a particular register on a particular device use:
Finally to set a particular register on a particular device use:
Some programmers like using these commands to check that slave devices are present and working. Personally I would prefer to write a C program simply because the results are more reliable.
If you want to know more about the Linux i2c tools consult the man pages.
So much for theory. In the next chapter we try things out with a simple temperature and humidity sensor - the HTU21D.
The starting point for finding out about all Intel's Internet of Things resources, including Edison, is the Intel IoT Developer Zone.
Now On Sale!You can now buy a print edition of Exploring Intel Edison.
You can buy it from:
or email your comment to: firstname.lastname@example.org
|Last Updated ( Monday, 23 November 2015 )|