The Atm128rfa1 has a nbew i2c implementation, which should work with atm128. You should contact Andras Biro about it. Miklos
On Wed, Feb 13, 2013 at 3:00 AM, Eric Decker <[email protected]> wrote: > > oops. > > shouldn't be hard but the h/w is different. I haven't studied the atm128 > i2c hardware so don't know. > > the key that makes the ti driver funky is the funky ti h/w. So if the > atm128 h/w is more straight forward and saner than the driver should be > saner too. > > It isn't hard. I'd recommend instrumenting the bus with a logic analyzer > and just rewrite the driver yourself. > > Studing my driver would be useful as I heavily comment. My driver is > production code. > > > On Tue, Feb 12, 2013 at 11:30 PM, He Dajiang (I2R) <[email protected]> > wrote: >> >> H Eric, >> >> Greatly appreciate your inputs. >> However, I am using micaz and its my only choice. How difficult is it to >> port ur driver to atm128? >> >> Best Regards >> >> ________________________________________ >> From: Eric Decker [[email protected]] >> Sent: Wednesday, 13 February, 2013 1:11:21 PM >> To: He Dajiang (I2R) >> Cc: [email protected] >> Subject: Re: [Tinyos-help] I2C read and write API >> >> Without watching the bus itself it is very hard to tell what is going >> wrong. >> >> The original TinyOS I2C drivers as far as I know were developed without >> looking at the bus traffic. >> >> I've rewritten the I2C drivers for the x5 series of chips (msp430f5438a, >> 6xxx, etc) and have verified under various circumstances the proper >> functioning of the driver using a logic analyzer observing the bus with the >> driver talking to various i2c devices that I'm using. >> >> The rewrite also includes the implementation of the I2CReg interface which >> provides a non-interrupt driven interface to accessing i2c devices that >> implement a register symantic. Non-interrupt because for short transactions >> the overhead of interrupts isn't worth it. Also because of the h/w >> structure of the i2c h/w, interrupts seriously complicates the proper >> functioning of the interface. (The data path is double buffered, but the >> control path isn't, not sure what they were thinking when they designed >> that, but it is what we've got). >> >> I sorted out the various issues with the data and control paths using the >> less complicated I2CReg code then applies what I learned to building a >> robust interrupt driven I2CPacket code. However, there are probable race >> conditions in a heavily loaded system that presents systemic problems for >> the interrupt code because of the fundamental h/w issues with double >> buffered data and single buffered control paths. So I've fixed I2CPacket >> (interrupt driven) as far as I could and added a robust I2CReg interface >> that should always work. >> >> >> This driver is in the tos/chips/msp430/x5xxx/usci-v2 directory of the >> tp-master branch (default) of >> gh:tp-freeforall/prod(tp-master)<https://github.com/tp-freeforall/prod>. >> >> >> Porting the usci-v2 driver to the x2 chips should be reasonably easy. >> Porting to x1 (1611) will be more difficult. See >> tos/chip/msp430/{00_Chip_Notes,01_Dependencies,02_Serial} for details about >> differences. >> >> Institute for Infocomm Research disclaimer: "This email is confidential >> and may be privileged. If you are not the intended recipient, please delete >> it and notify us immediately. Please do not copy or use it for any purpose, >> or disclose its contents to any other person. Thank you." >> >> _______________________________________________ >> Tinyos-help mailing list >> [email protected] >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > > > -- > Eric B. Decker > Senior (over 50 :-) Researcher > > > _______________________________________________ > 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
