Add I2C library and example for CC2538

[medmig]

Add one header file and one implementation file to use the I2C peripheral of the CC2538 platform.
Add a line in the CC2538 makefile to include the I2C library for compilation.
Also add an example to use the I2C library with two different sensors (TCN75 from Microchip and SHT21 from Texas Instruments).

This adaptation of I2C library was made by Mehdi Migault for the 4MOD Technology company, as part of an internship with the IT department of the "Institut Universitaire et Technologique" in La Rochelle.
Parts of the sources come from Contiki and Texas Instruments.

It include an example for the I2C library that work with two different I2C sensors, the TCN75 from Microchip and the SHT21 from Texas Instruments. It measure temperature and send the value over the serial port.

[bthebaudeau]

This is a PR concurrent to #397. I have not compared these two PRs, but you will probably have to discuss with @areaarea in order to choose which parts of each PR are the best.

Regarding the print_float() function introduced here, it might be better to just fix float support in cpu/arm/common/dbg-io/strformat.c.

[ademirci]

I have tested this driver with CC2538 and MPU9150 setup. No problems so far
Thanks.

[abcminiuser]

This line causes GCC warnings to be emitted when -Wextra is used, as the single equals in a conditional is in many causes a bug (but not this case). You can silence it by wrapping up the conditional in a second set of parenthes:

if((temp = i2c_master_error())) {

[wangchu92]

For a beginer like I am, it is worth checking charpter 20 on http://www.ti.com/lit/ug/swru319c/swru319c.pdf

[dazhbog]

I can confirm that this works for my custom board with an SHT21. Thanks medmig!

[wwhuang]

This code works pretty well on my custom cc2538 platform. However, I think it should be user configurable whether or not the internal pull up resistors are used. I know some i2c peripherals only work with external pull ups, but the rtc I use works with just the internal pull up resistors.

[g-oikonomou]

Noted, thanks.

I think that with those positive confirmations we can merge this, even if it doesn't have everything that one might desire. I'll have a closer look as soon as I get a chance in view of merging this ultimately.

[dazhbog]

@wwhuang That would be a nice addition, but its interesting what you say that about some peripherals. Are you sure its not just the value of the pull-ups? What is the value you use? Usually weak pull-ups result in corrupted data, especially when you have many devices on the bus.

[dazhbog]

Hi medmig,

I have been using the code for a while, I was getting more resets from this code so I changed the following.

while(i2c_master_busy()) {}

to

uint8_t 
while_busy(void){
    uint16_t count     = 0;
    uint16_t count_max = 1000;
    while( (i2c_master_busy() && (count<count_max)) ){
        count++;
        clock_delay_usec(10);   
    }
    if (count>=count_max)
        return 1;
    else
        return 0 ;
}

Also I havent figured out how to send bytes to a device. Should it be something like this?

uint8_t
writeByte(uint8_t address, uint8_t reg, uint8_t val){
    i2c_master_set_slave_address(address, I2C_SEND);
    i2c_master_data_put(reg);
    i2c_master_command(I2C_MASTER_CMD_BURST_SEND_START);
    if (while_busy()) return I2CM_STAT_BUSBSY;
    i2c_master_data_put(val);
    if (while_busy()) return I2CM_STAT_BUSBSY;
    return I2C_MASTER_ERR_NONE;
}

Thanks!!

[medmig]

Hi @dazhbog ,

Sorry I'm late, and I agree with you, because the waiting loop is an active loop, the watchdog may reboot. I have no sufficient experience to say if it's a good thing to had a timeout, and if the way you do this is the good way, but I think it can be a good idea (even if I think that the waiting loop should be finished (the I2C should be free) before the watchdog reboot).

Also, there are differents way to send data to a device, depending on the number of bytes you want to send. I've written few examples, but if they didn't help you, I suggest that you read the TI CC2538's documentation to get more precisions about the differents way to send data. If you want to send more than 1 byte you will have to use the i2c_master_command function, combined with the I2C_MASTER_CMD_BURST_SEND_* defines. Otherwise, you can use the i2c_single_send function.
In fact, the method to use depends of your slave (if he is waiting for a STOP or not, etc.), and if you are waiting for data in response or not, etc. In your case, I think that you should add "i2c_master_command(I2C_MASTER_CMD_BURST_SEND_FINISH);" or "i2c_master_command(I2C_MASTER_CMD_BURST_SEND_CONT);" after the second "i2c_master_data_put".

I'm sorry if I'm confusing, but I'm not working on this project anymore, and I'm not an English native speaker. I'll try to answer faster if you have any other question.

PS : I'm glad this code was usefull for someone :)

[g-oikonomou]

Hi, @medmig. We're looking at this now and it seems to work fine. We'll probably open a new PR based on this one since you are not working on this.

I see there is no license header in the .c file. Can you confirm that you're happy for this to be 3-clause BSD?

[medmig]

Hi, @g-oikonomou .
I confirm that I'm happy for this to be 3-clause BSD, and that someone works on it.

[bradjc]

@g-oikonomou Has there been any progress on this? The CC2538 should probably have an I2C library, even if it's not perfect.

[g-oikonomou]

#1005