STM32F4 Discovery Version mit anderem MEMS-Sensor?

[Andre Z. (slamy)]

Hallo Ihr lieben,

ich wollte mich mal ein bissle in die STM32-Welt einarbeiten, um einen 
Vergleich mit meiner bekannten NXP LPC-Welt zu schaffen. Ich habe mir 
dazu das relativ günstige STM32F4 Discovery Board bei einem ebay-Handler 
geschossen.

Das Board funktioniert eigentlich recht gut, zumindest dachte Ich das 
anfangs. Der MEMS-Sensor verweigert jede Funktion und gibt stetig die 
gleichen Beschleunigungswerte zurück, egal wie Ich es halte. Da Ich 
vermutet habe, dass meine eigene Schusseligkeit zu einem Tod des Sensors 
geführt hat, habe Ich beim gleichen Händler nochmal eines gekauft. 
Leider habe Ich dort einen Fehler gemacht und statt die eingebaute 
Firmware zu testen, direkt ein Beispiel von ST aufgespielt und erhalte 
hier das gleiche Ergebnis mit anderen Beschleunigungswerten.

Mittlerweile habe Ich das Gefühl, dass es eine Art andere Version (oder 
ein Plagiat) ist. Ein Arbeitskollege hat mir seines ausgeliehen und Ich 
stelle fest, dass der MEMS Sensor auf diesem eine gänzlich andere Form 
hat, da dieser eine rechteckige Form hat, während meiner ein 
quadratisches BGA Package ist. Mit diesem Board funktionierten dann auch 
die Beispiele.

Meine Frage nun an euch... ist jemand unter euch, der ebenfalls diese 
andere Version des Boards besitzt? Der Händler hat bisher nicht reagiert 
und jetzt 2 Versionen von diesem Board hier rumfliegen zu haben, 
frustriert schon sehr stark.
Anbei gibts auch ein Foto von dem fraglichen IC.

Grüße
Euer Slamy

[Gerhard W. (gerhard86)]

Die ST Website verspricht "LIS302DL or LIS3DSH ST MEMS 3-axis 
accelerometer", der LIS3DSH hat das Quadratische LGA-16, der LIS302DL 
das 3*5mm² LGA-12. Insofern sollte da nichts verkehrt sein, aber es 
könnte sein dass die Kommunikation etwas anders ist (im Zweifelsfalle 
Datenblatt befragen). Dass der Ebay-Händler Mist verkauft kann man nicht 
100% ausschließen, aber das Board sieht bis auf das andere Gehäuse des 
Beschleunigungssensors exakt wie meines aus.

[user (Gast)]

Hallo ich glaube nicht das es sich um ein Plagiat handelt.
Bei den Preisen für das Board lohnt sich das sicher nicht.

Könnte aber sein, dass ST unterschiedliche Versionen herausgebracht hat.
Ich meine mich zu erinnern, dass es auch ein neues F4 Derivat gibt.
Was sagt die ST-Web Seite? Dort gibt es entsprechende Dokumentation und 
Beispiel-Code zu den Discovery-Boards.

[Kurt B. (kurt)]

Es gibt verschiedene Revisionen des Boards. Der Beispielcode wurde für 
REV A geschrieben, mit LIS302DL.

Aktuell ist REV C mit einem LIS3DSH. Beide MEMS sind nicht direkt 
Softwarekompatibel.

Oben rechts auf dem Board steht die Revision: MB997A bzw. MB997C.

Mfg,
Kurt

[Andre Z. (slamy)]

Kurt,  Ich könnte dich küssen!
Woher hast du diese Information nur? >_<
Es funktioniert jetzt.

Vielleicht an alle Gleichgesinnten, den man damit helfen kann:
Der LIS3DSH ist präziser als der LIS302DL, da ersterer über 16-Bit 
Ausgaberegister verfügt. Der Registersatz ist vollkommen anders, weshalb 
man nicht auf das Beispiel 
Utilities/STM32F4-Discovery/stm32f4_discovery_lis302dl.c aus der Library 
von deren Website zurückgreifen kann. Ob es eine Ersatzlibrary für 
dieses schändliche Versionsproblem gibt, weiß Ich zwar immer noch nicht. 
Aber die Änderungen halten sich in Grenzen, sodass man diese Datei durch 
Modifikation an den 3DSH anpassen kann. Wichtig ist, dass 
LIS302DL_ReadACC() statt der 8 Bit nun 16-Bit zu lesen hat und diese 
entsprechend der Endianess richtig zusammensetzt. Da der Baustein und 
der ARM eine gleiche haben, reicht hier ein Union aus chars und shorts, 
um das zu bewerkstelligen.
Die Funktion LIS302DL_Init() muss komplett überarbeitet werden aber das 
Datenblatt erklärt die Register relativ gut.
Alle anderen Funktionen aus dieser Datei können weiterhin verwendet 
werden.
Speziell die extrem lange LIS302DL_LowLevel_Init() kann beibehalten 
werden.

Geändert werden muss ansonsten noch die Funktion LIS302DL_Read(), die im 
Falle eines Multi-Byte Reads ein spezielles Bit setzt, welches beim 3DSH 
in einem Register und nicht im Protokoll umgesetzt ist. Das setzen diese 
Bits ist in dieser Funktion zu deaktivieren.

Mein Problem wurde hiermit gelöst und dieser Thread kann geschlossen 
werden. :-)