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?
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.
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?
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.
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?
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.
(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.
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) ;-)
(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 :-)
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 ;)
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.
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.
(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.
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.
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.
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.
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.
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.
(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.
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.
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. ;-)
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.
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 ...
(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.
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.
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.
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.
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.
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, ...
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
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
voidcheckDevice(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?
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.
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.
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.
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.