LIS3LV02D: SPI tut nichts

SPI ist ja kein Hexenwerk. Allerdings mag mein LIS3LV02D (Accelerometer von ST-Micro) nicht.

Laut Manual habe ich /CS auf LOW, sende ein Byte 0x8f (Read WHOAMI),dann ein Byte 0.

Daten und Takt sehe ich auf dem Scope.

Nach dem ersten Byte sollte der Sensor mit 0x3a antworten, SDO bleibt aber konstant High.

Hat jemand Erfahrung mit dem Ding?

Gruß, Falk

Reply to
Falk Willberg
Loading thread data ...

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

--
From-address is Spam trap
Use: wolfgang (dot) mahringer (at) sbg (dot) at
Reply to
Wolfgang Mahringer

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

Reply to
Falk Willberg

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

--
Dipl-Ing. Reinhard Forster        Software-Entwicklung         
Mikroprozessor-Anwendungen        D-76149 Karlsruhe
Reply to
Reinhard Forster

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

--
Gruesse, Joerg

http://www.analogconsultants.com/
 Click to see the full signature
Reply to
Joerg

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

--
From-address is Spam trap
Use: wolfgang (dot) mahringer (at) sbg (dot) at
Reply to
Wolfgang Mahringer

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.

--
Gruesse, Joerg

http://www.analogconsultants.com/
 Click to see the full signature
Reply to
Joerg

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

formatting link

--
Gruesse, Joerg

http://www.analogconsultants.com/
 Click to see the full signature
Reply to
Joerg

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

--
www.ehydra.dyndns.info
Reply to
Henry Kiefer

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

Reply to
Falk Willberg

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?

--
Gruesse, Joerg

http://www.analogconsultants.com/
 Click to see the full signature
Reply to
Joerg

...

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

Reply to
Falk Willberg

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

--
Gruesse, Joerg

http://www.analogconsultants.com/
 Click to see the full signature
Reply to
Joerg

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

Reply to
Falk Willberg

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"

--
Gruesse, Joerg

http://www.analogconsultants.com/
 Click to see the full signature
Reply to
Joerg

Falk Willberg schrieb:

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

- Henry

--
www.ehydra.dyndns.info
Reply to
Henry Kiefer

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

--
SCNR, Joerg

http://www.analogconsultants.com/
 Click to see the full signature
Reply to
Joerg

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

Reply to
Falk Willberg

Wolfgang Mahringer schrieb:

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

Falk

Reply to
Falk Willberg

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

--
www.ehydra.dyndns.info
Reply to
Henry Kiefer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.