Re: [Tinyos-help] Problems with Atmel128 I2C-Components (iris) with slow I2C sensors
I don't know if what you are working with uses hardware
or software (since I've only used T1) -- if you have started
with Moteworks you probably have T1...
Look at the low level driver and see. If it uses ATmega
hardware I would hope that it supports the "so called clock
synchronization mechanism".
Otherwise I put this in I2CM.nc to stretch the period
between bytes received a bit:
void i2c_ack()
{
MAKE_DATA_OUTPUT();
CLEAR_DATA();
pulse_clock();
SET_DATA(); // schip 8/12/09
TOSH_uwait(10); // -- to fix SC18 wait-state non-detect
}
MS
Sebastian Dölker wrote:
>
>
>
>
> Thank you for your quick reply!
>
>
>
> Yes I see my workaround isn’t such a good idea.
>
> With other I2C-Sensors (tsl2561 light sensor) I also hadn’t any problems
> and all worked fine. But with the k30 co2 sensor in particular something
> doesn’t work.
>
> I also tried to slow down the i2c clock but it didn’t help.
>
>
>
> The co2 sensor uses the so called clock synchronization mechanism.
> Is it what you mean Michael?
>
>
>
> This is described as follows in the I2C- Specification:
>
> “On the bit level, a device such as a microcontroller with or
>
> without limited hardware for the I2C-bus, can slow down
>
> the bus clock by extending each clock LOW period. The
>
> speed of any master is thereby adapted to the internal
>
> operating rate of this device.”
>
>
>
> Equally it is described in the atmel datasheet:
>
> “The slave can extend the SCL low period by
>
> pulling the SCL line low. This is useful if the clock
> speed set up by the master is too fast for the
>
> slave, or the slave needs extra time for processing
> between the data transmissions”
>
>
>
> Because of that I concluded that the Atml128-I2C components support this
> mechanism
> but now I’m not sure if it works fine.
> Have anybody successfully communicated with an i2c sensor
> that slows down the master clock with this mechanism?
>
>
>
> @michael
>
> Yes I think it is a related problem.
> If I don’t get it to work with the standard tinyos components I think
> bit banging will be the next step.
> Are there any sources? Can you give a hint?
>
>
> Best regards
> Sebastian
>
>
>
>
> ___
> 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
Re: [Tinyos-help] Problems with Atmel128 I2C-Components (iris) with slow I2C sensors
Thank you for your quick reply! Yes I see my workaround isn't such a good idea. With other I2C-Sensors (tsl2561 light sensor) I also hadn't any problems and all worked fine. But with the k30 co2 sensor in particular something doesn't work. I also tried to slow down the i2c clock but it didn't help. The co2 sensor uses the so called clock synchronization mechanism. Is it what you mean Michael? This is described as follows in the I2C- Specification: "On the bit level, a device such as a microcontroller with or without limited hardware for the I2C-bus, can slow down the bus clock by extending each clock LOW period. The speed of any master is thereby adapted to the internal operating rate of this device." Equally it is described in the atmel datasheet: "The slave can extend the SCL low period by pulling the SCL line low. This is useful if the clock speed set up by the master is too fast for the slave, or the slave needs extra time for processing between the data transmissions" Because of that I concluded that the Atml128-I2C components support this mechanism but now I'm not sure if it works fine. Have anybody successfully communicated with an i2c sensor that slows down the master clock with this mechanism? @michael Yes I think it is a related problem. If I don't get it to work with the standard tinyos components I think bit banging will be the next step. Are there any sources? Can you give a hint? Best regards Sebastian ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Problems with Atmel128 I2C-Components (iris) with slow I2C sensors
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
Re: [Tinyos-help] (no subject)
If by "open" you mean edit or view, and you are doing that by double clicking on the file in a GUI file manager, then it looks like the .nc file type is associated with some other kind of document. I don't know how Ubuntu's file manager works, but there should be some way to change that association to be your favorite programming text editor -- On Widows you right click and find an "Open With" menu entry that often has an option to select a program. Failing that you can open a shell window and try "vi [file]" or "emacs [file]". MS Rakshitha GB wrote: > hi, > i am installing Tinyos on Ubuntu using VMware. > if i open Blink or any .nc files, it gives error saying > "There is no application installed for Unidata NetCDF document files" > > i need guidence. > > > > > ___ > 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
Re: [Tinyos-help] Change IPv6 address for CoAP
> Hi guys, > > I would like to ask the following: In order to change the IPv6 > addresses that my WSN will use with CoAP does it suffice to set the > -DIN6_PREFIX and -DCOAP_CLIENT_DEST in apps/CoapBlip/Makefile and COAP_CLIENT_DEST only needs to be modified, if you are using the CoAP client, i.e. -DCOAP_CLIENT_ENABLED and -DCOAP_CLIENT_SEND_NI is set. This should be a routable address, where a CoAP server is listening and serving /ni. In other cases, changing IN6_PREFIX for CoAPBlip _and_ PppRouter should be enough. Markus > apps/PppRouter/Makefile or do I have to make any other adjustments? > > PS: Naturally, I also use the desired prefixes with pppd and when > adding the interface with ifconfig > > Thank you in advance! > Marios > ___ > Tinyos-help mailing list > Tinyos-help@millennium.berkeley.edu > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help | Dipl.-Ing. Markus Becker | Communication Networks | TZI - Center for Computing Technologies | University Bremen | Germany | web: http://www.comnets.uni-bremen.de/~mab/ | mailto: m...@comnets.uni-bremen.de | telephone: +49 421 218 62379 | building: NW1 room: N2260 ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Problems with Atmel128 I2C-Components (iris) with slow I2C sensors
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"
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
> 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
[Tinyos-help] Problems with Atmel128 I2C-Components (iris) with slow I2C sensors
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
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Call for proposals to host EWSN 2013
Call for Proposals to host the European Conference on Wireless Sensor Networks (EWSN) 2013 www.ewsn.org The European Conference on Wireless Sensor Networks (EWSN) is a leading international conference devoted to exchange of research results in the field of wirelessly networked embedded sensors. The EWSN Steering Committee is seeking proposals for hosting EWSN 2013. Such proposals should contain: * Description of the proposed venue (pictures help) * Reachability of the venue from Europe and the World * Options for accommodation in the vicinity of the venue, including approximate room rates * Options for social events * Names and short bios of the proposed general chair and program chairs * Outline of the conference budget including estimated registration fees * Research and industry activities related to EWSN in the vicinity Proposals should be sent by email as a single PDF file containing at most 6 pages to Kay Roemer by December 31, 2011. The EWSN steering committee will review all proposals and may contact the proposers to obtain additional information. Since 2004, EWSN has been annually held in February at European destinations including Berlin (Germany), Istanbul (Turkey), Zurich (Switzerland), Delft (The Netherlands), Bologna (Italy), Cork (Ireland), Coimbra (Portugal), Bonn (Germany), and Trento (Italy). It is a 2.5-day event with parallel tutorials in the morning of the first day, followed by a single-track technical program. An important element of the conference is a combined demonstration and poster session with typically 30-50 exhibits. The conference proceedings are published in the Springer LNCS series. In the past, the conference had 100-200 attendees and was typically held on a university campus to keep registration fees low. Dates: Submission deadline: December 31, 2011 Notification: January 2012 EWSN Steering Committee: Holger Karl, University of Paderborn, Germany Koen Langendoen, TU Delft, The Netherlands Kay Rˆmer, University of L¸beck, Germany Thiemo Voigt, SICS, Sweden Andreas Willig, University of Christchurch, New Zealand Adam Wolisz, TU Berlin, Germany -- Dr. Anna Förster PostDoctoral Researcher Networking Laboratory, SUPSI Via Cantonale, Galleria 2 Manno, Switzerland Tel. + 41 58 666 6597 http://www.dti.supsi.ch/~afoerste/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 10 DAYS TO DEADLINE: Call for Contributions EWSN 2012: Industrial Demos/ Research Demos / Posters
** CALL FOR INDUSTRIAL DEMO, RESEARCH DEMO AND POSTER CONTRIBUTIONS European Conference on Wireless Sensor Networks February 15-17, 2012 Trento, Italy IMPORTANT DEADLINES: Industrial Demo/Research Demo/Poster proposal due: December 5, 2011 Acceptance notification:December 15, 2011 All submission deadlines are at 23:59:59 UTC/GMT-11 hours (Samoa-Apia time, the last one to change the date on Earth). All deadlines are HARD No extension will be granted *** DETAILED INFORMATION on individual calls: *** Industrial demos: http://ewsn12.disi.unitn.it/callforindustrialdemos.html This year the EWSN conference will continue with the successful Industrial Demonstrations. The main goal for this session is to showcase industrial research and development in the area of wireless sensor networks, and to stimulate cooperation between industry and academia, especially small and medium enterprises. The purpose is also to increase the innovation strength of Europe and across the globe. *** Research demos: http://ewsn12.disi.unitn.it/callfordemos.html The demonstration session at EWSN is typically very well attended and is one of the highlights of the conference. If you are a systems researcher who is bored with producing slides, and you would rather show off great code, working systems, useful tools, crazy flying objects, new platforms, and any other technologies related to EWSN, then the demo session is the place for you! Submissions from industry and universities are encouraged! *** Posters: http://ewsn12.disi.unitn.it/callforposters.html The poster session at EWSN provides a forum for researchers to present their work and receive feedback from experts attending the conference. The areas of interest are the same as the main track (see the call for papers for details). We explicitly encourage submissions from students. *** -- Dr. Anna Förster PostDoctoral Researcher Networking Laboratory, SUPSI Via Cantonale, Galleria 2 Manno, Switzerland Tel. + 41 58 666 6597 http://www.dti.supsi.ch/~afoerste/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Change IPv6 address for CoAP
Hi guys, I would like to ask the following: In order to change the IPv6 addresses that my WSN will use with CoAP does it suffice to set the -DIN6_PREFIX and -DCOAP_CLIENT_DEST in apps/CoapBlip/Makefile and apps/PppRouter/Makefile or do I have to make any other adjustments? PS: Naturally, I also use the desired prefixes with pppd and when adding the interface with ifconfig Thank you in advance! Marios ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
