Forum: Mikrocontroller und Digitale Elektronik NXP PCA8574 hat Phänomen mit 2 Adressen


von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

ich habe mit jemand zusammen ein Controllerboard entwurfen und bin nun 
der Erste der testen kann. Derzeit bin ich beim ersten I2C Test.

Kennt jemand das Phänomen das sich ein NXP PCA8574 (Nachfolger vom 
PCF8574) mit 2 Adressen meldet?

https://www.nxp.com/products/interfaces/ic-spi-i3c-interface-devices/ic-general-purpose-i-o/remote-8-bit-i-o-expander-for-ic-bus-with-interrupt:PCA8574_74A

Controller: AVR128DB64

Ein Testprogramm Address-Scanner zeigt:
1
I2C Address Scanning...     7Bit      7Bit         8Bit
2
I2C device found at address 0x26 = B0010.0110 = B0100.110x ... U6:  PCA8574 (Portexpander)
3
I2C device found at address 0x48 = B0100.1000 = B1001.000x ... U8:  TMP101   (Temperatursensor)
4
I2C device found at address 0x50 = B0101.0000 = B1010.000x ... U9:  FM24W256 (256K FRAM)
5
I2C device found at address 0x51 = B0101.0001 = B1010.001x ... U10: AT24C256 (256K EEprom)
6
I2C device found at address 0x68 = B0110.1000 = B1101.000x ... U12: DS3231 (RTC)
7
I2C device found at address 0x73 = B0111.0011 = B1110.011x ... U7:  PCA9538 (Portexpander)
8
I2C device found at address 0x7C = B0111.1100 = B1111.100x ... U6 ???
9
10
U11 ist nicht bestückt.

Laut Datenblätter hat kein IC von denen 2 Addressen.
Um die Ursache für 0x7C herauszufinden habe ich folgendes getan.
Ich hatte U9 runtergelötet. 0x7C immer noch da.
Danach den U7 runtergelötet. 0x7C immer noch da.
Dann den U6 runtergelötet, 0x7C nicht mehr vorhanden. 'grübel'
Ich verstehe es nicht. Bis auf die RTC stammen alle ICs von Mouser.

Das Einzigste was man sich zusammenreimen könnte wäre, wenn man sich die 
Adressmöglichkeiten vom PCA8574A mit anschaut.
Würde vorraussetzen das der Adressdekoder eine Macke hat und ein Bit 
querliegt. Wenn man die Adressbits theoretisch auf den (A) ummünzt 
erhält man 0x3E. Schiebt man die Bits um eins nach links erhält man 
0x7C. Nur wäre das dann eine 7Bit Addressangabe auf 8Bit 
zurechtgeschoben. Bestimmt reine Spinnerei.

Zurück zur Frage. Kennt jemand das Problem mit einem PCA8574?

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hier noch das unspektakuläre Programm.

von Björn W. (bwieck)


Lesenswert?

Auch wenn ich dir bei deinem Problem leider nicht helfen kann, möchte 
ich mal Erwähnen das dein Schaltplan eine reine Augenweide ist.
Ganz im Gegensatz zu diesen Symbolsuchspielen die gefühlt immer öfter 
aus reiner Faulheit verbrochen werden.

von Veit D. (devil-elec)


Lesenswert?

Freut mich.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?


von Veit D. (devil-elec)


Lesenswert?

Hallo,

verstehe ich noch nicht ganz. 0x7C ist eine 7Bit Adressangabe. 
B0111.1100
Woher sollen die 10Bit stammen? Der Scanner fragt nur zwischen 1 und 127 
ab. Wenn ich den PCA8574 entferne stimmt alles. Er hat eigentlich nur 
eine Adresse und zwar 0x26. Ich verstehes leider immer noch nicht. 
Könntest du das bitte näher erklären?

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Veit D. schrieb:
> verstehe ich noch nicht ganz. 0x7C ist eine 7Bit Adressangabe.

Nein. Das ist eine im 7-Bit Adressraum unzulässige Adresse (bei 10-Bit 
lag ich falsch, die sind noch davor). Lass die reservierten Adressen in 
deinem Scanner weg, die ergeben keinen Sinn und sorgen nur für 
Verwirrung. Übrigens auch die vorne, also alle 1111XXX und 0000XXX.

https://www.totalphase.com/support/articles/200349176-7-bit-8-bit-and-10-bit-I2C-Slave-Addressing

Was bei den reservierten Adressen genau geschieht, das hängt von der 
Implementierung des I2C-Busmoduls in den Slaves ab. Manche werden das 
schlicht ignorieren, manche werden darauf reagieren. Das wird dann auch 
nicht notwendigerweise im Datasheet stehen, weil diese Adressen ja 
sowieso unzulässig sind.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

7Bit und 8Bit Adressen sind ja gleich, werden nur unterschiedlich 
dargestellt mit oder ohne R/W Bit. Wegen der 10Bit Reservierung. Wenn 
ich das richtig verstehe ist der Scanbereich meines Programm einfach nur 
zu groß eingestellt? Wenn ich mit 7Bit arbeite reicht 0x08 bis 0x77 aus? 
Ehrlich gesagt hatte ich bis jetzt von einer 10 Bit Adressierung noch 
nichts gehört oder gelesen.
Vielen Dank.

Dennoch muss ich nachfragen. Wenn die Adresse vom PCA8574 0010.0110 bzw. 
0100.110x lautet (7/8 Bit), dass liegt nicht im 10Bit Bereich, wie kann 
das IC dann auf 0111.1100 mit ACK reagieren?

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Veit D. schrieb:
> Dennoch muss ich nachfragen. Wenn die Adresse vom PCA8574 0010.0110 bzw.
> 0100.110x lautet (7/8 Bit), dass liegt nicht im 10Bit Bereich, wie kann
> das IC dann auf 0111.1100 mit ACK reagieren?

Falsche Perspektive. Versuch es, aus der Sichtweise des I2C-Busses zu 
betrachten. Die State-Machines der Busmodule der Slaves kriegen eine 
Bitfolge und müssen die interpretieren. Und wenn da vorneweg 4 Einsen 
kommen, dann bist du ausserhalb der Definition der 7-Bit Adressierung. 
Bei 11110 wird manches Modul das als Einleitung einer 10-Bit 
Adressierung betrachten und zusammen mit dem nächsten Byte als Adresse 
sehen. Und bei 11111 ist alles offen.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Veit D. schrieb:
> Wenn ich mit 7Bit arbeite reicht 0x08 bis 0x77 aus?

Korrekt.

von Bauform B. (bauformb)


Angehängte Dateien:

Lesenswert?

(prx) A. K. schrieb:
> Das ist eine im 7-Bit Adressraum unzulässige Adresse,
> weil dieses Bitpattern für die 10-Bit Adressierung verwendet wird.

Auf jeden Fall unzulässig bzw. reserviert. Aber der reservierte Block 
1111 ist nochmal unterteilt:
1
 1111 0xx   10-bit slave addressing
2
 1111 1xx   Read: device ID, z.B. Cypress FM24V(N)10
3
                  und scheinbar auch PCA8574(A)
Im PCA8574 Datenblatt Rev.03 wird das nicht erwähnt, aber in der Rev.02 
heißt es noch:
1
7.1 Device Address
2
When using the PCA8574A, the General Call address (0000 0000b)
3
and the Device ID address (1111 100Xb) are reserved and cannot
4
be used as device address. Failure to follow this requirement
5
will cause the PCA8574A not to acknowledge.
Vielleicht hat das nie richtig funktioniert und Papier ist doch 
leichter zu ändern als Silizium ;)

Beim Cypress FM24V10 ist die Abfrage offiziell drin, evt. kann man nach 
dem Schema dem PCA8574 auch etwas entlocken
1
Device ID
2
The FM24V10 device incorporates a means of identifying the
3
device by providing three bytes of data, which are manufacturer
4
ID, product ID, and die revision. The Device ID is read-only.
5
It can be accessed as follows:
6
1. The master sends a START command.
7
2. The master sends Reserved Slave ID F8h.
8
3. The FM24V10 sends an ACK.
9
4. The master sends the I2C-bus slave address of the slave device
10
   it needs to identify. The last bit is a ‘Don’t care’ value
11
   (page select and R/W bits). Only one device must acknowledge
12
   this byte (the one that has the I2C-bus slave address).
13
5. The FM24V10 sends an ACK.
14
6. The master sends a Re-START command.
15
7. The master sends Reserved Slave ID F9h.
16
8. The FM24V10 sends an ACK.
17
9. The Device ID Read can be done, starting with the
18
   12 manufacturer bits, followed by the 9 device identification
19
   bits, and then the 3 die revision bits.
20
10.The master ends the Device ID read sequence by NACKing the
21
   last byte, thus resetting the slave device state machine and
22
   allowing the master to send the STOP command.
23
Note The reading of the Device ID can be stopped anytime by
24
     sending a NACK command.
Ausnahmsweise, anlässlich dieser Geheimniskrämerei, hänge ich mal die 
kompletten Datenblätter an.

Edit: Mit den DAC101C081 ist mir ähnliches passiert. Die antworten auch 
auf eine Broadcast Adresse 1001'000.

: Bearbeitet durch User
von Wolfgang (Gast)


Lesenswert?

Björn W. schrieb:
> Auch wenn ich dir bei deinem Problem leider nicht helfen kann, möchte
> ich mal Erwähnen das dein Schaltplan eine reine Augenweide ist.

Es ginge sogar noch besser, wenn die Adress-Select-Pins (A0..2) in den 
Symbolen alle zusammen liegen würden (U9, U10, U11) ;-)

von Veit D. (devil-elec)


Lesenswert?

(prx) A. K. schrieb:
> Veit D. schrieb:
>> Dennoch muss ich nachfragen. Wenn die Adresse vom PCA8574 0010.0110 bzw.
>> 0100.110x lautet (7/8 Bit), dass liegt nicht im 10Bit Bereich, wie kann
>> das IC dann auf 0111.1100 mit ACK reagieren?
>
> Falsche Perspektive. Versuch es, aus der Sichtweise des I2C-Busses zu
> betrachten. ...

Ich habe das Problem als solches jetzt verstanden. Vielen Dank. Würde 
demzufolge bedeuten das man diesen PCA8574 nicht mit Bausteinen die 
10Bit Adressen haben auf dem gleichen Bus mischen darf. Das ist der 
erste IC der so reagiert den ich den Fingern habe. Ich würde als Laie 
behaupten wollen das der Adressdekoder von dem Teil eine kleine Macke 
hat.  :-)  Aber es ist wie es ist. Problem gelöst bzw. erklärt. Danke.

@ Bauform: Danke für die Info.

@ Wolfgang: ja, geht noch besser  :-)

von Bauform B. (bauformb)


Lesenswert?

Veit D. schrieb:
> Würde demzufolge bedeuten das man diesen PCA8574 nicht mit Bausteinen
> die 10Bit Adressen haben auf dem gleichen Bus mischen darf.

Warum? Der reagiert auf 11111xx, aber doch nicht auf 11110xx, oder?

Das I2C User Manual UM10204 sagt dazu:
1
3.1.11 10-bit addressing
2
The 10-bit slave address is formed from the first two bytes following
3
a START condition (S) or a repeated START condition (Sr).The first
4
seven bits of the first byte are the combination 1111 0XX of which
5
the last two bits (XX) are the two Most-Significant Bits (MSB) of the
6
10-bit address; the eighth bit of the first byte is the R/W bit that
7
determines the direction of the message.
8
9
Although there are eight possible combinations of the reserved address
10
bits 1111 XXX, only the four combinations 1111 0XX are used for 10-bit
11
addressing. The remaining four combinations 1111 1XX are reserved for
12
future I2C-bus enhancements.
UM10204 von 2014, damals gab's noch eine Zukunft ;)

von Peter D. (peda)


Lesenswert?

Veit D. schrieb:
> Würde
> demzufolge bedeuten das man diesen PCA8574 nicht mit Bausteinen die
> 10Bit Adressen haben auf dem gleichen Bus mischen darf.

Die 10 Bit sind nur eine spezielle Benennung für das Adreßbyte + 1. 
Datenbyte. Die eigentliche Chip-Adresse hat immer nur 7 Bit.

Daß sich Dein PCA8574 auf 2 Adressen meldet, hat damit nichts zu tun.
Es könnte ein Hardwareproblem sein, z.B. zu lange Leitungen, zu hohe 
Pullups.
Oder der Master sendet mit >100kHz oder ist buggy. Versuch mal den 
Master in Software mit Bit wackeln und Delays.

von (prx) A. K. (prx)


Lesenswert?

Veit D. schrieb:
> Ich habe das Problem als solches jetzt verstanden.

Nicht ganz.

> Würde demzufolge bedeuten das man diesen PCA8574 nicht mit Bausteinen
> die 10Bit Adressen haben auf dem gleichen Bus mischen darf.

Das ist kein Problem. Dein einziges Problem besteht darin, dass du den 
I2C-Master in einem unzulässigen Modus verwendest. Nämlich mit 7-Bit 
Adressierung und einer darin unzulässigen Adresse. Das gibt dann 
Missverständnisse zwischen Master und Slave, was den Verlauf des 
I2C-Protokolls angeht. Der Master meint, es wäre ein Frame mit 7-Bit 
Adresse und der Slave meint, es käme der von Bauform B beschriebene 
Device ID Zyklus.

: Bearbeitet durch User
von Peter D. (peda)


Lesenswert?

(prx) A. K. schrieb:
> Dein einziges Problem besteht darin, dass du den
> I2C-Master in einem unzulässigen Modus verwendest. Nämlich mit 7-Bit
> Adressierung und einer darin unzulässigen Adresse.

Nö.
Es sind alle 128 Adressen gültig. Daß bestimmte Bereiche nicht von 
dummen Slaves benutzt werden, schränkt nicht deren Verwendbarkeit ein. 
Mit einem MC als Slave können sie problemlos verwendet werden.


(prx) A. K. schrieb:
> der Slave meint, es käme eine 10-Bit Adresse

Nö.
Nur Slaves, die auch 10Bit Adressen benötigen, können diese vergleichen.
Alle anderen Slaves vergleichen nur die 7Bit-Adresse und fühlen sich 
nicht adressiert. Das folgende Datenbyte ist ihnen also schnurz.

Konflikte kann es nur dann geben, wenn man einen MC als Slave 
programmiert und ihm eine 7Bit-Adresse gibt, die auch für 10Bit-Slaves 
gültig ist und außerdem auch noch 10Bit-Slaves am Bus hängen.

Vom Prinzip her entspricht der 10Bit-Adreß-Mode der 11Bit-Adressierung 
eines 24C16 EEPROM. Die 11Bit-Adresse im EEPROM besteht dabei aus 3 Bits 
in der I2C-Adresse + 8 Bits aus dem 1. Datenbyte.

: Bearbeitet durch User
von Detlef (Gast)


Lesenswert?

Hallo Veit,

mit welchem Programm hast Du denn den schönen Schaltplan aus dem 
Eröffnungsposting gezeichnet?

von (prx) A. K. (prx)


Lesenswert?

Peter D. schrieb:
> Es sind alle 128 Adressen gültig.

THE I²C-BUS SPECIFICATION
VERSION 2.1
JANUARY 2000

Two groups of eight addresses (0000XXX and 1111XXX) are reserved for the 
purposes shown in Table 2.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

ich weiß gar nicht wie ich auf alles antworten soll. Ich versuche es.

Mein Adressenscanner scannt zwischen 100kHz und 400kHz. Alle ICs 
vertragen offiziell bis 400kHz. Da sehe ich kein Problem. Die falsche 
Adresse bekomme ich auch mit 100kHz angezeigt. Pullups wie im Schaltplan 
gekennzeichnet 4,7k. Zu lange Leitungen auf einer Platine 19x11cm 
schließe ich eigentlich auch aus. Master als Problem schließe ich 
eigentlich auch aus, weil das Problem genau auf den einen IC 
runtergebrochen werden kann und die ältere Platinenversion mit anderen 
bestückten I2C Bausteinen, unter anderem mit dem Vorgänger PCF8574(A), 
keine Probleme zeigt. Ich habe hier aktuell 6 I2C Bausteine drauf, da 
kann der Controller als Master eigentlich nicht das Problem sein, denke 
ich.

Jetzt stehe ich sowieso zwischen den Stühlen. Ich überlege mir erstmal 
in Ruhe was ich als Nächstes machen werde. Genügend Infos habe ich dank 
Euch. Theoretisch habe ich ja den PCA8574 selbst in Verdacht das sein 
Adressdekoder einen Bug hat. Alles Theorie.

Noch eine Anmerkung wegen "falscher 7 Bit Addressierung". Das kann ich 
verneinen. Ich gebe der Lib eine Adresse im 7 Bit Format mit. Die Lib 
fügt intern das R/W Bit passend hinzu damit es 8 Bit werden. Das passt 
schon - keine Sorge. :-)
Ich kann ja hier im Forum die Adressen im 7 oder 8 Bit Format angeben. 
Ich muss nur dazuschreiben ob es 7 oder 8 Bit sind. Das habe ich getan. 
Vielleicht zu ausführlich was ungewolltes Missverständnis erzeugte. ?

@ Detlef:
Das ist mit Protel 99 SE erstellt wurden. Der Vorgänger von Altium.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Es ist mir klar, was da abgeht, nachdem Bauform B den Passus zum Device 
ID Frame erwähnte, der in der Hardware des PCA8574 drinsteckt. Aber um 
das nachvollziehen zu können, muss man in der Lage sein, sich gedanklich 
von irgendeinem I2C-API zu lösen, muss das auf der Bitebene des 
I2C-Busses betrachten. Muss nachvollziehen, wie das Busprotokoll 
funktioniert, und was im I2C-Modul des Slaves geschieht, wenn vornweg 
diese 5 Einsen kommen.

Das ist keine Fehlfunktion, sondern dieser PCA8574 ist wahrscheinlich 
nur der einzige Slave, der überhaupt den Device ID Frame berücksichtigt. 
Das ist ja keine Pflicht. Die anderen Slaves ignorieren den.

Da ich bisher nicht in der Lage war, das für dich verständlich zu 
erklären, werde ich das nicht weiter vertiefen. Sondern nur die 
Empfehlung wiederholen, die reservierten Adressen auch so zu behandeln, 
d.h. nicht zu versuchen, sie abzufragen. So lange sich die Slaves nach 
der I2C-Spezifikation richten, wird sich im reservierten Bereich auch 
kein Slave befinden.

Ich hatte mich oben schon korrigiert, was die 10-Bit Situation angeht. 
Die käme bei 0x78 in Spiel. 0x7C ist der Device ID Frame. Bauform B hat 
netterweise auch genau dargelegt, wie das abläuft.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

ich sage mal so. Ein ordentlicher Adressdekoder ignoriert alles wenn 
sein Bitvergleich nicht stimmt. In dem obigen Passus steht das der 
PCA8574A nicht auf eine Bitfolge von 1111.100x reagiert, mein PCA8574 
non A reagiert jedoch.

Das mit der manufacturer ID, product ID und die revision Abfrage ist ja 
eine ganz andere Nummer. Dafür muss ja ein ganz bestimmtes Protokoll 
eingehalten werden. Das hat mit einfacher Adressabfrage "ist da jemand" 
nichts zu tun.

Egal, wir müssen uns deswegen nicht zerfleischen. Ich ignoriere den 
reservierten Bereich und gut ist. Das ist meine aktuelle logische 
Konsequenz, wenn ich derzeit alles andere als Fehlerquelle ausschließen 
kann. Wenn etwas anderes rauskommt melde ich mich. Es gibt auf der 
Platine noch einiges zu testen ...

In diesem Sinne, Danke an alle für die vielen Informationen. Ist alles 
sehr wertvoll. Nehmt es mir bitte nicht krumm.

von Bauform B. (bauformb)


Angehängte Dateien:

Lesenswert?

Veit D. schrieb:
> Das mit der manufacturer ID, product ID und die revision Abfrage ist ja
> eine ganz andere Nummer. Dafür muss ja ein ganz bestimmtes Protokoll
> eingehalten werden. Das hat mit einfacher Adressabfrage "ist da jemand"
> nichts zu tun.

Vielleicht sagt ein Bild mehr als tausend Worte. Das ist wieder vom 
FM24V10, aber das Protokoll ist ja "genormt".

Das Protokoll beginnt mit der 1111.1000. Als nächstes käme die normale 
Slave-Adresse, aber dein Scanner sendet die natürlich nicht. Also bleibt 
vom Protokoll nicht viel übrig -- außer eben dem einen ACK vom PCA8574.

Aus der Sicht des Slave ist das ein ganz normales ACK zu einem Byte, mit 
dem er etwas anfangen könnte. Der Scanner sollte das so interpretieren: 
auf diesem Bus "ist da jemand", dem man weitere Info entlocken könnte. 
Wenn das keinen interessiert, sollte man den Scan bei 1110.1110 oder 
spätestens bei 1111.0110 beenden.

von Peter D. (peda)


Lesenswert?

(prx) A. K. schrieb:
> Es ist mir klar, was da abgeht, nachdem Bauform B den Passus zum Device
> ID Frame erwähnte, der in der Hardware des PCA8574 drinsteckt.

???

Kannst Du bitte mal nen Link posten, wo das steht.
Im Datenblatt Rev. 3 — 3 June 2013 des PCA8574 steht nichts dazu.
Ich hab nur nen FRAM von CYPRESS gefunden, der sowas implementiert.

Habs gefunden:
Beitrag "Re: NXP PCA8574 hat Phänomen mit 2 Adressen"

Ist also aus dem Datenblatt rausgeflogen.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Peter D. schrieb:
> Im Datenblatt Rev. 3 — 3 June 2013 des PCA8574 steht nichts dazu.

Das ist kein echtes Kriterium. Ein Datasheet dokumentiert nur jene 
Funktionen, die offiziell unterstützt werden. Obendrein ist es, wie 
Bauform B schrieb, weitaus billiger, irgendwelche Zombies aus dem 
Datasheet rauszuradieren, als aus dem Silizium zu entfernen. Das 
Datasheet sagt ja auch nicht, dass da nichts wäre, sondern verlässt sich 
darauf, dass es aufgrund der Adressbeschränkung in der I2C-Referenz 
niemand versucht. Unspecified behaviour.

Der Punkt ist halt der: Das Device reagiert exakt so, wie es müsste, 
wenn diese Funktion mindestens rudimentär vorhanden ist. Das erste Byte 
wird ACKed, was bei Veits Scanner zu "da ist was" führt. Weiter geht der 
Scanner nicht, würde also auch nicht merken, wenn sich zu diesem 
Zeitpunkt noch mehrere Slaves gleichzeitig angesprochen fühlen, denn die 
genaue Adressierung erfolgt ja erst im zweiten Byte.

Auch bei 0x78-0x7B könnten im Prinzip solche Effekte auftreten. Wenn 
mindestens einer der Slaves eine evtl undokumentiert 10-Bit Adressierung 
unterstützt, würde das erste Adressbyte erst einmal blind ACKed. Das 
Schema des 10-Bit Frames ist ja anfangs gleich wie bei Device ID.

Das I2C-Modul eines Slaves ist u.U. ein generischer Funktionsblock, der 
vielleicht nicht nur das kann, was offiziell beabsichtig ist, sondern 
auch mehr. Ohne dies jemals zu dokumentieren.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

PS: Wären mehrere Slaves mit dieser Eigenschaft am Bus gewesen, hätte 
Veits Suche noch weit gespenstischer gewirkt. Denn bei Versuch, den 
"Übeltäter" zu finden, hätte er jeden Slave einzeln auslöten können, 
ohne dass der Effekt verschwunden wäre. Weil immer mindestens einer 
dabei gewesen wäre, der ACKed. ;-)

: Bearbeitet durch User
von DerEgon (Gast)


Lesenswert?

Peter D. schrieb:
> Im Datenblatt Rev. 3 — 3 June 2013 des PCA8574 steht nichts dazu.

Tatsächlich steht da was, und zwar in der Änderungshistorie gegenüber 
der vorhergehenden Datenblattversion. Da wurde der Hinweis auf die 
Funktionalität aus den "bullet points" (der Stichpunktliste) am 
Datenblattanfang gelöscht.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

Dank eures erneuten Hinweises mit dem Finger in die Wunde, danke fürs 
dranbleiben Bauform und prx (geht doch :-) ), habe ich das "Problem" 
jetzt tatsächlich neu verstanden. Bei 1111.1000 habe ich immer nur rein 
an Addresse gedacht. Ich gebe es einmal mit meinen Worten wieder. Das 
ist ein extra Kommunikationsode damit der IC weiß hier folgt nochwas, 
hier will jemand anderweitig mit mir reden und ich melde mich mit ACK 
damit der Master weiß ich kenne das Stichtwort "1111.1000". Und weil das 
keine echte Adresse ist, ist das als Adresse verboten bzw. reserviert. 
Jetzt macht das alles Sinn.  :-)  Danke.

Und ja wenn davon mehrere verwendet wurden wären hätte ich echt blöd aus 
der Wäsche geguckt. Ich hätte mich tot gelötet.

Ich werden die obige Sequence ausprobieren ...

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

die Sequence sollte stimmen. Er antwortet jedoch nicht auf 0xF9. Damit 
sollte ihm nichts zu entlocken sein.
1
void checkDevice (Stream &out)
2
{
3
  /*
4
    1. The master sends a START command.
5
    2. The master sends Reserved Slave ID 0xF8. */
6
  Wire.beginTransmission(0x7C);   // (7 Bit)
7
  Wire.endTransmission(true);
8
  /* 
9
    3. The FM24V10 sends an ACK.
10
    4. The master sends the I2C-bus slave address of the slave device
11
     it needs to identify. The last bit is a ‘Don’t care’ value
12
     (page select and R/W bits). Only one device must acknowledge
13
     this byte (the one that has the I2C-bus slave address). */
14
  Wire.beginTransmission(0x26);  // (7 Bit) >>> 0x4C
15
  Wire.endTransmission(false);   // für Restart
16
  /*
17
    5. The FM24V10 sends an ACK.
18
    6. The master sends a Re-START command.
19
    7. The master sends Reserved Slave ID 0xF9 (B1111.1001) (8 Bit) 
20
    8. The FM24V10 sends an ACK.
21
    9. The Device ID Read can be done, starting with the
22
       12 manufacturer bits, followed by the 9 device identification
23
       bits, and then the 3 die revision bits.
24
    10. The master ends the Device ID read sequence by NACKing the
25
       last byte, thus resetting the slave device state machine and
26
       allowing the master to send the STOP command.
27
    Note The reading of the Device ID can be stopped anytime by
28
    sending a NACK command. */
29
  Wire.requestFrom(0x7C, 3);    // (7 Bit) / 0xF9 
30
  if (Wire.available() )       
31
  {
32
    out.println(F("Data"));
33
    out.println(Wire.read() );
34
    out.println(Wire.read() );
35
    out.println(Wire.read() );
36
  }
37
}

Edit: einen besseren Sreenshot rangehangen mit 8 und 7 Bit Dekodierung

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

(1) Die Transaktion direkt nach 0xF8 mit STOP abzubrechen ist nicht das, 
was das Device in diesem Fall erwartet. Die Adresse folgt direkt darauf, 
ohne STOP.

(2) Obacht: Eine STOP condition gefolgt von einer START condition ist 
etwas anderes als eine repeated START condition. Der Re-START wird 
verwendet, um innerhalb einer Transaktion die Richtung zu wechseln. Bei 
STOP-START sind es getrennte Transaktionen.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

ich habe die Beschreibung so verstanden das erst nach dem senden der 
Adresse ein Restart erfolgen muss. Bei Punkt 4 lese nichts von Restart. 
Ich kann das aber gern probieren.

von (prx) A. K. (prx)


Lesenswert?

Veit D. schrieb:
> ich habe die Beschreibung so verstanden das erst nach dem senden der
> Adresse ein Restart erfolgen muss. Bei Punkt 4 lese nichts von Restart.
> Ich kann das aber gern probieren.

Ich habe meinen Beitrag entsprechend angepasst.

Du hast zwischen 0xF8 und 0x4C ein STOP-START, und damit das Device ID 
sofort abgebrochen. Das Re-START erwähnte ich vorsorglich, weil Falle.

Ich kenne den API nicht, gehe aber davon aus, dass
  Wire.beginTransmission(0x7C);   // (7 Bit)
ein START darstellt, und
  Wire.endTransmission(true);
ein STOP.

: Bearbeitet durch User
von Bauform B. (bauformb)


Lesenswert?

Veit D. schrieb:
> 4    1. The master sends a START command.
> 5    2. The master sends Reserved Slave ID 0xF8. */
> 6  Wire.beginTransmission(0x7C);   // (7 Bit)
> 7  Wire.endTransmission(true);
> 8  /*
> 9    3. The FM24V10 sends an ACK.
> 10    4. The master sends the I2C-bus slave address of the slave device
> 11     it needs to identify. The last bit is a ‘Don’t care’ value
> 12     (page select and R/W bits). Only one device must acknowledge
> 13     this byte (the one that has the I2C-bus slave address). */
> 14  Wire.beginTransmission(0x26);  // (7 Bit) >>> 0x4C
> 15  Wire.endTransmission(false);   // für Restart

Jeder hat 3 Versuche ;) Ich verstehe das so, dass die ersten beiden 
Bytes "im Stück" gesendet werden sollten. Also ohne Stop in Zeile 7 und 
ohne neuen Start in Zeile 14. Oder mindestens mit einem Restart.

von Bauform B. (bauformb)


Lesenswert?

ja, ich bin zu langsam, aber jetzt war die Kaffeebestellung wichtiger ;)

von (prx) A. K. (prx)


Lesenswert?

Bauform B. schrieb:
> Jeder hat 3 Versuche ;) Ich verstehe das so, dass die ersten beiden
> Bytes "im Stück" gesendet werden sollten.

Natürlich. Gerade so wie bei 10-Bit Adressierung.

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

laut Beschreibung gehört nach 0xF8 keine Restart hin. Nach 0x4C lese ich 
von Restart was ja mache. Was stimmt denn nun?

von (prx) A. K. (prx)


Lesenswert?

Veit D. schrieb:
> laut Beschreibung gehört nach 0xF8 keine Restart hin

Aber auch nicht der STOP, den du da mit endTransmission reinlegst.

Der Re-START hinter 0x4C passt.

Ich tippe auf
  Wire.beginTransmission(0x7C);
  Wire.write(0x26);
  Wire.requestFrom(0x7C, ...

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

habe ich auch probiert, wenn ich endTransmission weglasse und/oder write 
verwende geht nichts mehr. Ich sehe nicht einmal das zweite 
beginTransmission oder write auf der Leitung.

Ich muss nochmal in Ruhe überlegen, sonst wird das MuP (Methode des 
unbekümmerten Probierens). Das ist nur in engen Grenzen sinnvoll.

endTransmission(false) ohne Stop
endTransmission(true) oder leer () mit Stop

von (prx) A. K. (prx)


Angehängte Dateien:

Lesenswert?

Dann such im Netz mal nach einem Arduino-Beispiel für eine Leseoperation 
mit 10-Bit Adressierung. Die ist im Ablauf praktisch gleich.

: Bearbeitet durch User
von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

Bsp. habe ich keines gefunden, aber im Spencekonde DxCore Package Readme 
stand das es einfach wäre mit einer 10Bit Adressierung. ;-)
Mein gedanklicher Hänger war, wie bekomme ich ein Start Repeat hin ohne 
endTransmission. Gar nicht. Ich musste die Reihenfolge der Aufrufe 
ändern.
1
void checkDevice (Stream &out)
2
{
3
  Wire.beginTransmission(0x7C); // 0xF8
4
    
5
  Wire.write(0x4C);     
6
  
7
  Wire.endTransmission(false);
8
  
9
  Wire.requestFrom(0x7C, 3);    // 0xF9 
10
  if (Wire.available() )       
11
  {
12
    out.println(F("Data"));
13
    out.println(Wire.read() );
14
    out.println(Wire.read() );
15
    out.println(Wire.read() );
16
  }
17
}

Data
0
2
88

Sieht das gut aus oder noch Fehler im Analyzer?

von (prx) A. K. (prx)


Angehängte Dateien:

Lesenswert?

Der Zyklus passt. Was du mit den gelesenen Daten anfängst, ist ein 
anderes Thema. ;-)

von Veit D. (devil-elec)


Lesenswert?

Hallo,

vielen Dank für die Unterstützung bzw. Hilfe. Mit den Daten kann ich 
nicht viel anfangen. Aber das es funktioniert ist schön, darum ging es.

Wenn ich die Bytes in der richtigen Reihenfolge zusammengesetzt habe, 
sieht das so aus.

Data
0
2
88

0000.0000 + 0000.0010 + 0101.1000

0000.0000.0000 manufactory

0010.0101.1 part id

000 revision

Ich weiß nicht ob das Sinn macht.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

ich habe noch eine Frage zur 10Bit Adressierung.

Ist im 10Bit Address Mode der gesamte Bereich 0x0000 bis 0x03FF ohne 
Ausnahme gültig? Oder beginnt der 10 Bit Address Mode wo der 7Bit Adress 
Range aufhört? Also beginnt der 10 Bit Address Range nach den 
reservierten Adressen ab 0x80?

Ich möchte einen Adressen Scanner schreiben der alles abdeckt. Die Frage 
lautet muss ich nach dem scannen des 7Bit Addressenbereiches mit 0x00 
anfangen oder muss ich ab 0x80 im 10Bit Adress-Mode weitermachen? Das 
macht am Ende den Unterschied das ggf. 128 Adressen nicht gescannt 
wurden.

: Bearbeitet durch User
von Bauform B. (bauformb)


Lesenswert?

Veit D. schrieb:
> Ist im 10Bit Address Mode der gesamte Bereich 0x0000 bis 0x03FF ohne
> Ausnahme gültig?

Naja, ein paar reservierte 7-Bit Adressen kennen wir doch schon? Der 
Unterschied zu normalen Adressen wird bei 10 Bit noch wichtiger.

Zuerst wird eine der vier 7-Bit Adressen 1111'0xyw übertragen. Damit 
wird praktisch auf 10 Bit umgeschaltet. Mit xy kommen die beiden MSBs 
der 10-Bit Adresse mit. Das nächste Byte enthält die restlichen 8 Bit 
der Adresse (das read/write Bit gibt es nur im 1. Byte).

Deshalb behaupte ich mal, dass man volle 10 Bit bekommt, also die 
Adressen 0 bis 1023, unabhängig vom 7-Bit Block 8 bis 119. Ja, 120 bis 
123 gehören jetzt wirklich nicht mehr dazu, und 124 bis 127 
funktionieren ja ähnlich speziell.

Natürlich könnten von den 1024 neuen Adressen auch ein paar reserviert 
sein, aber im Handbuch UM10204 von 2014 finde ich keine Spur davon.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

gut, also gehe ich erstmal davon aus das im 10Bit Mode der volle Bereich 
zwischen 0x0000 bis 0x03FF ohne Ausnahme gültig ist. Ich hatte nämlich 
auch keine Einschränkungen herauslesen können. Nur war ich mir nicht 
sicher. Wenn die ICs speziell im 10Bit Mode angesprochen werden sollte 
der eingeschränkte 7Bit Adressereich keine Rolle spielen. Reine 7Bit ICs 
die auf ein erstes Ansprechen im 10Bit Mode nicht reagieren stören 
nicht.

Ich fasse einmal zusammen. Man hat mit dem 7Bit Adressbereich 69 
Adressen zur Verfügung und mit dem 10Bit Adressbereich kommen ohne 
Überschneidung nochmal 1024 dazu.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.