One more thing:
DiagMsg doesn't start the radio or the serial stack by itself, you
should do it manually.

Andris

On Wed, Nov 30, 2011 at 4:14 PM, András Bíró <[email protected]> wrote:
> Hello,
>
> On Wed, Nov 30, 2011 at 1:20 PM, "Sebastian Dölker"
> <[email protected]> wrote:
>> Hallo,
>>
>> unfortunately I wasn’t successfully in reading out the i2c_status..
>> I successfully included the dbgmsg-components but on the pc-side
>> I can’t receive dbg-messages.
>> (I use blip‘s ipbasestation ..does it work together?)
>
> If you haven't defined any DIAGMSG_ constant, it will send to the
> serial port. If you define DIAGMSG_RADIO, it will send through the
> radio with single hop broadcast (but I don't know if it will work blip
> together with blip). By the way: How do you use blip on iris? It's not
> supported yet (see the thread "IRIS support on current Blip Version")
>
>> If you want to reconstruct the i2c error you can manually pull
>> scl low for a long (ca. 2-3 sec) time, while you are reading out
>> an i2c sensor with a cycle time of 1 sec…
>> I think that will end in the same error state which occurs in
>> communication with the co2 sensor I’m using..
>
> Ok, now I really don't understand the problem.
> In your first mail, you wrote both lines stayed high. It means that
> the bus is busy, and the driver returns E_BUSY, as it should, but
> after i2c_abort(), everything is working again. The problem is
> probably a failed communication, which the driver couldn't handle, and
> still waits for an answer from the slave.
>
> Now you say I should pull the SCL line low, and use the i2c bus. This
> means HOLD MASTER. This is a signal generated by the slave, becouse it
> isn't ready for communication. The driver should wait with the first
> job while the SCL is low (and sends EBUSY to any new request), and as
> soon as the SCL is released it should do the first job.
> Do you say that the i2c is still busy after releasing the SCL?
>
>> I think it doesn’t make sense for me to go one trying to find
>> out where the problem in the communication between co2-sensor and
>> i2c-device driver is, because I don’t really overlook the i2c-device
>> driver..so first of all I think I should do the bit-banging workaround…
>
> It still be much easier to resolve this bug, if you could send me the
> debug output of the low level communication, and it might be easier
> than writing a bit-banging driver.
>
> Andris
>> Best regards
>> Sebastian
>>
>> --
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 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

Reply via email to