LIS3LV02D: SPI tut nichts

Hallo Falk,

Falk Willberg schrieb:

Ja, ich :-)

Allerdings kann ich Dein Problem nicht nachvollziehen. Das Ding ist recht problemlos. Nur die Pinbezeichnung sind recht irreführend: Für SPI: CS = Low SCL/SPC = SPI-Clock SDA/SDI/SDO = SPI-Input SDO = SPI-Output

Man beachte das 2x "SDO"....

vg, Wolfgang

Wolfgang Mahringer schrieb:

Das hatte ich gehofft. Der zweite (einer darf defekt gewesen sein) verhält sich identisch.

So habe ich es gemacht. Das ist ja noch einfach.

SPI-Input/Output aus Sicht des Sensors, nehme ich an...

Ja, weiter hinten findet man dann die Ursache (3-wire SPI).

Danke erstmal, Falk

Am Mon, 19 May 2008 12:31:58 UTC schrieb Falk Willberg :

Leerlaufpegel der Taktleitung und aktive Taktflanke richtig eingestellt? Da gibt's immerhin vier Kombinationen, und nur eine funktioniert ...

Ade

Reinhard

Und nicht bei allen Bauteilen ist im Datenblatt die richtige angegeben.

Hallo Reinhard,

Reinhard Forster schrieb:

Guter Einwand.

Bei läufts mit Startpegel (Clk + SDO low), dann SDO Pegel setzen, dann SCL high und wieder low. Aus dem Datenblatt geht das nicht so genau hervor...

HTH Wolfgang

Wolfgang brachte einen guten Punkt auf: Sieh Dir an, wieviele Takte da genau reingehen. Viele Chips machen einen Abort oder Ignore, wenn die Anzahl der SCLK Zyklen vom erwarteten Wert auch nur um einen Takt abweicht.

Gerade mal im Datenblatt nachgesehen, mit Byte 0 liest er nicht aus. Zum Auslesen muss das erste Bit 1 sein. Seite 25:

Kranke DB-Schreiber gibts, tse tse. Man merkt bei STM öfters, das da Froschschenkelesser mitwirken.

Nimm i2c und gut iss. Hier mal wieder ein praktischer Grund für i2c.

- Henry

Henry Kiefer schrieb:

Das erste Byte ist ja das Lese-Kommando, das zweite Byte wird in diesem Sinne nicht gesendet. Es werden acht Takte erzeugt und zwischen 0 und eins gibt's ja nichts, was ich auf den Ausgang legen könnte ;-)

Clock Idle ist übrigens High, schreiben bei steigender Flanke.

Jaja, die Write-Only-Doku. Das Ding ist aber eher erträglich.

Wegen eines zickigen ICs die CPU wechseln? Der Sensor soll mal nicht glauben, wen er vor sich hat[0] ;-)

Falk [0]Frei nach Jürgen von Manger

Sieht aber im Datenblatt nach fallender Flanke aus. Jedenfalls sollte nach 8Fh ab dem achten Bit 3Ah rauskommen.

Also aehrlich, waer' ja wohl'n Dingen, woll?

...

Laut Fig. 3 soll es die steigende Flanke sein.

Leider bleibt DO ständig hochohmig....

Da muß ich noch irgendwo den Wurm drin haben....

Falk

Seite 24: "SDI and SDO are respectively the Serial Port Data Input and Output. Those lines are driven at the falling edge of SPC and should be captured at the rising edge of SPC."

Wobei Lesen auf der steigenden Flanke so aussieht, dass es knapp werden kann: th(SO) nach fallender Flanke ist 7nsec min. tv(SO) max ist 55nsec, waere mir fuer das Lesen zumindest bei voller Pulle von 8MHz und steigender Flanke zu haarig.

O-Ton eines AD App Ingenieurs, nachdem ich ihm versicherte, dass es nur auf der anderen Flanke geht: "Ahm, well, strange, then just take that one".

Grummel... Soso, wird DI "driven" oder "sampled"? Alles zu schwammig, jetzt habe ich die Nase voll und setze die Bits eben von Hand.

Wenn ich die Bits selber schubse, ist da überall reichlich Zeit :-(

...

Schön, sowas. Man sollte dafür Rechnungen stellen dürfen, daß man Manuals korrigiert...

Falk

SDI ist der Input des Chip, der ist "driven". SDO ist der Output und "sampled".

Manche Chips haben SPI Time-Out und machen bei Ueberschreiten einen Abort, habe aber auf Anhieb bei diesem so etwas nicht gesehen.

Das war noch gar nichts. Der Hammer waren mal handfeste Matheschnitzer in einem TE Controller. Habe ich das ganz Dingen kurzerhand diskret entwickelt, da hat man seine Ruhe. Allerdings hatte ich die Schnitzer trotzdem mitgeteilt.

Der echte Hammer traf mich aber wenige Monate nach dem Diplom. Sah auf dem Flugplatz durch Zufall einen ehemaligen Kommilitonen, der mir zu Studienzeiten nicht gerade durch Praxisahnung aufgefallen war und etwa zur gleichen Zeit sein Diplom bekam. "Was machst Du denn jetzt?" ... "Ich schreibe Application Notes"

Falk Willberg schrieb:

i2c brauch nur Bit-Banging und das kriegt ein ordentlicher Bitbanger-Head doch hin, oder?

- Henry

Ausser wenn I2C sich mal wieder aufhaengt, dann ist Banging Head on Table angesagt :-)

Henry Kiefer schrieb:

Hab' ich noch nie gemacht. Vor den paar Bits bin ich nicht bange[0], aber das Protokoll kenne ich nicht.

Mal sehen, was /usr/src/linux-2.6.22.17-0.1/drivers/i2c/i2c-core.c und Konsorten hergeben.

Falk [0]Und noch'n $ in die Kalauerkasse

Wolfgang Mahringer schrieb:

Danke, ich werde das mal "manuell" probieren...

Falk

Ich hatte vor 15 Jahren auch mal einen mir nicht aufzufindenden Fehler in einem solchen Bitbanger drin. Aber es gibt ja noch Kollegen, wenn Kiefer den Wald vor Bäumen nicht mehr sieht :-)

i2c kann sich eigentlich nicht aufhängen. Wenn, dann ist es eine defekte Software. In den einfachen Chips werden simple State-Machines benutzt.

Und es gibt noch eine vom Master kommende eher _geheime_ Bussequenz, mit der ein Bus-Reset erzwungen werden kann.

Einer der wenigen Unterschiede zwischen i2c und SMBus ist übrgens ein definierter time-out. Intel hat also bereits in der Hardware-Spec Rücksicht auf M$ genommen ;-) (He he)

- Henry