Hi Sebastian,

I'd spend a lot of time with the MasterPacketP, and never had such
problems. However your solution is not quite good. If the I2C is
really busy, your modification will abort the communication on any
request. Moreover, you're signaling readDone() from the read()
command, which can cause infinite loops, if anyone calls read again
from readDone.
If the errors is caused by a slow device, first try to slow down the
i2c clock in the HplAtm128I2CBusP with the TWBR, TWSR registers in the
I2C.init() function.

Andris

On Wed, Nov 23, 2011 at 4:15 PM, "Sebastian Dölker"
<[email protected]> 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;
>      }
>    }
>
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
> _______________________________________________
> Tinyos-help mailing list
> [email protected]
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to