VL53L1X mit AVR

[Holomino]

Hat hier jemand schon mal den VL53L1X unter nem ATMega (jenseits von Arduino und STM) ans Rennen bekommen?

Ich drück mich da gerade etwas rum: Ich hab den Sensor da, aber absolut keinen Bock, für nen kleinen Test den Arduino-Wire-Kram auf C zu portieren.

[Ceos]

erstmal ganz kurze Frage weil mir die Kinnlade auf dem Boden schleift, das Ding hat 16x16 ToF Pixel die man selektiv (2x2 Area) nutzen kann?!
Von der Doku her kurz reingelesen scheint es mir als ob die einem garnicht die Wahl lassen als deren Treiber zu nutzen, irgendwie bisschen doof.

Aber der API Doku nach zu lesen denke ich das porten sollte grundsätzlich garkein Problem sein, sofern da keine Funktionalität außer I2C genutzt wird ... leider lässt mich ST die API nicht ohne Anmeldung runterladen

[Holomino]

Das Porten ist schon nen Problem, weil die STM-Jungs Dich mit 40 Code-Dateien beschmeißen (ich hab die API bereits runtergeladen) und Dir durch die Blume mitteilen: Die API ist die Referenz (also kein Registerdatenblatt, kein Minimalbeispiel, da stehe ich schon mal gar nicht drauf).
Ich habe auch schon ne Implementierung für den AVR gefunden (https://github.com/SensorDots/MappyDotPlusFirmware), aber die ist noch aufgeblähter als das Original.

Drum dachte ich mir, vielleicht hat's jemand hier schon mal etwas schlanker portiert und lässt mich partizipieren (Dann kann ich mit die 3+x Tage geschätzte Umsetzung sparen).


(warum bekommst Du Muskelschwäche in der Kinnlade? Die Dinger gibt's seit geraumer Zeit z.B. bei EXP-Tech)

[Ceos]

(also kein Registerdatenblatt, kein Minimalbeispiel, da stehe ich schon mal gar nicht drauf)

Ganz deiner Meinung, ich muss mir nur mal ne neue spammail basteln dann lad ich mri das mal und guck mal rein, ob der moppes portfähig ist ... die github lösung ist auch irgendwie sehr speziell mit dieser mappersache da drin


https://github.com/pololu/vl53l1x-ar...er/VL53L1X.cpp

die sieht schonmal schlanker aus, auch wenn es ein bisschen polulu typisch mit makro zugekackt ist XD

https://github.com/sparkfun/SparkFun...rduino_Library

sparkfun hat eine relativ saubere lösung (persönliche meinung)

https://github.com/stm32duino/VL53L1X/

ich glaube aus der kann man fast am meisten gewinnen

[Holomino]

So, hat etwas gedauert, bis ich mich drangetraut (endlich mal Ruhe dafür gefunden) habe. Nicht ganz, wie vermutet 3+x Tage: es waren nur 2 Tage.
Anbei der allerallererste Test, quasi die Abkupferung des Polulu-Arduino-Beispiels als entarduinote, reine AVRStudio-Version. Naturgemäß wird es so mit knapp 6kB etwas kleiner auf dem Controller. Wer Spaß hat und C kann, der wird wohl die Wertabfrage aus der main-Funktion auf'n Timer-Interrupt legen.

Ich hab noch die ROI-Funktion hinzugefügt. In den Sparkfun-Quellen sind sie zwar falsch implementiert, aber immerhin findet man eine Spur, wohin die Reise geht. In der Original-ST-API habe ich mich nach der dritten Ebene ehrlich gesagt schwer am Kopf gekratzt, die rechnen da von links nach rechts und wieder zurück, völlig oversized, kein Wunder, dass die API so groß wirkt.

Vorweg noch dazu: Wer die ROI-Funktion nutzen will (immerhin bekommt man nominal seinen Erfassungswinkel mit 4x4 Spads auf 17° beschränkt), muss mit massiven Reichweiteneinbußen rechnen. Bei ca. 40cm war bei mir mit dem aus dem Chip zurückgegebenen validen Messstatus Schluss. Aber auch das ist im DB des Sensors irgendwo beschrieben.

Testhardware: 8MHz-ATMega168 mit UART, TWI und drei KontrollLEDs.

Anbei auch noch die Quellen des PC-Testprojektes (C# VS2010), damit man was von der Wertanzeige hat.

Controller: VL53L1XTest.zip
PC: VL53L1XTest_CS.zip

[Holomino]

Nachgereicht: Den VL53L1X als Nahfeldsensorik mit ca. 20° nach unten geneigt auf einer drehenden Sensorplattform (60U/min) zusammen mit einem LidarLite V1.

Brett und Schraubenkasten liegen unterhalb der horizontalen Messebene des LidarLite (blaue Messpunkte), können aber durchaus vom VL53L1X (schwarze Messpunkte) ab einem Abstand von ca. 40cm erkannt werden (gelber Kreis markiert 50cm Abstand).

Messergebnis


Szene