Try to compare the low level I2C code and see what's different
between T1 and T2. I think the last version of T1 had the
atmega code in:
tinyos-1.x/tos/platform/avrmote/HPLI2CM.nc
If you search for "schip tinyos I2C" you'll find some help list
discussion of my battles with the Moteworks all-in-software
bit banging code used by the iris in:
MoteWorks/tos/platform/atm128/I2CM.nc
Specifically the spec calls for a "wait state" mechanism driven
by the slave device which was not implemented in the software.
I would hope that a hardware impl does this correctly, but who knows...
I found this datasheet to have a good description of I2C operation
if you need to start poking an oscilloscope or logic analyzer at it:
http://www.nxp.com/acrobat_download/usermanuals/UM10204_3.pdf
MS
francodipersio wrote:
> Hi,
>
>
>
> I am using Micaz and Tinyos-2.1.1 together with the MDA300 sensorboard.
>
> Taking as base the code from
> http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x-contrib/uoit/mda300ca/
>
> , I am actually trying to complete the driver for controlling the
> 8-Channel Digital I/O.
>
> On MDA300 the hardware component proposed for the 8-Channel Digital I/O
> is the PCF8574A and its work via the I2C interface. Two of the 8
> channels are used for controlling two Relays.
>
> In order to control the I2C bus I am using the codes from
> …tos\chips\atm128\i2c (by the way, I have downloaded the last version
> from the trunk).
>
> At power on, the 8 channel ports on the PCF8574A are high (value 0xFF)
>
> I have no problem in reading the data from the device, once an Interrupt
> change from high to low the correspondent pin on the 8 channel ports,
> but the problems arise when I try to write on the device in order to
> control the two relays. In this case the PCF8574A stop to work. I am
> sure is not a hardware problem, because with the Tinyos-1.x everything
> is working properly.
>
> In order to debug the problem I check the Atm128I2CMasterPacketP.nc
> file, but apparently everything goes smoothly being the status codes
> called by I2C.status the proper ones (table 88 – Status Codes for
> Master Transmitter Mode in the ATmega128 Manual) along the writing process.
>
> So, I presume that something wrong is happening after data has been
> transmitted and ACK has been received, thus during and after the STOP
> condition is sent.
>
> Also I have noted that the data is reaching the device, because I
> verified that the correspondent bit on the PCF8574A port is effectively
> changed, but after that the device become irresponsive. Also, if I try
> to write the default value (0xFF) and in this case everything go fine
> and the device keep working.
>
>
>
> Somebody has any idea how to solve the problem?
>
> There is a way with the Atm128I2CMasterPacketP to check the status just
> before and after the STOP condition is sent?
>
> I should check with an oscilloscope the I2C behaviour, but I am not so
> familiar with them, so I hope to solve the problem in other way.
>
>
>
> Thank you in advance
>
>
>
> Franco Di Persio
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
