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
