Verständnisfrage I²C

Nachdem Stafen so tolle Hilfe bei SPI bekommen hat, frage ich jetzt mal nacj I²C: Gehe ich recht in der Annahme, daß der Master wissen muß, wie viele Daten der Slave schickt, oder kann er das irgendwie aus dem Datenstrom ableiten? Hintergrund: Beim "Spielen" mit I²C-gesteuerten Bausteinen möchte ich mir einen AtMega herrichten, dem ich I²C-Daten in ASCII seriell übergebe (z.B. "11 22 33") und an den Slave schicken kann und die Antwort wiederum in ASCII ausgegeben bekomme. Nur ... falls ich die Länge der Antwort vorher wissen muß, muß ich das in mein "Protokoll" mit einbauen.

Josef

--
These are my personal views and not those of Fujitsu Technology Solutions!
Josef Möllers (Pinguinpfleger bei FTS)
	If failure had no penalty success would not be a prize (T.  Pratchett)
Company Details: http://de.ts.fujitsu.com/imprint.html
Reply to
Josef Moellers
Loading thread data ...

Josef Moellers :

Das erkennt der Master am NoAck hinter dem letzten Byte. (Das ist ein Pegelwechsel auf SDA während SCL Low ist, glaub ich.)

M.

Reply to
Matthias Weingart

Matthias Weingart schrieb:

Wenn der Master von Slave liest, dann generiert doch der Master die ACKs bzw. das NAK. Der Slave hat afair keine Möglichkeit, einen Lese-Transfer abzubrechen. Aus der I2C-Spezifikation, Version 2.1:

| If a master-receiver is involved in a transfer, it must signal | the end of data to the slave-transmitter by not generating | an acknowledge on the last byte that was clocked out of | the slave.

Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x6DA025CA
Reply to
Christian Zietz

Am 04.04.2012 13:47, schrieb Josef Moellers:

Eigentlich muss der Master nur wissen, wieviele Daten er lesen möchte. Wenn es z.B. ein Speicherbaustein ist, muss der Master die Adresse des Slaves und die Adresse der auszulesenden Speicheradresse senden. Das letztere können je nach Baustein 8 oder 16 Bit Adressen sein.

Der Master kann dann noch jedes Byte einzeln addressieren, oder mehrere aufeinanderfolgende Bytes. Dabei muss man beachten, dass der Speicher in der Regel nicht komplett in einem Rutsch gelesen werden kann. Bei EEProms ist es (oft?) so, dass man an den Blockgrenzen, d.h. alle 128 Bytes neu adressieren muss.

Das gilt aber nur für Bausteine, die ähnlich wie EEProms angesprochen werden, ob es bei anderen Bausteinen andere Varianten gibt, weiss ich nicht.

Gruß

Stefan DF9BI

Reply to
Stefan

Christian Zietz :

Das gilt nur beim Rausschreiben von Daten. Beim Lesen macht das NACK der Slave.

Von

formatting link
"Eine Dateneinheit besteht aus 8 Datenbits = 1 Oktett ( welche protokollbedingt entweder als Wert oder als Adresse interpretiert werden ) und einem ACK-Bit. Dieses Bestätigungsbit (Acknowledge) wird durch einen Low- Pegel auf der Datenleitung von Seiten des Slaves während der neunten Takt- High-Phase (welcher nach wie vor vom Master generiert wird) und als NACK (für engl. not acknowledge) durch einen High-Pegel signalisiert. Der Slave muss den L-Pegel an der Datenleitung anlegen BEVOR der CLK auf High geht, andernfalls würden weitere eventuelle Teilnehmer ein ?STOP-Signal? lesen."

Und der Slave weiss durch das LSB der Adresse, ob es ein Lese- oder Schreibzugriff ist.

M.

Reply to
Matthias Weingart

Am 04.04.2012 14:14, schrieb Stefan:

Kann ich jetzt die Nummer nicht aus dem Kopf schreiben, aber es gibt WIMRE mindestens 2 Bausteine (Rotation- bzw. Beschleunigungssensoren), die die Registerinhalte rausspucken, solange kein Stopp-Signal vom Master kommt. D.h. ich (als Master) schicke ein Befehl: "schicke Register 0x20" und Slave schickt dann 0x20, 0x21 usw, solange kein ACK vom Master kommt. Dito beim Schreiben.

Waldemar

--
My jsme Borgové. Sklopte ?títy a vzdejte se. Odpor je marný.
Reply to
Waldemar Krzok

Am 04.04.2012 14:41, schrieb Matthias Weingart:

ACK.

Nein. Oben gesagtes gilt beim Lesen (Slave -> Master).

Das gilt nur beim Schreiben (Master -> Slave).

Allgemein erzeugt immer der Empfänger das ACK. siehe auch

formatting link
Kapitel

3.1.6

ACK.

@Josef: Der Master muss einen Lesezugriff mit NACK beenden. Im Normalfall weiß der Master vorher, wie viele Bytes er lesen will (jedenfalls war das bei mir bisher immer so).

Markus

Reply to
Markus Faust

Matthias Weingart schrieb:

Moment. Josef schreibt, dass der Slave Daten schickt. Also, Slave sendet, Master empfängt. Dann erzeugt der *Master* das ACK/NAK. Siehe die I2C-Spezifikation, die ich zitiert habe.

Selbst in dem von Dir verlinkten Wikipedia-Artikel steht das so drin: "Das ACK beim Schreiben wird vom Slave gesendet und beim Lesen vom Master. Das letzte Byte eines Lesezugriffs wird vom Master mit einem NACK quittiert, um das Ende der Übertragung anzuzeigen."

Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x6DA025CA
Reply to
Christian Zietz

Der Slave kann den Master nicht veranlassen, eine Leseübertragung abzubrechen.

Man kann in den Datenstrom sowas wie ein Längenbyte an den Anfang oder ein Terminierungsbyte ans Ende setzen, woran der Master erkennt, dass die Daten zuende sind.

Allerdings gibt es Controller mit I2C-Einheiten, die bereits vor dem Beginn einer Übertragung wissen wollen, wieviele Byte da drin sind, und dann die komplette Übertragung ohne weitere Eingriffsmöglichkeiten am Stück abfahren (z.B. OMAP4). Daher würde ich ein neu entworfenes Proto- koll zumindest nicht mehr so bauen, dass man einen Teil der Botschaft lesen muss, um die Länge zu erfahren.

Stefan

Reply to
Stefan Reuther

Naja, über "müssen" kann man streiten. Wenn der Master ein STOP generiert, ist Schluss, der Slave kann sich nicht bockig in die Ecke stellen "ich will aber mein NAK haben".

Stefan

Reply to
Stefan Reuther

Am 04.04.2012 16:40, schrieb Waldemar Krzok:

Der Master gibt das Clocksignal. Solange er das nicht tut schickt der Slave gar nichts - nur dass es keine Misverständnisse gibt. Und mit einem Stop-Signal vom Master sollte der Slave seine Mitteilungsfreudigkeit auch einstellen.

Gerlad

Reply to
Gerald Oppen

Doch, kann er, und einige Slaves machen das (z.B. LM75 von National).

Markus

Reply to
Markus Faust

Am 5.4.2012 schrub Markus Faust:

Ja, im konkreten Fall weiß man das, ich hatte aber an eine allgemeine Lösung gedacht, die automatisch erkennt, wie viele Daten der Slave zurückschickt.

Aus allem lerne ich, daß das nicht geht, ich muß also in meinem Protokoll explizit die Anzahl zu empfangenden Bytes vorgeben, so a'la

bedeutet "sende die 3 Bytes 34, 56 und 78 an Slave Adresse 12 und erwarte 4 Bytes vom Slave", wobei man das "S" streng genommen auch noch weglassen könnte.

Danke an alle,

Josef

--
These are my personal views and not those of Fujitsu Technology Solutions!
Josef Möllers (Pinguinpfleger bei FTS)
	If failure had no penalty success would not be a prize (T.  Pratchett)
Company Details: http://de.ts.fujitsu.com/imprint.html
Reply to
Josef Moellers

Am 5.4.2012 schrub Waldemar Krzok:

Auf jeden Fall macht z.B. der Chip auf dem Kompassmodul HDMM01 von Pollin das so.

Josef

--
These are my personal views and not those of Fujitsu Technology Solutions!
Josef Möllers (Pinguinpfleger bei FTS)
	If failure had no penalty success would not be a prize (T.  Pratchett)
Company Details: http://de.ts.fujitsu.com/imprint.html
Reply to
Josef Moellers

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.