Guten Tag, Nach der Entwicklung einer Platine, muss ich die Daten von Beschleunigungssensor (ADXL345) mittels I2C Schnittstelle auslesen und diese Daten zu Putty-Anzeige bringen. Die Werte (Xout: Accelaration in X-Axis) werden mithilfe von ADXL_Read_Single und ADXL_Read_Double gelesen. Im Putty-Anzeige wird nur -1 (unendliche Schleife von -1) gelesen??? Haben Sie eine Idee warum wird nur -1 gelesen.? Im Anhang finden Sie den Code C. Mikrocontroller: ATMEGA88 A Sensor : Beschleunigungssensor (ADXL345)
C.png?? Ich kann es nicht ohne weitere Hilfsmittel lesen.
Ich habe das alles abgetippt. Bekomme aber noch Fehlermeldungen, wg. fehlender Dateien. Und genügend kleine Pullup sehe ich in deinem Schaltplan auch nicht. :-O
Die Antwort wird hoffentlich in der Doku der ADXL Bibliothek stehen. Darauf habe ich keinen Zugriff.
Kevin A. schrieb: > Code_C.png > Im Anhang finden Sie den Code C. Mit PNG-Dateien können die wenigsten Compiler etwas anfangen.
Stefan ⛄ F. schrieb: > Die Antwort wird hoffentlich in der Doku der ADXL Bibliothek stehen. > Darauf habe ich keinen Zu Danke für Ihre Antwort. Im Anhang Finden Sie die zwei Bib für ADXL345,die benutzt wird.Ich habe auch den Eindruck, dass es ein Problem in den Bibliotheken gibt,aber wo genau !!,weiss ich nicht ...
Leider enthalten die beiden Dateien keinerlei Dokumentation. Ich würde die Kommunikation mit einem Logic-Analyzer aufzeichnen und mit dem Datenblatt des Sensors vergleichen.
Um es kurz zu machen, der Treiber ist Schrott. Warum wird kein Hardware I2C verwendet sondern Pingetoogel und Wartezeiten über delay? Warum wird keines der Ack ausgewertet? Wenn das gemacht werden würde, würde man merken dass der Sensor nichts zurück schickt und dadurch die -1 (Datenpin dauerhaft High) entsteht.
N. M. schrieb: > Um es kurz zu machen, der Treiber ist Schrott. Woran machst du das fest? OK, er prüft das ACK nicht, aber das erklärt noch nicht, warum es nicht funktioniert.
Stefan ⛄ F. schrieb: > aber das erklärt noch nicht, warum es nicht funktioniert. Das kann alles sein. Fehlende Pullups. Falsche Adressierung des Chips. Defekter Beschleunigungssensor. Vielleicht versorgt er den uC mit 5V und hat dadurch den Beschleunigungssensor geschrottet. Müsste man halt messen. Wurde oben ja schon geschrieben. Stefan ⛄ F. schrieb: > Woran machst du das fest? An der fehlenden Auswertung des ACK. Der Chip wird scheinbar nicht adressiert. Man wertet das aber nicht aus, sondern macht einfach weiter. Man bekommt auch keine Daten zurück, nimmt die ganzen 1en aber als Wert entgegen und verwendet ihn. Also für mich ist das Schrott in doppelten Sinne. Normalerweise würde man doch pro Job schauen ob adressiert werden konnte und ob alle TX Daten geACKt werden. Nur wenn das der Fall ist gibt man ein Success zurück. Und nur genau dann nimmt man die Daten.
N. M. schrieb: > Normalerweise würde man doch pro Job schauen ob adressiert werden konnte > und ob alle TX Daten geACKt werden. Normalerweise: ja Andererseits: Wenn es im Programm keine nützliche Fehlerbehandlung gibt und diese auch nicht notwendig ist (weil dann nichts schlimmes passiert) kann man auch mal drauf verzichten. Nur muss man dann man mit Messgeräten arbeiten, um nicht blind raten zu müssen.
Stefan ⛄ F. schrieb: > Wenn es im Programm keine nützliche Fehlerbehandlung gibt und diese auch > nicht notwendig ist (weil dann nichts schlimmes passiert) kann man auch > mal drauf verzichten. Ich gebe dir Recht wenn man nichts dagegen machen kann OK. Aber ich finde das alleine schon sinnvoll um sich nicht falsche Messwerte rein zu ziehen. Wenn das während des zyklischen auslesen Auftritt, hat man immer Mal wieder falsche Messwerte die man verwendet. Bei einer Armbanduhr vielleicht nicht so schlimm weil sie nur zu viele Schritte zählt, beim inversen Pendel aber hinderlich 😂 Und vermeidbar.
Hier sieht man mal wieder deutlich wie gut doch Arduino ist! ...hihihi... Da muss man sich die Fehlermeldungen auch noch selber abholen, aber sie liegen bereit.
Hallo, im englischsprachigen Datenblatt, das man zu Beginn nicht verlinken braucht, https://www.analog.com/media/en/technical-documentation/data-sheets/ADXL345.pdf Seite 18 wird es interessant für I2C, die Schaltung ist relevant und es gibt zwei Adressen, unter denen das nette IC zu reagieren pflegt: ". Single- or multiple-byte reads/writes are supported, as shown in Figure 41. With the ALT ADDRESS pin high, the 7-bit I2C address for the device is 0x1D, followed by the R/W bit. This translates to 0x3A for a write and 0x3B for a read. An alternate I2C address of 0x53 (followed by the R/W bit) can be chosen by grounding the ALT ADDRESS pin (Pin 12). This translates to 0xA6 for a write and 0xA7 for a read." Die Geräteadresse wird im gezeigten Text nirgends gegeben, zumindest ist sie mir nicht ins Auge gefallen. Figure 41 gibt ergiebige Auskunft. "SLAVE ADDRESS + WRITE" sowie "SLAVE ADDRESS + READ" fehlen zu Anfang der Unterprogramme "ADXL_Write" "ADXL_Read_Single" "ADXL_Read_Double" wenn ich das richtig sehe. Nach dem Einschalten ist noch ein Ablauf notwendig: "After VS is applied, the device enters standby mode, where power consumption is minimized and the device waits for VDD I/O to be applied and for the command to enter measurement mode to be received. (This command can be initiated by setting the measure bit (Bit D3) in the POWER_CTL register (Address 0x2D).) In addition, while the device is in standby mode, any register can be written to or read from to configure the part. It is recommended to configure the device in standby mode and then to enable measurement mode. Clearing the measure bit returns the device to the standby mode." Auf den Ablauf zu "MULTIPLE-BYTE WRITE" verzichtete der Weihnachts-Programmierer, denn um 12 gab es Mittagessen.... MFG
:
Bearbeitet durch User
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.