Moin, ich wollte in ein Projekt den in Betreff genannten Sensor einbringen. Der Zugriff erfolg über I2C. Da mein ganzes Projekt auf Python basiert, wollte ich den Sensor auch dementsprechend mit in das Projekt Einpflegen. Jetzt habe ich mich durchs Datenblatt gekämpft und sehe folgendes: "The customer must use the VL53L1X software driver for easy and efficient ranging operations to match performance and accuracy criteria. Hence full register details are not exposed. The customer should refer to the VL53L1X API user manual (UM2356)." Das heißt die RegisterMap wird vom Hersteller nicht freigegeben und man wird gezwungen die API (In C geschrieben) zu nutzen. Da ich nicht so in dem Thema drin bin, meine Frage. Kommt sowas häufig vor und wieso macht der Hersteller das? Es gibt für Python zwar eine Library, die mir aber nichts nützt, da ich einige Konfigurationen ändern muss, die mit der PythonLibrary nicht verfügbar sind.
:
Bearbeitet durch User
Ich habe das Ding vor ein paar Monaten benutzt. Ein Register-Set mit Inhalten ist wohl intern vorhanden, wird aber nicht nach aussen geführt und dokumentiert. Dokumentiert ist alleine die C-Api. Die habe ich dann letztendlich auch benutzt. Die gesamte C-Api hat über 10000 Zeilen, ich würde nicht versuchen, das noch nach Pyton zu portieren. Letztendlich werden nur ein Dutzend Funktionen gebraucht: die in den Flussplänen der API-Beschreibung. Die könnte man in einem C-Programm über ein Interface nach draussen bringen.
Chris M. schrieb: > Da ich nicht so in dem Thema drin bin, meine Frage. > Kommt sowas häufig vor und wieso macht der Hersteller das? In manchen Bereichen ist das (leider) das einzig übliche Vorgehen. Das verschafft dem Hersteller einige Vorteile, denn er muss keine Details über die Hardware preisgeben und kann einen Teil der Funktionalität (z.B. Berechnungen) in Software auslagern. Das reduziert Support-Anfragen von unfähigen Entwicklern, die an der Mathematik scheitern. Solange die API kompatibel bleibt, kann der Hersteller die gesamte Hardware beliebig ersetzen, ohne sich um Kompatiblität zu kümmern. Die Hardware darf beliebig kaputt sein, weil die Software mit Workarounds kommt. Die API kann in der Zukunft erweitert werden, ist ja nur Software. Außerdem ist der Kunde an den Hersteller gebunden (Vendor Lock-In). Kurz: Alle Vorteile liegen auf Seiten des Herstellers, der Kunde ist im Zweifelsfall der Gearschte.
Naja, das Ding hat über 100 Register. Damit möchte ich mich gar nicht im Einzelnen beschäftigen. Die API hat schon Vorteile. Diese ca 12 Hauptcalls sind einfacher aufgerufen, als die 100 Register mit richtigen Werten in der richtigen Reihenfolge zu bedienen. Letztendlich sitzt wohl selber ein richtiger Prozessor im Sensor, der die interne Hardware steuert. Da ist eine Menge an interner Komplexität. Übrigens habe ich auch mit dem L0X gespielt. Der 1er ist aber zuverlässiger.
Falls dir das weiterhilft: Es gibt auch Sensoren-Boards mir µC der auf UART übersetzt. https://de.aliexpress.com/item/32905344953.html?spm=a2g0o.productlist.0.0.27d95789ORRZK1&algo_pvid=793ee494-bd05-4e9b-bfe8-422dfb121bc6&algo_expid=793ee494-bd05-4e9b-bfe8-422dfb121bc6-4&btsid=70a844ad-75ee-4790-bf56-e22ba1945d83&ws_ab_test=searchweb0_0,searchweb201602_2,searchweb201603_52 Die Aruino Libary hast du schon angeschaut? Benutzt die auch die hersteller Api?
Ich habe nicht gesagt, dass der Hersteller so eine Bibliothek nicht zur Verfügung stellen darf oder dass man sie nicht benutzen sollte. Sie ersetzt aber eigentlich keine Dokumentation der Hardware. Der eigentliche Grund wird das hier sein: PittyJ schrieb: > Letztendlich sitzt wohl selber ein richtiger Prozessor im Sensor, der > die interne Hardware steuert. Da ist eine Menge an interner Komplexität. Die meiste Hardware ist heutzutage auch schon Software, und der Hersteller kann jederzeit Fehler beheben, neue Funktionen hinzufügen oder allgemein das Registerverhalten komplett neu definieren. Wichtig ist nur, dass die mitgelieferte Bibliothek feststellen kann, ob sie diese Hardware(version) unterstützt oder nicht.
Im ST Newsletter wurde im Juni eine neue Ultra Light Lib angekündigt. Auch in C, aber vielleicht einfacher: https://www.st.com/content/st_com/en/products/embedded-software/proximity-sensors-software/stsw-img009.html?ecmp=tt11548_gl_enews_may2019&cid=stmDM19337&bid=227646141&uid=ZMWUaxHSyawFGqlTFbHvQSa5mUlCN7e7
Danke für die Erklärungen. Habe mir ja schon fast gedacht, dass es letztendlich mal wieder aufs Geld hinausläuft. Was auch sonst :) Werde mal schauen ob ich mit der UltraLightLib von ST einen Link zu Python hinbekomme. Klingt noch verhältnismäßig nach kleinerem Aufwand, als die alte Lib.
Weiß nicht, ob das noch relevant für dich ist, ansonsten für die Nachwelt: Der ULD Treiber ist sehr einfach zu verstehen, der lässt sich ohne Weiteres auch in andere Programmiersprachen portieren. Beim Init werden halt einige Bytes aus einem Const-Array in den Sensor kopiert und fertig. Die anderen Aufrufe schreiben oder lesen aus einzelnen Registern, da steigt man relativ schnell durch. Alle verwendeten Adressen sind sauber im Header als Define hinterlegt. Die beiden Routinen zur Kalibrierung sind nicht unbedingt notwendig, auf jeden Fall nicht für die ersten Schritte. Wenn man sich die eine Weile anschaut wird sehr schnell klar, was da gemacht wird. Über 50 Messungen wird gemittelt und der eingestellte Messwert korrigiert bzw. der Crosstalk-Wert ermittelt. Die grundsätzliche Vorgehensweise beim Messen ist als Pseudocode dargestellt, ist sehr anschaulich. Ein paar Fallstricke möchte ich noch dokumentieren: 1. Ich habe mehrere Sensoren, diese werden nacheinander geweckt und eine neue Adresse verpasst. Danach haben sie dann ihr Default-Setup bekommen. Das Problem: An Register-Adresse 1 ist die I2C-Adresse hinterlegt, beim Scheiben der Initwerte wird diese dann wieder auf Default gestellt. Lösung: Sensor erst initialisieren und erst dann die neue Adresse vergeben. Danach den nächsten Sensor wecken und parametrieren. 2. Die Defaultadresse 0x52 ist als 8-Bit Adresse inkl des R/W definiert. Eigentlich bezeichnet man ja nur die höheren 7 Bits als I2C Adresse und die ist dann 0x29. Der ganze Treiber basiert aber auf der Verwendung der 8-Bit Adresse. Kann man dann im eigenen I2C Treiber korrigieren. Interessanterweise wird im internen Register des VL53 die 7bit Adresse hinterlegt. Bei der Routine, die eine neue Adresse vergibt (simples Schreiben in Register 1) kann man schön sehen, wie das korrigiert wird. Durch diesen „Quatsch“ ist die Adresse des nächsten Sensor dann auch nicht 0x53 sondern 0x54. Irgendwie waren die Autoren da etwas inkonsequent. 3. Die meisten Hardware-Umsetzungen werden den Baustein wohl mit 2.8V betrieben und nicht mit unterschiedlichen Leveln für AVDD und IOVDD. Das geht grundsätzlich, das Datenblatt sagt aber im Kleingedruckten: „The default driver mode is 1V8. 2V8 mode is programmable using device settings loaded by the driver. For more details please refer to the VL53L1X API user manual (UM2356)“ Dazu muss man im ULD in Vl53L1X_api.c zwei Zeilen patchen: 0x00, /* 0x2e : bit 0 if I2C pulled up at 1.8V, else set bit 0 to 1 (pull up at AVDD) */ 0x00, /* 0x2f : bit 0 if GPIO pulled up at 1.8V, else set bit 0 to 1 (pull up at AVDD) */ In beiden Zeilen muss man 0x00 in 0x01 wandeln. Funktionieren wird es auch ohne, fragt sich nur wie lange und wie stabil. Im ULD ist das nicht dokumentiert, im alten großen Treiber hingegen schon (als Compiler-Switch)
:
Bearbeitet durch User
Punkt 1 habe ich ähnlich gemacht. Erst einen Chip geweckt, diesem eine neue Adresse gegeben, Basis konfiguriert, dann den nächsten ...
Und tut euch selbst einen Gefallen, indem ihr einen Logic Analyzer benutzt, da wird einem vieles klar! „Habe ich nicht“ zählt in diesem Fall übrigens nicht, die Dinger gibt es für ca. 7€ inkl. Sigrok als kostenlose SW.
2. Die Defaultadresse 0x52 ist als 8-Bit Adresse inkl des R/W definiert. Eigentlich bezeichnet man ja nur die höheren 7 Bits als I2C Adresse und die ist dann 0x29. Der ganze Treiber basiert aber auf der Verwendung der 8-Bit Adresse. Kann man dann im eigenen I2C Treiber korrigieren. Interessanterweise wird im internen Register des VL53 die 7bit Adresse hinterlegt. Bei der Routine, die eine neue Adresse vergibt (simples Schreiben in Register 1) kann man schön sehen, wie das korrigiert wird. Durch diesen „Quatsch“ ist die Adresse des nächsten Sensor dann auch nicht 0x53 sondern 0x54. Irgendwie waren die Autoren da etwas inkonsequent. 0x52 (wr) und 0x53 (rd) sind keine I2C Adressen! Wie Du richtig erkannt hast ist es die 0x29 die um ein Bit nach links geschoben wird um write(0) und read(1) to / from bus zu machen. Daher ist die nächste I2C Adresse 0x2A (0x29 + 0x01 = 0x2A), also 0010 101(0) << 1 = 0101 0100 = 0x54. Bedeutet 0x54 (wr) und 0x55 (rd) ist für die Busrichtung. Also nichts mit Quatsch oder Inkonsequenz der Autoren!
Ja, das ist eine typische I2C Fehldefinition, aber meinst Du, dass das 3 Jahre später noch relevant ist?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.