Thank you for your answer.
I check with an oscilloscope and find out the bug.
It was in the code I wrote for managing the Digital I/O.
Very simple error but sometimes those are the most difficult to debug.
In fact once I I2C.Write a value on the Digital port the changed bit is of
course kept in the values that are I2C.Read later.
I changed the code making independent the I2C.Read from the first two bits
that are used for the Relays control, and that solved the problem.
Franco Di Persio.
-Mensaje original-
De: Michael Schippling [mailto:sc...@santafe.edu]
Enviado el: martes, 17 de julio de 2012 20:00
Para: francodipersio
CC: tinyos-help@millennium.berkeley.edu
Asunto: Re: [Tinyos-help] I2C problem in micaz and MDA300
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/mda3
00ca/
, 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
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
