ATMEGA88A/Beschleunigungssensor (ADXL345)

C.png??
Ich kann es nicht ohne weitere Hilfsmittel lesen.

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 ...

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.

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.

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.

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