I2C i2cBusSetBitRate() library call not working on AXON2

[oscar]

OK, so here is the issue. The guys in the robot club in school are interfacing some i2C NXT sensors to the AXON2. The IC2 bus works and the NXT compass sensor works fine (it's set as a generic device). However, the IR sensor does not and the reason according to MindSensors is that the sensor can only run up to 10kbs. No problem you say, just set the AXON2 I2C bus to 10k using i2cBusSetBitRate(10). The Webbotlib documentation is a bit confusing as some places it says the parameter is in units of 100k. Which means that it cannot be set to less than 100k. It also states that to set it to 100kbs, you use 100, which would actually be 100x100k, which is 10mbs, which of course is not right. Ok, so that aside, they tried different speeds from 1 to 255 and monitored the clock rate using an oscilloscope. The kbps never changed! The wave form did differ slightly, but only in so far as how long the clock was high compared to how long it was low low. There was certainly no dramatic jump from 1kbs to 100kbs etc from what I saw.

i2cBusInit(&i2c);
i2cBusSetBitRate(10);

Note that the rate was set AFTER the bus is initialized.  (tried the other way around too for completeness but no joy as expected).  Also note that they are using the hardware I2C bus that allows the rate to be reconfigured. The software rate does not allow it to be changed.

So the the question is, has anybody changed the I2C rate and actually observed a symmetrical clocking frequency that followed the setting on a cro?. Also, is the parameter supposed to be in units of 100k or 1k? From what I see on the oscilloscope, there may be a problem with the library.

Help, the boys in the school are stuck and desperate!

Oscar

[oscar]

After a look at the source code in the library, and correct me if I am wrong, because it locks bits TWBS0/1 to 0 in the TWSR register, it restricts you to 62khz as there is no prescaler value as its 1. There is another issue, and again correct me if I am wrong. In the library routine (see below) it has declared bitrate_div as 8 bits. So, what would happen below if (cpu_speed_div_1000 / bitrateKHz) was greater than 255? Well, you'd get an overflow and the setting would end up all wrong. Eg, say if you had 160000/20, the answer is 800, or in hex 0x0320. This gets truncated to 0x20 and we end up with the wrong answer.

static void speed(const I2C_ABSTRACT_BUS* bus,uint16_t bitrateKHz){
   uint8_t bitrate_div;

   // set i2c bitrate
   // SCL freq = F_CPU/(16+2*TWBR))
   #ifdef TWPS0
      // for processors with additional bitrate division (mega128)
      // SCL freq = F_CPU/(16+2*TWBR*4^TWPS)
      // set TWPS to zero to make = F_CPU/(16+2*TWBR)
      cbi(TWSR, TWPS0);
      cbi(TWSR, TWPS1);
   #endif
   // calculate bitrate division
   bitrate_div = cpu_speed_div_1000 / bitrateKHz;
   if(bitrate_div >= 16)
      bitrate_div = (bitrate_div-16)/2;
   outb(TWBR, bitrate_div);
}

So I reckon that if you need to set the I2C speed, you should load the registers directly yourself (check out the PDF on the ATmega640). The registers are TWBR (0xB8) and TWSR (0xB9). Rant over! Would welcome any comments as if this is all OK, then it should be flagged as a problem. Anyway, with some luck, this should get the guys sorted.
Oscar

[Webbot]

Well spotted. It was more of an oversight on my behalf - all the stuff I'd seen used 100kbps or 400kbps and the software works fine with 100 and 400 as parameters.
You problem arises as you are passing a value of 10 and so yes it doesn't work properly.

So just to clarify the speed parameters in in 'kilo bits per second'.

Anyway - fixed in next release of code and docs.

[Webbot]

Fixed in release 1.32 or 2.05