MoinMoin,
kennt jemand von euch zufällig den LSM6DSL von STM? Ein
Gyro/Accelerometer. Ich hab den auf dem IKS01A2-Sensorbord. Das
Accelerometer macht klaglos was soll. Aber das Gyro liefert mir nur beim
ersten Auslesen einen Satz Werte für X-, Y- und Z-Achse, nach jedem
Reset die selben. Ich vermute, dass ich irgendwie die falschen Register
auslese, da sich die Werte auch nicht ändern, wenn ich FULL_SCALE(den
Messbereich) ändere. Würde nur einmal ein Wert ausgelesen werden, sollte
der sich ja mit dem Messbereich ändern... Auf der anderen Seite wäre es
schon komisch, wenn die Register im Datenblatt falsch angegeben wären.
Die Register von Gyro und Accelerometer liegen direkt hintereinander
weg.
Die "Initialisierung" vom Accerometer besteht nur darin das CTRL1_XL
Register zu setzen. Das mach ich auf 0b10001100 und ich kann mir die
Werte abholen, kein FIFO kein ganix... Beim Gyro klappt das aber einfach
nicht. Die Controlregister gehen auf Seite54 im angehängten Datenblatt
los. Dabei ist mir auch aufgefallen, dass auf Seite 55 in Table46 bei
FS_XL steht, 00 = 2g, 01 = 16g, 10 = 4g, 11 = 8g ist. Alle anderen Werte
die mir begegnet sind, sind in anständig aufsteigernder Reihenfolge.
Dass kommt mir irgendwie quer Beet vor...
Der Forumssuche scheint der LSM6DSL völlig unbekannt zu sein, auch
Google konnte mir nicht recht weiterhelfen, dass förderte lediglich
jemanden zu Tage, der Probleme hatte, eine Achse des Gyros in den FIFO
zu bekommen....
Meine Init sieht vom LSM6 sieht folgendermaßen aus:
Kann jemand irgendwas dazu sagen, wieso die Reihenfolge der
Messbereichsbits in Table 46 so durcheinander ist und ob das so sein
soll? Und vor allem etwas hilfreiches zu dem Problem, dass mir das
Gyroskop seine Werte verweigert?
MfG Chaos
P.S.
Die Achswerte vom Gyro sind übrigens 4 für die X-, 0 für die Y- und 1024
für die Z-Achse, falls das weiterhelfen sollte. Und die Werte sind
jeweils 16bittig.
Ich hab mir nun eine Funktion geschrieben, die einfach alle Register,
die mit 8 Bit möglich sind, 2 mal im Abstand von einer Sekunde abfragt
und dass dann auf unterschiedliche Werte vergleicht. (Während der
Abfrage schüttel ich das ganze Gebilde wild hin und her, dass möglichst
unterschiedliche Werte rauskommen sollten).
Dabei bekomme ich die 6 Register vom Accelerometer (X-,Y- und Z- je High
und Lowbyte) diese liegen wie im Datasheet angegeben von 0x28 - 0x2D.
Dann bekomme ich noch einen 6er Satz Register ausgegeben, diese liegen
von 0xA8 - 0xAD. Jedoch bekomme ich aus diesen Registern die selben
Werte wie aus den Accelerometer-Registern aus dem Datenblatt.
Laut Datenblatt sollten über 0x75 eigentlich gar keine Register mehr
kommen...
Weiß denn wirklich niemand was zu diesem Chip?
J. T. schrieb:> Es darf auch gern jemand was sagen, der den Chip nicht kennt, aber> trotzdem eine Vermutung hat, was ich falsch mache....
Poste doch mal die Registerwerte (zusammen mit der Adresse).
J. T. schrieb:> Ich hab mir nun eine Funktion geschrieben, die einfach alle Register,> die mit 8 Bit möglich sind, 2 mal im Abstand von einer Sekunde abfragt
Jedi Knight schrieb:> Poste doch mal die Registerwerte (zusammen mit der Adresse).J. T. schrieb:> Dabei bekomme ich die 6 Register vom Accelerometer (X-,Y- und Z- je High> und Lowbyte) diese liegen wie im Datasheet angegeben von 0x28 - 0x2D.
Die Werte sind je nachdem in welche Richtung ich es halte,
unterschiedlich. Halte ich es waagerecht, bekomme ich 1g auf der Z-Achse
und 0 auf den anderen.
J. T. schrieb:> Dann bekomme ich noch einen 6er Satz Register ausgegeben, diese liegen> von 0xA8 - 0xAD.
Wie gesagt, die Werte sind immer die selben wie in den 0x28-0x2D. Aber
natürlich jedesmal anders, da die ich vermutlich nicht bei jeder Messung
in die gleiche Richtung halte.
Alle anderen Register verändern sich zwischen den Messungen nicht.
J. T. schrieb:> Wie gesagt, die Werte sind immer die selben wie in den 0x28-0x2D. Aber> natürlich jedesmal anders, da die ich vermutlich nicht bei jeder Messung> in die gleiche Richtung halte.
Ich kann dir nicht folgen. Ich kann den Satz nicht verstehen.
Naja. Ich lese 2mal alle Register von 0x00 bis 0xFF ein, und Speicher
die Werte weg, während ich die Messplattform bewege, damit dann auch
unterschiedliche Werte in den Registern landen, die für die Drehraten-
und Beschleunigungswerte da sein sollten.
Die einzigen Register mit Änderungen sind die 6 vom Accel und dann
nochmal ein 6er Satz Register, der aber jedes mal die selben Werte wie
die Accel-Werte hat. Die Adresse dieser Extra-Register ist die Adresse
vom Accel-Reg + 0x60....
Könnte der Grund hier liegen?
> 5.1 Operating modes> In the LSM6DSL, the accelerometer and the gyroscope can be> turned on/off independently of each other and are allowed> to have different ODRs and power modes.> The LSM6DSL has three operating modes available:> only accelerometer active and gyroscope in power-down> only gyroscope active and accelerometer in power-down> both accelerometer and gyroscope sensors active with independent ODR
Jedi Knight schrieb:> Ich kann dir nicht folgen. Ich kann den Satz nicht verstehen.
Nunja, meine Funktion sucht nach unterschiedlichen Werten in den
Registern.
Jedi Knight schrieb:>> 5.1 Operating modes>> In the LSM6DSL, the accelerometer and the gyroscope can be>> turned on/off independently of each other and are allowed>> to have different ODRs and power modes.>> The LSM6DSL has three operating modes available:>> only accelerometer active and gyroscope in power-down>> only gyroscope active and accelerometer in power-down>> both accelerometer and gyroscope sensors active with independent ODR
Das hab ich, meine ich zumindest, hiermit abgehandelt:
J. T. schrieb:> Send_Buffer[0] = CTRL1_ACCEL;> Send_Buffer[1] = HighPerfomance2g;> HAL_I2C_Master_Transmit(&hi2c1, LSM6DSL_Adr, &Send_Buffer[0], Size,> I2C_Timeout);>> Send_Buffer[0] = CTRL2_GYRO;> Send_Buffer[1] = HighPerformance500dps;> HAL_I2C_Master_Transmit(&hi2c1, LSM6DSL_Adr, &Send_Buffer[0], Size,> I2C_Timeout);>> Send_Buffer[0] = CTRL7_G;> Send_Buffer[1] = HPF_En;> HAL_I2C_Master_Transmit(&hi2c1, LSM6DSL_Adr, &Send_Buffer[0], Size,> I2C_Timeout);>> Send_Buffer[0] = CTRL4_C;> Send_Buffer[1] = DRDY_MASK;> HAL_I2C_Master_Transmit(&hi2c1, LSM6DSL_Adr, &Send_Buffer[0], Size,> I2C_Timeout);Michel M. schrieb:> IKS01A2 LSM6DSL & GitHu enthält keine Beispiele ?
Ich hatte, wenn ich mich recht entsinne nach "LSM6DSL no Gyro Data"
gesucht. Da hatte ich lediglich jemanden gefunden, der Probleme damit
hatte, eine Achse vom Gyro in den FIFO zu bekommen...
Aber deinen Suchbegriff werd ich direkt nochmal versuchen.
@Jedi Knight:
Ja gerade nochmal nachgeschaut. Mit CTRL1_XL (bzw ich habs bei mir
irgendwie CTRL_Accel genannt) aktiviert man dass Accelerometer und mit
CTRL2_G das Gyro...
Wie wahrscheinlich ist es denn, dass das Gyro einfach defekt ist?
Michel M. schrieb:> ... mal unter Self-test ...... Ergebnis ?!
Da kommen die Werte fürs Gyro unverändert wie im Startpost genannt. 4,
0, 1024. Keine Änderung.
Ich bin mir aber auch nicht sicher, das mit dem Selftest richtig
verstanden zu haben...
Ist das richtig, dass der eine Selftest einfach ein positives und der
andere Selftest einfach ein negatives Offset zufügt?
Also Register auslesen, dann selftest wählen, nochmal Register auslesen.
Dann sollte ich, solang ich nichts bewegt habe, den selben Wert wie beim
ersten auslesen +- Offset?
Ich hab nun den Selftest mal gemäß der AN nachprogrammiert. (das 5-fach
Auslesen und Durchschnitt bilden hab ich weggelassen, da ich eh im
Singlestep durchgehe. Ich habs auch einmal mit probiert, nur um
sicherzugehen, dass es keinen Unterschied macht).
Ich bekomme immer noch statische Werte, aber die Z-Achse hat sich im
Vergleich zu meinen vorherigen Versuchen geändert, ich vermute aufgrund
der anderen FullScale-Einstellung im Selftest.
Ich bekomme nun 4, 0, 1792. Unabhängig davon ob ich den Selftest nun
aktiviert habe oder nicht...
So sieht der Selftest aus
J. T. schrieb:> Wie wahrscheinlich ist es denn, dass das Gyro einfach defekt ist?
Habe ich auch schon oft gedacht. Im Endeffekt war der Fehler (fast)
immer bei mir.
Das Problem an der Sache ist und bleibt China & Co. Nicht umsonst ist
BOSCH einer der größeten Chip-Hersteller der Welt geworden. Eigenbedarf
lautet der Grund, denn die (teilw. auch gefährlichen) Hardwarefakes
toppen alles, was sich das menschliche Gehirn ausdenken kann, um Welten.
Ist heute leider so und daher kann es durchaus sein, wenn du ins Klo
gegriffen hast. Kauf halt ein neues. Neues Spiel, neues Glück. Oder
neues Pech ;)
Jedi Knight schrieb:> Habe ich auch schon oft gedacht. Im Endeffekt war der Fehler (fast)> immer bei mir
Ja das kenn ich nur zu gut :D
Aber dass ich nen Fake bekommen habe, kann ich mir fast nicht
vorstellen. Dieses IKS01a2 Sensorboard hab ich auf ner Hands-On-Session
direkt von STM abgegriffen.
Dank dir für die Durchhalteparolen, aber langsam bin ich am Ende mit
meinem Latein....
Michel M. schrieb:> versucht ?> https://community.st.com/s/question/0D50X00009XkXheSAF/lsm6dsl-faulty-reading
Das scheint der zu sein, den ich per Googlesuche gefunden hatte. Der hat
ja nur Probleme mit der Z-Achse vom Gyro gehabt, was vermutlich
irgendwie mit Timestamps und dem FIFO zu tun hatte. Aber der Thread
endet auch mitten im Thema...
Bei mir ändern sich die Gyrowerte einfach nicht. Egal um welche Achse
ich das Bord wie schnell drehe.
J. T. schrieb:> Bei mir ändern sich die Gyrowerte einfach nicht. Egal um welche Achse> ich das Bord wie schnell drehe.
Geh das Datenblatt noch mal in Ruhe durch und vergleiche mit dem
Programm, ob alles korrekt enabled ist. Meist ist es ja nur eine winzige
Kleinigkeit, die man übersehen, oder der man nicht genügend Beachtung
geschenkt hat. Ich hätte ja mitgesucht, aber bei über 100 Seiten mit
meinem schlechten Englisch tut mir der Kopf nur beim Drandenken schon
weh, sorry ;)
..und die Umsetzung Logik-Physik. Es gibt Register/Ports, wo nach CLR 1
drin steht, und nach SET steht 0 drin. Oder so ähnlich. Oder der
aktuelle Inhalt wird mit PORTBIT=1 getogglet. Irgendwas in dieser
Richtung, was man nicht sieht, weil man nicht damit rechnet, dass es
sowas geben kann.
Sorry, wenn ich keine Details bzw. keine konkreten Lösungsvorschläge
nennen kann.
Variablenüberprüfung, ob der Type stimmt, fällt mir noch ein.
Gibt es bei der Umsetzung der defines unerkannte Typisierungsfehler?
uint8_t, wo uint16_t sein sollte. Compiler schluckt es, Programm läuft.
Aber nicht richtig.
Das sind alles Dinge, die mir schon passiert sind, und wo man sich einen
wolf sucht, obwohl man den Fehler manchmal direkt vor den Augen hat.
Jedi Knight schrieb:> Geh das Datenblatt noch mal in Ruhe durch und vergleiche mit dem> Programm, ob alles korrekt enabled ist. Meist ist es ja nur eine winzige> Kleinigkeit, die man übersehen,
Ja richtig, dass ist es meistens auch bei mir. Nur kommt bei mir
erschwerend eine fiese "Betriebsblindheit" dazu. Umso öfter ich alles
nochmal durchgegangen bin, ohne einen Fehler zu finden, umso geringer
wird die Wahrschenlichkeit, dass ich ihn beim nächsten mal finde :D. Und
ich bin es nun schon einige Male durchgegangen...
Jedi Knight schrieb:> ..und die Umsetzung Logik-Physik. Es gibt Register/Ports, wo nach CLR 1> drin steht, und nach SET steht 0 drin. Oder so ähnlich. Oder der> aktuelle Inhalt wird mit PORTBIT=1 getogglet
Ja sowas kenn ich auch noch von den Atmegas... Aber alle Register die
ich anfasse erwähnen mit keinem Wort etwas davon, dass sie "umgedreht"
sind.
Jedi Knight schrieb:> Sorry, wenn ich keine Details bzw. keine konkreten Lösungsvorschläge> nennen kann.
Brauchst dich doch nicht entschuldigen. Ich freu mich schon darüber,
dass du versuchst zu helfen.
Jedi Knight schrieb:> Variablenüberprüfung, ob der Type stimmt, fällt mir noch ein.
Laut Datenblatt werden die Werte über 2 8-bit Breite Register als 16-bit
Wert ausgegeben. Im 2er Komplement. --> int16_t. Das klappt ja auch
wunderbar beim Accelerometer.
Jedi Knight schrieb:> Gibt es bei der Umsetzung der defines unerkannte Typisierungsfehler?
Es wird ohne Warnungen kompiliert. (nur ein paar unused-variable
Warnungen)
Jedi Knight schrieb:> Das sind alles Dinge, die mir schon passiert sind, und wo man sich einen> wolf sucht, obwohl man den Fehler manchmal direkt vor den Augen hat.
Ja wie gesagt, dass kenn ich nur zu gut. Gerne mach ich mal ein "<"
statt eines ">" oder sowas, und da kann man sich echt blöd dran suchen.
Michel M. schrieb:> https://microsoft.github.io/azure-iot-developer-kit/docs/apis/lsm6dsl/#readreg> ...* vielleicht Untersch. zw Reg u. Data ?!
Ich benutze die HAL_I2C zum Auslesen, der will auch einen Pointer sehen,
wo er die Daten aus den Registern hinschmeißen soll. Ich übergebe der
Funktion einach die Adresse meiner X- Y- und Z-Variablen. Und wie
gesagt, beim Accelerometer klappt ja alles wunderbar...
J. T. schrieb:> Laut Datenblatt werden die Werte über 2 8-bit Breite Register als 16-bit> Wert ausgegeben. Im 2er Komplement. --> int16_t.
Allignment-Verschiedenheit ?
int16_t => uint16_t ?
"2er Komplement" ist auch ein üblicher Verdächtiger
***
bals weiß ich nichts mehr
Ich hab nun von den Beispielen die bei X-CUBE-MEMS dabei sind, das
DataLogTerminal aufgespielt. Dabei bin ich nach Seite 10/11 im
verlinkten PDF vorgegangen. Aber irgendwie findet die PC GUI keinen
COM-Port...
Dann hab ich mal HyperTerm angeschmissen, das findet aber auch keinen
COM-Port...
Ich werd mal schauen, ob ich im Quelltext vom Beispiel etwas finden
kann. Evtl wird die UART ja nicht richtig initialisiert.
Der COM-Port wird nun gefunden. Nachdem ich den ST-LINK Firmware-Update
wie im PDF gemacht hatte, war es Version 33.irgendwas.
Ich hab dann nochmal die STM32 ST-Link Utility Software benutzt, und
konnte auf Version 32.irgendwas "updaten". Seit dem wird der COM-Port
wieder gefunden.
Aber diese Unicleo-GUI sagt "Expansion Board: Unknown Firmware
Version: Unknown"
Jedi Knight schrieb:> Allignment-Verschiedenheit ?>> int16_t => uint16_t ?>> "2er Komplement" ist auch ein üblicher Verdächtiger
Gestern gar nicht mehr gesehen, dass du noch was geschrieben hattest.
Ich denke, dass mit dem 2er Komplement hab ich richtig umgesetzt. Wie
gesagt, die Werte vom Accelerometer sind total plausibel. Halte ich das
Bord waaagerecht, hab ich 0g, 0g, 1g, halte ich es überkopf bekomme ich
0g, 0g, -1g.
Nur auf dem Gyro bekomme ich drehgeschwindigkeitsunabhängig statische
Werte...
Und da der Selftest auch nichts an den Werten ändert, gehe ich langsam
davon aus, dass das Gyro tatsächlich kaputt ist.
=(
J. T. schrieb:> Aber diese Unicleo-GUI sagt "Expansion Board: Unknown Firmware> Version: Unknown"
Okay wenn man dann das DataLogExtended statt dem nicht extendedetem
DataLog nimmt, dann wird das Bord auch gefunden.
Aber irgendwie kann ich so überhaupt gar nichts auslesen. Es gibt
Buttons zum Register auslesen und setzen. Aber es tut sich nichts, egal
ob ich im Play-Modus oder im gestopt bin.
Ich hab auch nochmal mit HyperTerm auf den COM-Port geschaut. Da kommt
quasi nichts. Nachdem ein paar mal planlos auf den Reset- und den
Userbutton gedrückt hab, kam aufeinmal "C0 A0 C2 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 A4 C5"
Hmm. Also wenn ich einmal auf Reset drücke und dann den User-Button
drücke, kommen drei Werte über den COM-Port. Die scheinen mir aber
irgendwie ziemlich zufällig. Aber nachdem ich nun ein paar mal öfter
gedrückt habe, wiederholen sich einige Werte. Es sieht grad wie folgt
aus: "C7 19 ED C8 A4 C5 88 94 ED C7 19 ED A4 CD C6 A0
C2 C8 B4 CD C0 A0 C1 88 94 ED C0 A0 C3"...
J. T. schrieb:> HAL_I2C_Mem_Read(&hi2c1, LSM6DSL_Adr, GYRO_X_REG_L, 1,> &Recieve_Buffer[0], 2, I2C_Timeout);
Die HAL-Funktionen geben auch einen Status zurück. Für eine Fehlersuche
schlage ich vor, diesen Status auch auszuwerten.
P.S.: Es heisst "Receive"
Pete K. schrieb:> Die HAL-Funktionen geben auch einen Status zurück. Für eine Fehlersuche> schlage ich vor, diesen Status auch auszuwerten.
Aber damit würde ich doch lediglich erfahren, ob die I2C-Funktionalität
Fehler hat. Die läuft aber, sonst hätte ich doch gar keinen Zugriff auf
die ganzen Sensoren?
Mich wunder nun nur, dass das Beispiel von ST so gar nichts ausgiebt.
Angeblich soll mans nur kompilieren und laufen lassen und bekommt dann
Werte in dieser GUI
>> P.S.: Es heisst "Receive"
Ist geändert:D
@ chaos Ich habe mit diesen Sensoren noch nie zu tun und kenne nur grob
die Basics. Darf ich mal was fragen, statt zu googeln? Wieso eigentlich
6 Achsen? Ich hätte angenommen, auf 3 kann man alles nötige abbilden?
Natürlich täusche ich mich, aber welches sind denn die 6 Achsen?
Jedi Knight schrieb:> Wieso eigentlich> 6 Achsen? Ich hätte angenommen, auf 3 kann man alles nötige abbilden?> Natürlich täusche ich mich, aber welches sind denn die 6 Achsen?
Weil du 3 Achsen vom Accelerometer und 3 Achsen vom Gyroskop hast. Die
zeigen zwar jeweils in die selben Richtungen, sind aber irgendwie auch
unabhängig voneinander. Auf diesem Bord ist auch noch ein drei achsiger
Magnetsensor, so dass das ganze vom Marketing vermutlich als 9-axes-IMU
oder so ähnliche aufgeschwatzt wird.
Nein leider niccht. Nun ist am Nucleo auch noch, vermutlich, der
Spannungsregler durchgebrannt. Meine letzte Meinung ist aber immer noch,
dass das Gyro kaputt ist... Ich habs erstmal zur Seite gelegt.
Sollte sich nochmal was tun, werde ich aber hier berichten.
Thread beobachten
Seitenaufteilung abschalten