i2c question

[Todd Allen-2]

Hi,

I'm working on an open source wind data logger (see sourceforge
"osdatalogger"), and I'm having a bit of trouble getting i2c bus
communications working properly.  It's the simplest configuration possible,
a single master (a MSP430F2619) talking to a single slave (a Ramtron FM6124
event data recorder).  Everything seemed to be working fine until I
simulated a 100 mph wind on all six channels (60 Hz events on each
channel).  I'm getting sporadic NACKs.  I'm running the i2c clock at 100
kHz.  If I slow the clock down to 25 kHz things seem to work fine, as far as
communications go, but I can't keep up with the events (the FM6124 fills up
in a second).

The MSP430X2xx user's guide section on i2c is at best confusing.  According
to the diagram for master transmitter mode, you can't get the ACK from the
slave address until you've stuffed a data byte into the transmit buffer.
>From there on, it's not clear to me whether I'm getting the ACK/NACK for the
byte I just wrote or the previous byte.

I can't seem to find any examples of working code out there that's not a
bit-banging approach, which I'm trying to resist because I want the i2c
clock to go at its maximum of 100 kHz and I don't want to muck around with a
'scope and NOPs and all that.  Does anyone have a working example using the
interrupt flags provided by the i2c module, either using interrupts or
polling the flags?

Thanks,
Todd
**

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Hans Nieuwenhuis-2]

Hi,

On Fri, 2 Oct 2009 12:53:16 -0400
Todd Allen <mspgcc@...> wrote:

> Hi,
>
> I'm working on an open source wind data logger (see sourceforge
> "osdatalogger"), and I'm having a bit of trouble getting i2c bus
> communications working properly.  It's the simplest configuration
> possible, a single master (a MSP430F2619) talking to a single slave (a
> Ramtron FM6124 event data recorder).  Everything seemed to be working
> fine until I simulated a 100 mph wind on all six channels (60 Hz events
> on each channel).  I'm getting sporadic NACKs.  I'm running the i2c
> clock at 100 kHz.  If I slow the clock down to 25 kHz things seem to
> work fine, as far as communications go, but I can't keep up with the
> events (the FM6124 fills up in a second).
>

Just from the top of my hat: if I am correct you'll have to keep polling
until you receive an ACK when you are writing data to the device before
you can write more data. It is a while ago since I last used an i2c
device and I got the same issue. OTOH the Ramtron devices claim to be
faster than ordinary 2416s, they are NVRAM's after all. You could try to
setup the simulation in a way to verify the written data afterwards.

BTW: just read about a typhoon somewhere in the pacific last night where
wind speeds are up to 130 mph...

> The MSP430X2xx user's guide section on i2c is at best confusing.
> According to the diagram for master transmitter mode, you can't get the
> ACK from the slave address until you've stuffed a data byte into the
> transmit buffer.
> >From there on, it's not clear to me whether I'm getting the ACK/NACK
> >for the
> byte I just wrote or the previous byte.
>

I2C is confusing compare to SPI.

> I can't seem to find any examples of working code out there that's not a
> bit-banging approach, which I'm trying to resist because I want the i2c
> clock to go at its maximum of 100 kHz and I don't want to muck around
> with a 'scope and NOPs and all that.  Does anyone have a working
> example using the interrupt flags provided by the i2c module, either
> using interrupts or polling the flags?
>
> Thanks,
> Todd
> **
>

Regards,
Hans

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[JMGross]

Hi!

I too was very confused about the I2C hardware (in the 1611) when I had to exchange data with an I2C RTC module.
I found that setting up the transfer and handling it was way too complicated for a few bytes. Or even did not properly fit for some devices (where you first send a byte to set the start address, then switch to read mode)
Maybe with continuous data streams or large data chunks and together with DMA it might be worth the effort, but just for writing or reading one byte or two, doing it by direct port pin manipulations is far easier - at
least if you're the only master :)
I ended up with a software I2C function set (the UART does better when used as SPI ).
Depending on your clock speed, you can be quite fast and have full control over transfer and handshake.

Anyway its strange that it works at 25kHz clock and not at 100kHz.
even 60 events per channel and 6 channels is just 360 events/s, leaving you with 3ms per event, which is lots of time to do things, even manually.

Some wild guesses:
Are you sure about the clock speed? Maybe you just THINK it is 100kHz but it is far more? And the client cannot keep up...
Do you react to transmit buffer empty fast enough? If not, you're getting a transmit buffer underflow error (which shouldn't be a problem on I2C as it is a synchroneous transfer)
Are you using the correct operation mode? All these multi-master stuff can mess things up. Trouble is just one wrong bit away :)
Is your hardware properly built? (pullups/line termination)? Some things cause trouble at higher speeds but do not show on lower speeds.

Good luck!

JMGross

----- Ursprüngliche Nachricht -----
Von: Todd Allen
Gesendet am: 02 Okt 2009 18:53:16

Hi,

I'm working on an open source wind data logger (see sourceforge
"osdatalogger"), and I'm having a bit of trouble getting i2c bus
communications working properly.  It's the simplest configuration possible,
a single master (a MSP430F2619) talking to a single slave (a Ramtron FM6124
event data recorder).  Everything seemed to be working fine until I
simulated a 100 mph wind on all six channels (60 Hz events on each
channel).  I'm getting sporadic NACKs.  I'm running the i2c clock at 100
kHz.  If I slow the clock down to 25 kHz things seem to work fine, as far as
communications go, but I can't keep up with the events (the FM6124 fills up
in a second).

The MSP430X2xx user's guide section on i2c is at best confusing.  According
to the diagram for master transmitter mode, you can't get the ACK from the
slave address until you've stuffed a data byte into the transmit buffer.
>From there on, it's not clear to me whether I'm getting the ACK/NACK for the
byte I just wrote or the previous byte.

I can't seem to find any examples of working code out there that's not a
bit-banging approach, which I'm trying to resist because I want the i2c
clock to go at its maximum of 100 kHz and I don't want to muck around with a
'scope and NOPs and all that.  Does anyone have a working example using the
interrupt flags provided by the i2c module, either using interrupts or
polling the flags?

Thanks,
Todd


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users