Hi Kurt,
I try to explain my situation better:
I use telosB(Tmote sky) and I connected digital sensor (I2C) on it through
the 6 and 8-pin expansion connector of the mote.
The same pins shared with the chip radio. You can see that on datasheet of
tmote sky, pag 21.
I hope you can explain me better your opinion.

best,
T.


2009/9/5 KURT PETERS <[email protected]>

>  I highly doubt the MSP 430 uses the same i/o lines for the SPI bus and the
> I2C bus.  Therefore I don't think you have to worry about contention.  I
> haven't looked at the schematics, but the MSP430s I've used have them on
> totally different I/O lines.
> K
>
> ------------------------------
> Date: Fri, 4 Sep 2009 23:51:16 +0200
> Subject: Re: [Tinyos-help] I2C examples (Michael Schippling)
> From: [email protected]
> To: [email protected]; [email protected]
>
>
> Hi Kurt,
> thank you so much for your suggestion but unfortunately I didn't find the
> example you mention.
> I've just solved that problem, but now I'm working to operate the
> "arbitration" between my sensor (digital compass HMC6343) that use the USART
> bus in I2C mode and the chip radio (CC2420) that use the same bus in SPI
> mode, both should communicate with the microprocessor (MSP430). I use TinyOS
> 2.
>
> I'm in trouble with this, can you help me with some suggestions or
> examples?
>
> Best regards,
>
> Tommaso Montisci.
>
>
>
> 2009/8/25 KURT PETERS <[email protected]>
>
>  Depending on the version of tinyos you're using, the 7 bit addressing was
> fixed to conform to standards around the 2.1 version. Besides this, there
> was an error in implementation of reading and writing such that you
> shouldn't use an odd address because it was not masked correctly.  I pointed
> this out about 3 years ago and you should be able to find it in the
> archives.
> Regards,
> Kurt
>
> > Date: Mon, 24 Aug 2009 16:27:28 -0600
> > From: Michael Schippling <[email protected]>
> > Subject: Re: [Tinyos-help] Fwd: I2C examples
> > To: Tommaso Montisci <[email protected]>
> > Cc: [email protected]
> > Message-ID: <[email protected]>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > 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]>>
> > >
> > > 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]
> > >
> > > 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.
> > >
> > >
>
> > > <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
>
>
> _______________________________________________
> 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

Reply via email to