I'm not sure what you mean by "slow", but here's something to check...
The T1 version of I2C for the ATmega used bit banging on the TOS
side rather than the controller's I2C hardware -- go figure....
I found that it didn't recognize a "wait-state-request" from
external devices and would lose a bit when reading -- for the
particular device I was using, an SC18 SPI->I2C converter --
which would make it lose message sync and fail. I don't remember
the details, I think the external device can hold one of the
lines to signal that it's not ready -- I made up the name above
but that's what it's doing -- digging through the I2C spec should
turn it up. I fixed it by putting a short busy wait at the end of
each i2c_ack() which slows everything down but makes it work.
If you think this is what you have I can try to find more details.
MS
Sebastian Dölker wrote:
>
> Hello!
> I have a problem with the Atmel128 i2c environment.
> I want to read out the k30 co2-sensormodul from senseair.
> On this sensor the i2c communication is implemented in software.
> Because of that there is an advice in the datasheet
> that it might come to problems during the i2c communication
> caused by the long response time of the sensor.
>
> The problem was that after an undetermined time the atmel128 i2c
> components got in an incorrect state out of which the software can’t
> recover.The bus lines stayed high and the return value was EBUSY.
> The only way to make the software run fine again was to reset
> the node with the watchdog.
> However this solution is inadequately.
>
> I analyzed the Atm128I2CMasterPacketP Component and found out that
> while the node was in the incorrect state the Atm128I2CMasterPacketP
> returned with EBUSY in the else-block at line 220 in the I2CPacket.read()
> command.
> To solve the problem I added the i2c_abort(EBUSY) call in the else-block.
> (1,2)
> (same for the I2C.write() command, see software snippet below (2,3))
> After that it seemed to work fine.
> Now the software recovers out of the incorrect state.
>
> Had somebody else this problem or tested the atmel128 i2c components with
> slow i2c sensors?
>
> Is it possible that in this else-Block should be a call to the
> i2c_abort(EBUSY)-function?
>
>
> However there seems to be another bad state, which fortunately occurs more
> rarely.
> In this state the return value is EOFF and the bus lines also are in high
> state.
> I tried to add the i2c_abort-function in the else if block above,
> but this seemed not to solve the problem. (see the software snippet below)
>
> Has anyone an idea how to solve that problem?
>
> Best regards!
> Sebastian
>
>
> Modified Atm128I2CMasterPacketP.nc:
>
> async command error_t I2CPacket.read(i2c_flags_t flags, uint16_t addr,
> uint8_t len, uint8_t* data) {
> atomic {
> if (state == I2C_IDLE) {
> state = I2C_BUSY;
> }
> else if (state == I2C_OFF) {
> i2c_abort(EOFF); //added...1
> return EOFF;
> }
> else {
> i2c_abort(EBUSY); //added...2
> return EBUSY;
> }
> }
> ...
>
>
> async command error_t I2CPacket.write(i2c_flags_t flags, uint16_t addr,
> uint8_t len, uint8_t* data) {
> atomic {
> if (state == I2C_IDLE) {
> state = I2C_BUSY;
> }
> else if (state == I2C_OFF) {
> i2c_abort(EOFF); //added...3
> return EOFF;
> }
> else {
> i2c_abort(EBUSY); //added...4
> return EBUSY;
> }
> }
>
>
>
>
>
>
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
