I2C stehe auf dem Schlauch (CC430)

Hallo I2C,
ein wenig Code würde Dein Problem hier besser beschreiben.

Ich habe mir mal meinen Code für einen MSP430F2013 angesehen. Danach 
wird nach jedem empfangen Byte ein Ack gesendet und zum Schluss ein 
NAck.

#####################################
 case 6: // Receive Data Ack/Nack bit
    if (WriteMode)
      USICTL0 &= ~USIOE;         // SDA = input
    else
    {
      USICTL0 |= USIOE;          // SDA = output
      OutCode[pntOutCode++] = USISRL; // Lesen des empfangenen Bytes
      if (LoopsToRead > 0)
      {
        USISRL = 0x00;           // Send Ack,
        USICNT |= 0x01;          // Bit counter = 1, send Ack bit
        I2C_State = 8;           // Go to next state
        break;
      }
      USISRL = 0xFF;             // Send NAck, hier generell senden,
    }
    USICNT |= 0x01;              // Bit counter = 1, receive (N)Ack bit
    I2C_State = 8;               // Go to next state: check (N)Ack
    break;
#####################################

Dieser Code ist zwar den rudimentären Samples von TI entnommen, wurde 
von mir aber für Rx und Tx zusammengefasst und etwas ergänzt. Die 
damalige I2C-Lib bekam ich nicht zum Laufen. Heute sieht das aber 
bestimmt anders aus. Versuch mal die Lib einzusetzen.

mfg klaus.

USI (F2xx) ist nicht das gleiche wie USCI (CC430).

Siehe Abschnitt 24.3.4.1.2 und Abbildung 4-10 des User's Guide.
Ein ACK wird automatisch gesendet, wenn im Eingabepuffer Platz ist, weil 
deine Software das vorherige Byte aus UCBxRXBUF gelesen hat.
(Und mehr als ein Byte wird nicht gepuffert.)

Hallo Clemens,
ich bin zwar nicht der Ersteller des Threads aber ich werde mich 
demnächst auch mit einem cc430x513x befassen. Ich weiss noch welchen 
Aufwand (Try/Error) ich 2007/2008 betreiben musste um aus den 
TI-Samples, die sehr rudimentär gehalten waren und noch sind, etwas 
Lauffähiges wie für einen TMP102, bzw. dem DS1631, hinzubekommen.

In den TI-Samples wird zwar beschrieben wie man ein Byte zum Slave 
sendet, aber auch nur das. Und im anderen Sample, wie man ein Byte 
empfängt. Ja, und dann bastele mal dies zusammen zu einem Code und das 
noch für 16Bit-Anworten des Slave. Für einen damaligen Anfänger etwas 
Anspruchsvolles.

Ich habe mich in den letzten Tagen wieder wegen dem cc430x513x durchs 
Internet gewühlt um ein paar Samples zufinden. Vielleicht suche ich an 
den falschen Stellen.

Mir ging es für das erste darum:
-Über I2C bei einem TMP102 (12 Bit Temperatursensor) den Messvorgang
 einleiten
-Empfang der 2 Byte des Sensors

Beim MSP430F2013 läuft mein Code seit Jahren einwandfrei. Der 
Sample-Code für den cc430x513x sieht etwas anders aus.

Kannst Du mir Quellen nennen die mir weiterhelfen könnten?
mfg klaus

Normalerweise empfehle ich driverlib:
http://www.ti.com/tool/mspdriverlib
entweder direkt, oder den Quellcode als Vorlage nehmen.

Die CC430-Familie wird zwar von driverlib nicht direkt unterstützt, aber
das USCI-Modul ist das gleiche wie in der F5xx-Familie.
Siehe examples/MSP430F5xx_5xx/usci_b_i2c/ und
driverlib/MSP430F5xx_5xx/usci_b_i2c.*.

Für den TMP102 muss man ein Byte schreiben und dann sofort zwei Bytes
lesen. Das wären USCI_B_I2C_masterMultiByteSendStart() (nicht
…SingleByte(), damit kein STOP gesendet wird), und wenn das erledigt
ist, USCI_B_I2C_masterMultiByteReceiveStart(), und dann im Interrupt
USCI_B_I2C_masterMultiByteReceiveNext() oder
USCI_B_I2C_masterMultiByteReceiveFinish().

Und wenn das nicht weiter hilft, musst du dein Englisch ausgraben und
auf http://e2e.ti.com/support/microcontrollers/msp430/ nachfragen.

Das hättest du einfach im User's Guide, Abschnitt 24.4.9, nachlesen
können:
> The I2CSAx bits contain the slave address of the external device to be
> addressed by the USCI_Bx module. It is only used in master mode.
> The address is right justified. In 7-bit slave addressing mode, bit 6
> is the MSB and bits 9-7 are ignored.

Clemens L. schrieb:
> Normalerweise empfehle ich driverlib:
> http://www.ti.com/tool/mspdriverlib
> entweder direkt, oder den Quellcode als Vorlage nehmen.
>
> Die CC430-Familie wird zwar von driverlib nicht direkt unterstützt, aber
> das USCI-Modul ist das gleiche wie in der F5xx-Familie.
> Siehe examples/MSP430F5xx_5xx/usci_b_i2c/ und
> driverlib/MSP430F5xx_5xx/usci_b_i2c.*.

Das Beispiel driverlib/MSP430F5xx_5xx/usci_b_i2c.* hatte ich mir gestern 
schon mal angeschaut ...
>
> Für den TMP102 muss man ein Byte schreiben und dann sofort zwei Bytes
> lesen. Das wären USCI_B_I2C_masterMultiByteSendStart() (nicht
> …SingleByte(), damit kein STOP gesendet wird), und wenn das erledigt
> ist, USCI_B_I2C_masterMultiByteReceiveStart(), und dann im Interrupt
> USCI_B_I2C_masterMultiByteReceiveNext() oder
> USCI_B_I2C_masterMultiByteReceiveFinish().
>
... aber erst jetzt bin ich mir sicher es verstanden zu haben. Die LIB 
vereinfacht in der Tat den Umgang mit I2C.

> Und wenn das nicht weiter hilft, musst du dein Englisch ausgraben und
> auf http://e2e.ti.com/support/microcontrollers/msp430/ nachfragen.

Ja, das wird sich manchmal nicht vermeiden lassen.
Nochmals Danke, Du hast mir sehr geholfen.

mfg klaus

I2C schrieb:
> Wozu muss bzw. kann ich meinem Controller (Master) mitteilen, welche
> Adresse mein Sensor besitzt?

Der Controller sendet nach dem START automatisch die Slave-Adresse.

> was macht der CC430 Controller mit der 0x40, die ich in obigem Register
> mit angeben kann?

Er sendet es auf dem Bus, und hängt das R/W-Bit an.

Hallo I2C,
wenn Du die I2C-Lib verwendest dann hast Du mit den Registern direkt 
nichts mehr zu tun.
mfg klaus

Im I²C-Protokoll muss das erste Byte immer die Slave-Adresse sein,
deshalb kann der Controller sie automatisch senden. Die anderen Bytes
hängen von der Anwendung ab.

Der ergänzte Bit ist 0 beim Schreiben und 1 beim Lesen. (Auch bei einer
Lese-Transaktion sendet der Master die Slave-Adresse.)

Die oben erwähnten Links gelten auch für dich.

I2C schrieb:
> Der Family Guide weist darauf hin, dass das UCTXIFG ein rw-1 Bit ist,
> d.h. es ist immer high solange der TX-Buffer leer ist.
>
> Frage: Geht der Controller dann bei gesetztem TXIE in die ISR?
>
> Wie verhindere ich denn, dass dort kein permanentes Trap durch Sprünge
> in die ISR stattfindet?

Indem du etwas in the TX-Buffer schreibst, oder STOP sendest.

Beim STOP musst du das Interrupt-Flag manuell zurücksetzen.
Aus driverlib:

1

    //Send stop condition.

2

    HWREG8(baseAddress + OFS_UCBxCTL1) |= UCTXSTP;

3

4

    //Clear transmit interrupt flag before enabling interrupt again

5

    HWREG8(baseAddress + OFS_UCBxIFG) &= ~(UCTXIFG);

Das Datashit des HTU21D zeigt es nicht, aber in Bild 24-3 in Abschnitt 
24.3.2 des CC430 User's Guide sieht man es.

I2C schrieb:
> so, die Sendesequenz hin schaffe ich, aber mit der Antwort stimmt
> irgendetwas nicht:
>
> Senden tue ich:
>
> [S][1000.0000]{0-ACK}[1110.0011]{0-ACK}[S][1000.0001]{0-ACK}
>

So wie ich das sehe hast Du den Mode "No Hold Master communication 
sequence" gewählt. In dieser Tabelle sehe ich den Verlauf etwas anders.

[S][1000.0000]{0-ACK}[1110.0011]{0-ACK}
[S][1000.0001]{0-NACK}
[S][1000.0001]{0-ACK}

mfg klaus

I2C schrieb:
> Nach den 42ms sehe ich dann ein Signal auf dem Bus, und zwar geht die
> Taktleitung wieder auf low sowie die Clock fängt an zu laufen, dann sehe
> ich folgendes Signal:
>
> 1100.0100.1100.100

Mehr als 8 Bit sollten ohne ACK des Masters nicht gesendet werden.
Kannst du uns mal zeigen, was das Oszilloskop dazu sagt?

Hallo Clemens,

> Mehr als 8 Bit sollten ohne ACK des Masters nicht gesendet werden.
Ist aber so, siehe Datenblatt.

http://www.meas-spec.com/downloads/HTU21D.pdf, Seite 12.
mfg klaus

Klaus Ra. schrieb:
> Ist aber so, siehe Datenblatt.
> http://www.meas-spec.com/downloads/HTU21D.pdf, Seite 12.

Auf Seite 12 wird "No Hold master" beschrieben, was hier aber nicht
verwendet wird.

Und nirgendwo sehe ich mehr als 8 Datenbits vor einem ACK.

Clemens L. schrieb:
> Klaus Ra. schrieb:
>> Ist aber so, siehe Datenblatt.
>> http://www.meas-spec.com/downloads/HTU21D.pdf, Seite 12.
>
> Auf Seite 12 wird "No Hold master" beschrieben, was hier aber nicht
> verwendet wird.
>
Jau, ich habe mich mit dem F3 vertan.
mfg klaus