Sensordaten umrechnen

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Sensordaten umrechnen

      Hallo!

      Habe gerade mal wieder nen Brett vor den Kopf:
      Die Sensordaten eines CC2D habe ich vor einiger Zeit irgendwie gebacken bekommen.
      Nun aber werkel ich seit Stunden an nem MPL3115A2:

      Zwei Meßwerte in 5 Registern:

      h01 Luftdruck MSB
      h02 Luftdruck CSB <- Ergeben 3 Byte mit 20 Nutzbits und vier Schrottbits am Ende, Format Q18.2
      h03 Luftdruck LSB
      h04 Temperatur MSB <- Ergeben 12Bit inkl. Signierung 12 Bit in Q8.4
      h05 Temperatur LSB

      Druck ist ein Q18.2 Wert, Also...
      Druck MSB h63 01100011
      Druck CSB h72 ________ 01110010
      Druck LSB h50 ________ ________ 10,10xxxx

      Das untere Nibbel LSB ist Müll, wird nicht genutzt.
      Das obere Nibbel LSB besteht aus zwei Bit vor dem Komma und zwei Nachkomma-Bits.

      Manuell zusammengesetzt bekomme ich es auch auseinandergedröselt:
      Obige Meßwerte zusammengesetzt (h63 h72 h50) ergäben binär: 11000110111001010 als Ganzzahl (Dec.= 101834)
      Dazu die Bits 5 und 4 (10) dazu entsprechen einer Wertigkeit von 0,25 ergäbe dann 101834,50 Pascal, oder in das metereologische Format /100 = 1018,3425hPa.

      Nur alle Ansätze bisher das in banscom nachzubilde die letzten Stunden waren wenig erheiternd.
      Die Rohdaten liegen in einem Byte-Array MPL(2) bis MPL(4).
      Von dort aus schiebe ich in ein DWord...zuerst erfolglos mit Addition und Shift, zuletzt Bitweise Manuel:
      Dword.0 = MPL(4).6....usw..

      Eigentlich dachte ich sowas hätte ich vor einiger Zeit mal verstanden, aber irgendwie helfen mir meine bisherigen 2-Byte-Flieskomma Erfahrungen da nicht wirklich weiter. Wie macht man sowas in möglichst einfach und effektiv?

      Grüße

      Jürgen
    • Wenn du dein array andersrum füllst, dann kannst du dein dword als overlay drüber legen. Dann das dword in ein weiteres kopieren und um 4 bits nach rechts shiften. Das dann x 0,25, dann bist du bei Pa.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Kannst Du mich mal erhellen: Du liest die Register aus und betankst damit per Zuweisung eine Fließkomma-Variable?

      Wenn das Fließkomma ist, wäre dann nicht die erste Nachkommastelle 0,5 (also 2^-1)?
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.
    • @DG7GJ, hast Du den Sensor selbst auf der Platine verlötet? Falls ja, ging es gut oder eher bescheiden? Meine Heißluftstation ist neu und es fällt mir noch schwer Bauteile dieser Art schadlos zu löten (wahrscheinlich zu ungeduldig).
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.
    • Hallo!

      Mitch64 schrieb:

      @tschoeatsch
      so kann man das machen.

      Im Prinzip steht in deinem Array der Druck mit 4 multipliziert.
      Man könnte nach dem Ausleser der Datenbytes auch den Wert durch 4 teilen.

      Das Ergebnis wäre das gleiche.
      Hmm, also die kompletten 20 Bit inklusive der zwei Nachkomma-Bits / 4 *grübel*...das hört sich überraschend logisch an.
      Muss ich doch gleich mal ausprobieren.


      monkye schrieb:

      Kannst Du mich mal erhellen: Du liest die Register aus und betankst damit per Zuweisung eine Fließkomma-Variable?

      Wenn das Fließkomma ist, wäre dann nicht die erste Nachkommastelle 0,5 (also 2^-1)?

      Der Meßwert selber ist kein Fließkomma, sondern Fixwert mit zwei Nachkomma-Bit. Also Wertigkeit 1/4: ,00 ,25 ,50 ,75.
      Seit dem Beitrag von Mitch64 lässt mich sein Hinweis nicht mehr los...bestechend, wenn man den Wald vor lauter Bäumen nicht mehr sah..:-)

      monkye schrieb:

      @DG7GJ, hast Du den Sensor selbst auf der Platine verlötet? Falls ja, ging es gut oder eher bescheiden? Meine Heißluftstation ist neu und es fällt mir noch schwer Bauteile dieser Art schadlos zu löten (wahrscheinlich zu ungeduldig).
      Ja - Nein - Ja..:
      Selber gelötet, aber schief gegangen und musste nachgelötet werden.
      Da die Anschlußpads unter dem Gehäuse liegen habe ich im Layout die Pads länger gemacht um seitlich zumindest Wärme von der Seite ran zu bekommen.
      Die erste Lötung mit Lötpaste und Lötkolben sah auch gut aus.
      Dumm war nur, das Lötzinn hat sich am SDA-Pad nicht verbunden.
      Also mit Heißluft zurechtgerückt und zwei wichtige How-Do's gelernt:

      Der MPL3115A2 geht beinahe Problemlos mit Heißluft - wenn man geübt ist.
      Allerdings werde ich das nächste mal NICHT mehr die Lötpaste auf die Platine geben, sondern direkt 8 kleine Klekser direkt auf die Pads des MPL3115A2.
      Ersatzweise - sollte ich nochmal ne Platine für den MPL3115A2 machen, werden die Pads nicht mehr größer als die Pads des MPL.

      Meine zweite wichtige Lehrerkentniss bei dieser Nachlötaktion betraf eher den ersten Sensor direkt neben dem MPL3115A2: Ein CC2D. Schon beim durcharbeiten des Datenblattes will man ihn weder mit Heißluft noch mit einem Lötofen löten.
      Ist zwar laut Datenblatt möglich, allerdings braucht der CC2D hinterher eine aufwändige und zeitraubende Rehydrierung und Kalibrierung.
      Als mir das egal wurde, wegen dem nachzulötenden MPL3115A2 direkt daneben war aber nicht nur die Kalibierung dahin...das Gehäuse löste sich auf!
      Also löten mit TpMax 225°C soll laut Datenblatt gehen - direkt daneben mit 240~250°C führt sofort zum Totalschaden.

      Während der MPL3115A2 also relativ unproblematisch ist, werde ich den CC2D zukünftig immer als aller letztes bestücken, und dann nicht mit Heißluft sondern mit Lötkolben Pad für Pad mit max. 225°C und gemütlichen Pausen zwischen den Pads.

      Allgemein zum Thema Heißluftstation:
      Als ich vor etwa 6~7 Jahren anfing mit der Heißluftstation habe ich auch etliche Sachen sprichwörtlich verbraten.
      Es brauchte hinreichend frustige Erfahrungen bis ich die Realtemperatur am Lötobjekt besser einschätzen konnte.
      Was enorm hilft ist ein entsprechender Temperatursensor den man mal drunter legt.
      Denn die Temperatur welche die Heißluftstation im Heizelement misst (das ist die Regelungsgrundlage der Station) hat kaum was - oder nur sehr wenig mit der Temperatur am Lötobjekt zu tun.

      Oder um es mal vereinfacht zu sagen:
      Stelle ich meine Heißluftstation auf 220°C (niedrigster mögliche Wert) kann ich da noch schmerzfrei meine Hand unter die Düse halten. PT1000 meldet selbst nach 30 Minuten einlaufzeit nur schlappe 60°C unter der Düse.

      Einstellung 250° geht dann innerhalb von 2-3 Minuten auf reale 180-188°C am Objekt.
      Für praxisübliche Lötaufgaben wo ich 220-240°C für brauche muss ich an meiner Station irgendwas zwischen 280-310°C (je nach Luftmenge/Blaskraft) einstellen.
      Und ohne griffbereit an der Station liegendes Multimeter mit Temperatursensor mache ich gar nix mehr mit Heißluft. Fängt man da an zu schätzen, geht es fast immer in die Hose.

      Grüße

      Jürgen
    • Du musst nur dran denken, das lsb eines dword liegt im Speicher an der Stelle n, das msb an der Stelle n+3. Daher musst du die Elemente des arrays auch so füllen, dass ein overlay mit einem dword auch richtige Bitfolgen hat.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Hallo!
      Hat geklappt:

      Quellcode

      1. ADC:1.253120061 = Akku = 3.763119931V MPL: 1020.1074hPa 36.38°C Hex: 63 9E B0 24 60 CC2D: 17.67% 35.15°C Hex: 0B 4F 74 98
      2. ADC:1.253120061 = Akku = 3.763119931V MPL: 1020.1150hPa 36.38°C Hex: 63 9E E0 24 60 CC2D: 17.69% 35.15°C Hex: 0B 52 74 98
      3. ADC:1.254879947 = Akku = 3.764879938V MPL: 1020.0774hPa 36.31°C Hex: 63 9D F0 24 50 CC2D: 17.69% 35.13°C Hex: 0B 52 74 90
      4. ADC:1.251360056 = Akku = 3.761359926V MPL: 1020.0900hPa 36.31°C Hex: 63 9E 40 24 50 CC2D: 17.69% 35.13°C Hex: 0B 52 74 90
      5. ADC:1.253120061 = Akku = 3.763119931V MPL: 1020.0850hPa 36.31°C Hex: 63 9E 20 24 50 CC2D: 17.69% 35.12°C Hex: 0B 52 74 8C
      6. ADC:1.254879947 = Akku = 3.764879938V MPL: 1020.0800hPa 36.31°C Hex: 63 9E 00 24 50 CC2D: 17.69% 35.12°C Hex: 0B 52 74 8C
      7. ADC:1.251360056 = Akku = 3.761359926V MPL: 1020.1274hPa 36.31°C Hex: 63 9F 30 24 50 CC2D: 17.67% 35.12°C Hex: 0B 4F 74 8C
      8. ADC:1.253120061 = Akku = 3.763119931V MPL: 1020.1124hPa 36.31°C Hex: 63 9E D0 24 50 CC2D: 17.69% 35.12°C Hex: 0B 52 74 8C
      9. ADC:1.256639954 = Akku = 3.766639946V MPL: 1020.0874hPa 36.31°C Hex: 63 9E 30 24 50 CC2D: 17.67% 35.12°C Hex: 0B 4F 74 8C
      10. ADC:1.253120061 = Akku = 3.763119931V MPL: 1020.0950hPa 36.31°C Hex: 63 9E 60 24 50 CC2D: 17.67% 35.13°C Hex: 0B 4F 74 90
      11. ADC:1.254879947 = Akku = 3.764879938V MPL: 1020.0900hPa 36.31°C Hex: 63 9E 40 24 50 CC2D: 17.69% 35.12°C Hex: 0B 52 74 8C
      12. ADC:1.253120061 = Akku = 3.763119931V MPL: 1020.0625hPa 36.31°C Hex: 63 9D 90 24 50 CC2D: 17.67% 35.12°C Hex: 0B 4F 74 8C
      13. ADC:1.254879947 = Akku = 3.764879938V MPL: 1020.1224hPa 36.31°C Hex: 63 9F 10 24 50 CC2D: 17.69% 35.13°C Hex: 0B 52 74 90
      14. ADC:1.251360056 = Akku = 3.761359926V MPL: 1020.1050hPa 36.31°C Hex: 63 9E A0 24 50 CC2D: 17.69% 35.12°C Hex: 0B 52 74 8C
      15. ADC:1.254879947 = Akku = 3.764879938V MPL: 1020.0900hPa 36.31°C Hex: 63 9E 40 24 50 CC2D: 17.67% 35.12°C Hex: 0B 4F 74 8C
      16. ADC:1.253120061 = Akku = 3.763119931V MPL: 1020.1124hPa 36.31°C Hex: 63 9E D0 24 50 CC2D: 17.67% 35.12°C Hex: 0B 4F 74 8C
      17. ADC:1.254879947 = Akku = 3.764879938V MPL: 1020.0924hPa 36.31°C Hex: 63 9E 50 24 50 CC2D: 17.67% 35.12°C Hex: 0B 4F 74 8C
      Alles anzeigen
      Nicht wundern über die Temperaturen:
      Die leergenuckelte LiIin-Zelle wird gerade über einen mit auf der Platine sitzenden MCP73811T geladen, was entsprechend Wärme erzeugt.

      Nach mehreren Anläufen siehr die Sub nun wie folgt aus:

      Quellcode

      1. MPL:
      2. 'Auswerter für MPL3115A2 Drucksensor
      3. i2cstart
      4. i2cwbyte &hC0 'MPL Schreiben
      5. i2cwbyte &h26 'Register 26 Anwählen
      6. i2cwbyte &h3A 'Meßbefehl
      7. i2cstop
      8. waitms 550
      9. i2cstart
      10. i2cwbyte &hC1 'MPL Lesen
      11. i2crbyte MPL1,ack
      12. i2crbyte MPL2,ack
      13. i2crbyte MPL3,ack
      14. i2crbyte MPL4,ack
      15. i2crbyte MPL5,ack
      16. i2crbyte MPL6,nack
      17. i2cstop
      18. '###################Luftdruck auswerten aus Bytes MPL2-MPL4########################
      19. DruckA = MPL2
      20. Shift DruckA , Left , 8
      21. DruckA = DruckA + MPL3
      22. Shift DruckA , Left , 8
      23. DruckA = DruckA + MPL4
      24. Shift DruckA , Right, 4
      25. DruckA = DruckA / 4
      26. DruckA = DruckA / 100 'Single mit Endergebnis in hPa/mBar
      27. DruckS = Fusing(DruckA , "####.####") 'String mit Endergebnis in hPa/mBar
      28. '###################Temperatur auswerten aus Bytes MPL5-MPL6#######################
      29. TempA = MPL5
      30. Shift TempA , Left, 8
      31. TempA = TempA + MPL6
      32. Shift TempA , Right , 4
      33. TempA = TempA / 16 'Single mit Endergebniss in °C
      34. TempS1 = Fusing(TempA , "#.##") 'String mit Endergebnis in 'C
      35. Return
      36. MPLinit:
      37. i2cstart
      38. i2cwbyte &hC0 'MPL Schreiben
      39. i2cwbyte &h26 ' Register h26 anwählen
      40. i2cwbyte &h3C 'Register h26 auf Software-Reset
      41. i2cstop
      42. Return
      Alles anzeigen

      Die MPLinit muss nur nach einem POR, oder falls der Sensor nür Müll ausgibt (bisher nie passiert) aufgerufen werden.
      In MPL wird der Sensor ausgelesen und decodiert.

      Nun bleibt nur noch 1,5 Probleme in meinem Projekt:
      Die zwei externen I²C-Eproms (M24M02) antworten auf ihre Adressen, jedoch bislang ist es mir nicht gelungen auch nur ein einziges Byte da rein zu schreiben.
      Das bislang eher noch halbe Problem ist das Register h01 eines RFM69HW.
      Soll eigentlich im Sleepmode auf h00 stehen, wechselt aber selbstständig gelegentlich auf h1A und zieht dabei mehrere mA statt einstellige µA.

      Muss mich damit morgen mit weiter auseinander setzen...

      Grüße

      Jürgen
    • Hallo!

      monkye schrieb:

      Cooler Sensor, ohne Umrechnen - spart Speicher :-).

      Nicht nur das. Sondern auch verflixt hochauflösend. Das Hektopascal mit vier zumindest auf dem ersten Blick glaubwürdigen Nachkommastellen.
      Das Datenblatt versprach als Altimeter eine Auflösung von 35cm. Hielt ich bis gestern für etwas übertrieben.


      Pluto25 schrieb:

      DG7GJ schrieb:

      Die zwei externen I²C-Eproms (M24M02) antworten auf ihre Adressen
      Wie werden die denn angesprochen? (Code)

      Bin da seit Tagen dran die Dinger zum laufen zu bekommen. Zig Anläufe, im Prinzip aktuell mit diesem Code:

      BASCOM-Quellcode

      1. M24M02A_W:
      2. IC11 = 0 'Schreibschutz IC11 deaktivieren
      3. waitms 10
      4. i2cstart
      5. i2cwbyte &hA0 'IC11 schreibadresse
      6. IC10_ack.0 = Err 'wird mit Ack beantwortet!
      7. i2cwbyte &h00 'Speicheradresse MSB
      8. IC10_ack.1 = Err 'wird mit Ack beantwortet!
      9. i2cwbyte &h00 'Speicheradresse LSB
      10. IC10_ack.2 = Err 'wird mit Ack beantwortet!
      11. 'waitms 50 'Optionale Gebetspause
      12. i2cwbyte &hC1 ' 1.zu speicherndes Byte
      13. IC10_ack.3 = Err 'wird mit Ack beantwortet!
      14. i2cwbyte &h10 ' 2.zu speicherndes Byte
      15. IC10_ack.4 = Err 'wird mit Ack beantwortet!
      16. i2cstop
      17. waitms 10
      18. IC11 = 1 'Schreibschutz IC11 aktivieren
      19. waitms 10 'mindestens notwendig nach i2cstop: 5ms
      20. Return
      21. M24M02A_R:
      22. i2cstart
      23. i2cwbyte &hA1 'IC11 Leseadresse
      24. IC10_ack.5 = Err 'wird mit Ack beantwortet!
      25. i2cwbyte &h00 'Speicheradresse MSB
      26. IC10_ack.6 = Err 'wird NICHT bestätigt vom Slave!
      27. i2cwbyte &h00 'Speicheradresse LSB
      28. IC10_ack.7 = Err 'wird NICHT bestätigt vom Slave!
      29. i2crbyte IC10_1 , ack 'kommt hFF raus
      30. i2crbyte IC10_2 , ack 'kommt hFF raus
      31. i2crbyte IC10_3 , nack 'kommt hFF raus
      32. i2cstop
      33. return
      Alles anzeigen

      Also beim schreiben werden alle Daten mit Ack bestätigt, die Slave-Schreibadresse (hA0), die Speicheradressen (h00, h00) sowie die zwei zu speichernden Bytes (hC1 , h10). Unmittelbar nach dem letzten Byte setze ich den i2cstop, welcher vom M24M02 benötigt wird als Schreib-Trigger. 5ms später sollten die Daten also gespeichert sein.

      Beim lesen wird lediglich die eigentliche Leseadresse (hA1) mit einem Ack bestätigt. Sogar beide Adressbytes bekommen beide ein Nack.
      Zum besseren Verständniss der Hardwarebedingungen:
      Ein gemeinsammer I²C-Bus (gesamtlänge etwa 5-6cm) über 2x 6K8 an Vcc 3,3V hängend.
      An diesem Bus in Reihenfolge vom µC (ATmega1284) gesehen:
      Zuerst IC10, direkt dahinter IC11 (beide M24M02), dann Feuchtigkeitssensor CC2D33S und der in Posting #10 erwähnte Drucksensor MPL3115A2.
      Die Adressen auf dem Bus etwas chaotisch zugemüllt durch die zwei E²PROMS:

      h50 CC2D33S Schreibadresse
      h51 CC2D33S Leseadresse
      hA0 IC11 M24M02 Speicherbereich h000000-h00FFFF Schreibadresse
      hA1 IC11 M24M02 Speicherbereich h000000-h00FFFF Leseadresse
      hA2 IC11 M24M02 Speicherbereich h010000-h01FFFF Schreibadresse
      hA3 IC11 M24M02 Speicherbereich h010000-h01FFFF Leseadresse
      hA4 IC11 M24M02 Speicherbereich h020000-h02FFFF Schreibadresse
      hA5 IC11 M24M02 Speicherbereich h020000-h02FFFF Leseadresse
      hA6 IC11 M24M02 Speicherbereich h030000-h03FFFF Schreibadresse
      hA7 IC11 M24M02 Speicherbereich h030000-h03FFFF Leseadresse
      hA8 IC10 M24M02 Speicherbereich h000000-h00FFFF Schreibadresse
      hA9 IC10 M24M02 Speicherbereich h000000-h00FFFF Leseadresse
      hAA IC10 M24M02 Speicherbereich h010000-h01FFFF Schreibadresse
      hAB IC10 M24M02 Speicherbereich h010000-h01FFFF Leseadresse
      hAC IC10 M24M02 Speicherbereich h020000-h02FFFF Schreibadresse
      hAD IC10 M24M02 Speicherbereich h020000-h02FFFF Leseadresse
      hAE IC10 M24M02 Speicherbereich h030000-h03FFFF Schreibadresse
      hAF IC10 M24M02 Speicherbereich h030000-h03FFFF Leseadresse
      hB0 IC11 M24M02 Identifikations-Page Schreibadresse
      hB1 IC11 M24M02 Identifikationspage Leseadresse
      hB2 IC11 M24M02 Identifikations-Page Schreibadresse
      hB3 IC11 M24M02 Identifikationspage Leseadresse
      hB4 IC11 M24M02 Identifikations-Page Schreibadresse
      hB5 IC11 M24M02 Identifikationspage Leseadresse
      hB6 IC11 M24M02 Identifikationspage Schreibadresse
      hB7 IC11 M24M02 Identifikations-Page Leseadresse

      hB8 IC10 M24M02 Idenifikationspage Schreibadresse

      hB9 IC10 M24M02 Identifikationspage Leseadresse

      hBA IC10 M24M02 Idenifikationspage Schreibadresse

      hBB IC10 M24M02 Identifikationspage Leseadresse

      hBC IC10 M24M02 Idenifikationspage Schreibadresse

      hBD IC10 M24M02 Identifikationspage Leseadresse

      hBE IC10 M24M02 Idenifikationspage Schreibadresse

      hBF IC10 M24M02 Identifikationspage Leseadresse

      hC0 Drucksensor MPL3115A2 Schreibadresse

      hC1 Drucksensor MPL3115A2 Leseadresse

      Beide Sensoren am selben Bus arbeiten problemlos, obwohl sie ganz am Ende des Busses sind.
      Busgeschwindigkeiten von 100000 und 400000 ausprobiert, immer das gleiche Ergebniss: Die E²PROM's wollen offenbar nichts speichern...
    • Hallo Michael!

      Michael schrieb:

      Das Lesen funktioniert anders:
      I2Cstart
      Schreibadresse
      Speicheradresse high
      Speicheradresse Low
      I2Cstart
      Leseadresse
      Byte Lesen
      Byte Lesen
      ...
      I2Cstop

      Bin ich gerade drüber gestolpert beim x-ten mal durchkauen des Datenblattes, das diese M24M02 einen Adresscounter drin haben.
      Ist ja bescheuert...wenn ich zuletzt was geschrieben habe von h000000 bis h00000F und minuten später was lesen will, wo steht dann der interne Zeiger? Wohl auf h000010 vermute ich mal. Grumel...
      Gut, will man sequentiell ähnlich wie bei nem FIFO Datenpakete nacheinander auslesen, mag soein Adresscounter wieder nützlich sein.
      Ich für mein Teil würde mich aber nur auf meine eigenen Adressen verlassen.

      Danke für den Hinweis!

      Jürgen
    • Der Conter ist nötig damit man in einem Rutsch mehrere Bytes lesen/schreiben kann ohne jedes einzeln adressieren zu müssen. Nach jedem Stop habe ich immer die neue Startadresse gesand. Obs nötig ist? Hat hier jemand mehr Erfahrung?
      Michaels Lösung funktioniert? Nur zur Verdeutlichung:
      Nach dem Senden der Readadresse antwortet normalerweise der Slave und es ist an dem AVR ein Ack zu generieren damit der Slave weiß: gut angekommen nächstes kann gesendet werden. Wird jetzt nach der Readadresse noch ein Byte gesendet gibts eine Kollision - kein Schaden aber auch kein Grund für den Slave ein Ack zu senden bzw überhaupt erst zuzuhören. a_169_53178177
    • Hallo!

      Pluto25 schrieb:

      Der Conter ist nötig damit man in einem Rutsch mehrere Bytes lesen/schreiben kann ohne jedes einzeln adressieren zu müssen. Nach jedem Stop habe ich immer die neue Startadresse gesand. Obs nötig ist? Hat hier jemand mehr Erfahrung?
      Michaels Lösung funktioniert?
      Ja, funktioniert!
      Habe in manchen Datenblättern diverser Slaves schon häufiger von "speziellen" I²C-Zugriffen gelesen, wie der M24M02 benutzt.
      Also nicht nur ein Start am Beginn und ein Stop am Ende, sondern erneute Start oder Restarts zwischen einzelnen Bytes.
      Der M24M02 ist halt nur mein erster Slave gewesen der sowas benutzt und ich es nicht blickte.

      Was den Adresscounter angeht, den habe ich gestern Abend noch schätzen gelernt.
      Die zwei M24M02 auf meiner Platine sollen als Notfall-Speicher dienen:
      Eine Art Zentralstaktion welche von mehreren Sensoren mittels RFM69W / RFM69HW minütlich Datenpakete je Sensor mit 25Byte umfang ansammelt.
      Die 6-8 Einzelpakete welche er in den Sekunden 15-50 empfängt soll er in Sekunde 59 weiter senden an ein Terminal.
      Sollte dieses Terminal nicht erreichbar sein, sollen alle Pakete solange in die M24M02 geschrieben werden, bis das Terminal wieder die Daten abholt.

      Dazu will ich 11 Array(25) nutzen:
      Paket0(25) für das jeweils aktuell empfangende, wird nach Abarbeitung sequentiell in Paket1(25) bis Paket10(25) kopiert.
      Ist der Schwellwert von 10 Paketen erreicht, ohne erfolgreich ans Terminal weiter leiten zu können, müssen diese 250Bytes flott weg damit es nicht zum Datenstau kommt.

      Da das Datenblatt des M24M02 zum Thema "wie viele Bytes kann man auf einmal senden" ziemlich schwammig bleibt, hab ich es gestern mal getestet.
      Und jawoll...klappt:
      10 Arrays zu je 25Bytes von B0 00 00 bis B0 00 FA reinpressen, Stop....alles mit Ack bestätigt.

      Wenige Sekunden später dann eine Terminal-Abholung mit dem Adresscounter getestet:
      Start B0 00 00 Start B1 -> 25 Bytes ausgelesen Stop
      Start B1 - 25Bytes ausgelesen - Stop
      Start B1 - 25 Bytes ausgelesen - Stop...
      250Bytes rein und raus im Affenzahn, also durchaus praktisch dieser Counter.

      E²PROM's also erledigt.

      Zu meinem oben angedeuteten 1/2-Problem das mein RFM69HW nach initialisierung selbstständig den Modus wechselt und unnötigen Strom verbraucht, will ich gleich erst angehen. Vermute mal das er Störungen auf dem /CS hat, bekommt da also nachher erst man einen PullUp.

      Die erste Tageshälfte kam noch ein analoges Problem hinzu.
      Seit Tagen schaffte es ein MCP73811 nicht mehr den LiPo-Akku des Moduls voll zu bekommen. Klappte anfangs spitze, doch zuletzt 3 Tage laden und LiPo kam nicht über 4,078V.
      Heute morgen dann noch immer Temperaturen >30°C von den Sensoren, die selbst nach abklemmen der Ladespannung nicht verschwanden.

      Erkentniss bei der Fehlerursache: Ein TPS62203 PWM-PFM Schaltwandler war abgeraucht. Zog dauerhaft 71mA aus den LiPo obwohl die 3,3V-Seite definitiv nur 6mA zog.

      Grüße

      Jürgen