Hallo zusammen,
wir versuchen gerade im Rahmen einer Studienarbeit den ADXL380-1BCCZ-RL7 via SPI auszulesen und die Beschleunigungsdaten zu protokolieren. Der ADXL380 wurde gemäß dem Datenblatt auf Seite 23 (siehe Bild) angeschlossen und wird mit dem ESP32-C3-Mini von Espressif betrieben. Der Stromverbrauch im Standby-Mode beträgt etwa 7uA und im High Performance-Mode messen wir etwa 250uA. Der ESP32 wird mit der Arduino IDE 2.3.6 programmiert und in der PDF ist der Leseprozess, den wir mit dem Oszilloskop beobachtete haben dokumentiert. Wir versuchen zurzeit nur die Beschleunigungsdaten der X-Achse (Register: 0x15 und 0x16) zu lesen und bekommen nur eine 0 als Ergebnis. Die Device_ID lässt sich allerdings, so wie auch einige andere Register problemlos auslesen. Die Ergebnisse wurden mit 2 ADXL380 getestet.
Zusätzlich zu dem vorliegenden Code haben wir ebenfalls versucht die anderen Achsen und die Temperatur auszulesen und haben ebenfalls nur 0 als Ausgabe bekommen. Vielleicht hat jemand eine Idee oder ein paar Tipps.
LG OLLI
ich habe mal das Datenblatt beigefügt, auf Seite 49 wird dort das schreiben und lesen per SPI erklärt. Ich habe das Datenblatt so gedeutet, dass die Adresse insgesamt 7 Bit lang ist und in die Bits 9-15 geschrieben wird, weswegen ich in meiner Funktion auch die Adresse um 9 Bit shifte (von Bit 0 auf Bit 9) und der Read/Write Befehl liegt auf Bit 8, weswegen ich das dann um 8 shifte. Vielleicht habe ich da auch einen Denkfehler. Könntest du mir deinen Ansatz etwas genauer erläutern.
LG Olli
uint16_t data = SPI.transfer16(((uint16_t)registerAddress<<9) | (0x01<<8));
7
:
Das sollte der Compiler zwar von sich aus tun, aber hey, wer weiß. Das Oszi wäre hier wieder super, um zu sehen, ob auf dem Bus auch das unterwegs ist, was du erwartest.
Noch Tipp: die Bits 15..8 im empfangenen 16-Bit-Wort sind "undriven". Die solltest du also sinnigerweise spätestens bei der Anzeige ausblenden. Oder einfach nur 8 Bits zurückgeben:
Das ist jetzt unser aktueller Code. Die Ausgabe ist jetzt etwas formatiert und ich habe die Verbesserung mit uint8_t bei readRegister() übernommen. Die Datentypkonvertierung mit (uint16_t) ist eine gute Idee gewesen, aber leider hat das auch keine Verbesserung ergeben.
Wir erhalten weiterhin bei allen Achsen 0 als Ausgabe und lesen derzeit alle 4 ID´s aus, wobei eine ID vom Datenblatt abweicht. Die ID unter der Adresse 0x03 sollte den Wert 0xC2 widergeben und wir erhalten eine 0xC1. Allerdings ist in dem Applications Examples (GitHub) in der ADXL38x.h auf der Analog Devices Seite zum ADXL380 auch als Rückgabewert 0xC1 beschrieben.
Des weiteren haben wir den Status 0-3 weiter ausgewertet und haben "EFUSE-Fehler" lesen können:
Erweiterter Reset + NVM Control
1
writeRegister(0x2A, 0x52); //Seite 69
2
…
3
delay(10);
4
//NVM Control
5
writeRegister(0x29, 0b11000000);
6
delay(10);
Ausgabe:
1
Soft-Reset: 0x2 0b10
2
Mode_1: 0x0 0b0
3
Dig_En: 0xE0 0b11100000
4
Mode_2: 0xC 0b1100
5
Status0: 0x40 0b1000000
6
Status1: 0x80 0b10000000
7
Status2: 0x9C 0b10011100
8
Status3: 0x1 0b1
Erweiterter Reset
1
writeRegister(0x2A, 0x52); //Seite 69
2
…
3
delay(10);
Ausgabe:
1
Soft-Reset: 0x2 0b10
2
Mode_1: 0x0 0b0
3
Dig_En: 0xE0 0b11100000
4
Mode_2: 0xC 0b1100
5
Status0: 0x40 0b1000000
6
Status1: 0x80 0b10000000
7
Status2: 0x9C 0b10011100
8
Status3: 0x0 0b0
Erweiterter Reset mit Startdelay
1
delay(10);
2
writeRegister(0x2A, 0x52);
3
…
4
delay(10);
Ausgabe:
1
Soft-Reset: 0x2 0b10
2
Mode_1: 0x0 0b0
3
Dig_En: 0xE0 0b11100000
4
Mode_2: 0xC 0b1100
5
Status0: 0x40 0b1000000
6
Status1: 0x80 0b10000000
7
Status2: 0x9C 0b10011100
8
Status3: 0x0 0b0
Soft-Reset
1
writeRegister(0x2A, 0b00000010);
2
…
3
delay(10);
Ausgabe:
1
Soft-Reset: 0x0 0b10
2
Mode_1: 0x0 0b0
3
Dig_En: 0xE0 0b11100000
4
Mode_2: 0xC 0b1100
5
Status0: 0x0 0b0
6
Status1: 0x80 0b10000000
7
Status2: 0x9C 0b10011100
8
Status3: 0x1 0b1
Bei dem "erweiterte" Reset schreiben wir in das Reset-Register die 0x52, was einen sofortigen Reset zur Folge hat (S.69 im Datenblatt).
Zu erkennen ist, dass wir ohne "erweiterten" Reset NVM_Done (Bit 6) in Status 0 nicht gesetzt wird. Ansonsten haben wir das Problem bei alle Versuchen das Status 1 einen Error mit Bit 7 zum EFUSE Controller ausgibt und Status 2 mit Bit 3 einen EFUSE CRC Error ausgibt. Vielleicht haben wir auch eine Denkfehler, aber ich sehe gerade keine anderen Problem mehr und verstehe die EFUSE-Errors nur bedingt. Ich werde noch einmal den SPI-Bus mit dem Oszilloskop untersuchen und mich dann nochmal melden.
Ich werde noch einmal den SPI-Bus mit dem Oszilloskop untersuchen
Je nach dem, was du für ein Oszilloskp hast, kann das möglicherweise als Logikanalysator das SPI-Signal selbst dekodieren.
In dem Analyse-Dokument ist es wegen der geringen Zeitauflösung und der Überlagerung von Clock und Daten arg mühselig, irgendwelche Details bzgl. des Timings abzulesen.
Moin,
ich kenne diesen Chip nicht, aber für die SPI Kommunikation ist kein eigenes Frame Format angegeben.
Bei anderen Chips heisst das, das exakt das I2C Frame Format benutzt werden muss. Also Byte1 Devadr+r/w, Byte2 regadr, byte2 Data.
Du machst nur 16bit transfers.
Und die Device Adresse sollte ja fix sein, je nachdem wie ASEL0/1 stehen.
Könnte es daran liegen?
SPI braucht keine DeviceAddress.
Das R/W-Bit wird an das Command-Byte (obere sieben Bit) als LSB angehängt.
Kapitel "Serial Communicatiom" im Datenblatt (https://www.analog.com/media/en/technical-documentation/data-sheets/adxl380.pdf - Seite 49)
Ob der Baustein ein Adress-Autoinkrement unterstützt, habe ich auf die Schnelle nicht gefunden. Normalerweise / von anderen Bausteinen wird sowas ja unterstützt.
Der ADXL380-1BCCZ-RL7 ist nur mit einer SPI-Kommunikation ausgestattet (siehe S.103) und diese ist auch leider Vorgabe. Wir haben jetzt versucht mit einem anderen Mikrocontroller (Arduino Nano) den ADXL380 auszulesen, haben aber weiterhin nur die Device ID bekommen.
Zusätzlich dazu haben wir die SPI-Kommunikation mit einem ADXL345 geteste und direkt plausible Beschleunigungsdaten erhalten. Den SPI-Modus (0 oder 3), sowie eine Veränderung der Frequenz haben wir auch am ADXL380 probiert ohne Erfolg, wobei das mehr eine Akt der Verzweiflung war ^^.
Die Bilder von dem Oszilloskop sahen soweit genauso aus, wie wir es erwarten würden. Alldering sind die Daten nicht so leicht zu sehen, wegen des schlechten Kontrastes.
Grün = Daten
Gelb = Clock
Zu sehen ist einmal MISO und MOSI von dem High-Byte der x-Achse und von der ID4, da wir dort eine Abweichung hatten. Zusätzlich schicke ich noch ein Bild zu dem kompletten MISO-Datensatz, was wahrscheinlich wegen dem HighZ (vergleiche Seite 49) in den nicht relevanten Bits 1 oder 0 ist.
Es gibt chips bei welchen man das Datenblatt nur scheinbar begriffen hat, resp das vorgegebene Timing ist nur minimal verschieden zum implementierten. Schliesslich vergleicht man jede Flanke mit dem Datenblatt. Ich hab auch schon eine Woche an solchen Details vertan.
ADXL380_Schaltung.png
(54 KB)
