Hi Tommaso, in the "read" command of your sensor driver you should only call the stop command of the radio splitcontrol. Then in the radio "stopDone" event your would call the i2c resource request. Finally, in the i2c resource "granted" event you will execute the actual sensor reading. That should be quite straightforward!
Cheers, Raffaele 2009/8/25 Tommaso Montisci <[email protected]> > Hi Michael, > Thank you very much for your suggestion, now It seems to work all right! > I would have never thought that the solution could be so easy! :-) > Now I'm making some experiments to read and write from my compass, but I'm > in troubles again with the arbitration between RadioChannel (CC2420-chip > using SPI mode) & my sensor (HMC6343 using I2C mode) infact in my > platform(Tmote sky) the same pins are shared between i2c, usart, and spi > buses. I'm taking as reference for arbitration the tep108. Do you think I > should turn off the radio chip cc2420, or is enough to request the i2c > resource and then release it? I tried this second case but I have problems > because neither the i2c nor the radio works (if I turn off the radio all > work, but this solution seems too bad to me...!). > > Bye, and thanks again for the shift thing!!!! > > Tommaso. > > > > > 2009/8/25 Michael Schippling <[email protected]> > >> Can't make any sense of the picture, but (0110010) is 0x62... >> The issue is when the datasheet says an address of 0x32, >> has it been shifted up to account for the rd bit? And/or >> is the I2C system "helping" you by doing a shift that >> you don't know about? Now you seem to be getting a response >> so maybe we've stumbled onto the right incantation... >> >> MS >> >> Tommaso Montisci wrote: >> >>> So, I told you 0x32 because in the datasheet of the compass I read (page >>> 8): >>> >>> >>> 'All bus transactions begin with the master device issuing the start >>> sequence followed by the slave address byte. The >>> address byte contains the slave address; the upper 7 bits (bits7-1), and >>> the Least Significant bit (LSb). The LSb of the >>> address byte designates if the operation is a read (LSb=1) or a write >>> (LSb=0). At the 9 th clock pulse, the receiving slave >>> device will issue the ACK (or NACK). Following these bus events, the >>> master will send data bytes for a write operation, or >>> the slave will clock out data with a read operation. All bus transactions >>> are terminated with the master issuing a stop >>> sequence.' >>> >>> That's why I thought to have 0x32 (0110010) +0 for write +1 for no ack. >>> I tried now to send, as you suggested me, 0x32>>1 = 0x19 (of course with >>> my way of counting, probably wrong). >>> The big surprise (now is why I told that my way of counting is wrong) is >>> that now I have a lot of output, with the scl pin that is set to low. So >>> something seems to happen sending 0x32 in your way of counting(probably >>> right), but still, why now I have the scl pin down 'forever'? >>> I attach another picture from the oscilloscope to better explain the >>> situation. >>> Thank you very much, I did not know what to do and now something has >>> changed! >>> >>> Tommaso >>> >>> 2009/8/25 Michael Schippling <[email protected] <mailto: >>> [email protected]>> >>> >>> >>> If I read that trace right you have a 0x64, not 0x32 on the bus. >>> Could be wrong, but is consistent with 32 << 1 in the wrong place... >>> MS >>> >>> >>> Tommaso Montisci wrote: >>> >>> Hi Michael sorry I've sent the wrong file!!! >>> Yes the slave address should be shifted, infact the 2 last bits >>> are the r/w bit and the ack (not received...). >>> The 0x32 address should be after shifting, is a 7 bits address. >>> I send the address through the I2CSA register, after sending the >>> start condition. What I would expect is an ack so that then I >>> can send my data (a reading command for example). >>> Also there should be no conflict on the bus, because I turned >>> off other chips (I use a tmote sky, so the usart bus is shared >>> with the radio chip cc2420, which I disabled to avoid conflicts >>> of any kind). >>> Regarding the pullup resistances, I use the compass with an >>> evaluation circuit, with capacitors and resistances following >>> the datasheet (page 6). >>> let me know if you have some ideas, also about the picture... >>> >>> I don't do robotics, I do telecommunication but for a project I >>> have to develop a sensorboard with this compass, an >>> accelerometer, and a gyroscope. >>> >>> Thanks, >>> >>> Tommaso >>> >>> 2009/8/24 Michael Schippling <[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> >>> <mailto:[email protected]>>> >>> >>> >>> Actually I don't see anything but a straight line on the >>> Oscope trace, >>> but that could just be me... >>> >>> The slave address needs to be shifted up one bit in the first >>> byte sent, >>> because the LSB (bit 8) is the rd/bar-wr bit. It's not clear >>> to me if >>> that is what you are doing (because I can't see anything in the >>> picture). >>> Perhaps that is what you mean by "0x32 followed by a 0 and a >>> 1 (no >>> ack)"... >>> >>> It is also not entirely clear from the spec sheet if the 0x32 >>> slave >>> address is before or after shifting, have you tried both? >>> >>> I'm not familiar with the telos/MSP in this respect. You're >>> sure that >>> there is no conflict on the I2C bus, and also that you have >>> the pull- >>> up resistors in place? >>> >>> Looks like a nice compass chip. You doing robotics? >>> MS >>> >>> >>> >>> Tommaso Montisci wrote: >>> >>> I'm using the I2C part of the MSP430 datasheet and it >>> seems very >>> clear: >>> http://focus.ti.com/lit/ug/slau049f/slau049f.pdf >>> From my oscilloscope (scl , sda) the synchronization >>> between >>> clock and data seems ok, has you can see in the picture >>> attached. >>> There should be an ack there on the 9th bit? >>> The slave address should be ok, 0x32, the default address >>> standing at the datasheet >>> http://www.magneticsensors.com/datasheets/HMC6343.pdf >>> >>> From the picture we can recognize the bits and indeed it >>> is >>> 0x32 followed by a 0 and a 1 (no ack). >>> >>> I do not know what to do... >>> >>> thanks, >>> Tommaso >>> >>> >>> 2009/8/24 Michael Schippling <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> <mailto:[email protected] <mailto:[email protected]> >>> >>> <mailto:[email protected] <mailto:[email protected]>>>> >>> >>> >>> This is the I2C spec for the chip I was fighting: >>> >>> http://www.nxp.com/acrobat_download/usermanuals/UM10204_3.pdf >>> It has a (to me) useful description of the spec and >>> clock/data sequence. >>> Careful comparison to your observations might turn >>> something up. >>> Pay attention to the relationship between clock and >>> data...IIRC the >>> data must be stable the entire time the clock is >>> active (high >>> or low, >>> I don't remember for sure...) >>> >>> Are you sure you are sending the right slave address? >>> If the >>> target >>> doesn't agree it won't respond. >>> >>> Is your TOS MSP I2C implemented in hardware or software? >>> >>> MS >>> >>> >>> Tommaso Montisci wrote: >>> >>> Hi Michael, thanks for your answer. >>> >>> I try to explain you my problem: >>> I'm able to send the START condition and the slave >>> address, but >>> I receive no ACK from my sensor(HMC6343 >>> digital-compass). >>> I know >>> that I have sent the right-byte through the >>> Oscilloscope. >>> Without the acknowledgment it seems that I'm not >>> able to sent >>> further data to my device (is it true that I need >>> the ack >>> before >>> sending data?). >>> >>> Have you any suggestions? >>> >>> best, >>> Tommaso. >>> >>> >>> 2009/8/23 Michael Schippling >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> >>> <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>>>> >>> >>> >>> >>> I discovered a "lapse of implementation" in the >>> T1 >>> atmega I2C >>> implementation, which is BTW entirely done in >>> bit-banging >>> software. >>> I don't use or have access to a T2 tree and >>> haven't >>> looked at the >>> MSP implementation, but I might be able to help >>> if you >>> describe >>> your problem. >>> >>> My problem was when reading multi-byte data from >>> an >>> I2C device. >>> According to the spec the slave can request a >>> "wait-state" >>> between >>> bytes. The TOS code was ignoring this and >>> getting out >>> of bit >>> sync. >>> >>> MS >>> >>> Tommaso Montisci wrote: >>> >>> Hi all, >>> >>> I'm working to write TinyOS 2.x drivers for a >>> 3-axiss digital >>> compass(HMC6343). >>> This sensor communicates via a two-wire I2C >>> bus >>> system as a >>> slave divice with a microprocessor MSP430. >>> I would like to know if someone just >>> working in >>> similar >>> context >>> couse I'm in trouble to recive the ack from >>> the >>> compass. >>> >>> Thanks, >>> >>> Tommaso Montisci. >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> Tinyos-help mailing list >>> [email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>> >>> <mailto:[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> <mailto:[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>> >>> <mailto:[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[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 >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
