Ich stehe vor der Entscheidung Yocto oder buildroot für STM32MP1 zu verwenden. ST supported Yocto direkt. Aber die Stunden die ich mit Yocto verbracht habe waren für mich eine sehr negative Erfahrung. Irgendwie fehlte bisher der Aha-Moment. Im Internet lese ich auch öfter dass yocto nicht gerade beliebt sei. Nun bin ich mir unsicher ob ich vielleicht auf buildroot umschwenken sollte. Wer kann aus eigener Erfahrung berichten?
Zero V. schrieb: > Wer kann aus eigener Erfahrung berichten? Habe Yocto mal als Auftragsarbeit für einen Kunden gemacht. Naja, ist reichlich komplex, ich habe nicht alles davon verstanden, aber irgendwie kann man sich schon "durch wurschteln". Vorteil bei mir: die Yocto-Entscheidung war nicht meine, und der Kunde hatte uns per Stundensatz bezahlt. Die Zeit, die ich für die entsprechende Einarbeitung benötigt habe, war damit bezahlte Zeit. ;-) Habe aber keine Erfahrung mit was anderem. (War übrigens der gleiche Prozessor.)
Hi Ich würde jederzeit zu buildroot raten. Ist deutlich einfacher sich da reinzuarbeiten. Ich fange immer mit einer minimalen config an und erweitere um die benötigten Komponenten. Die komplette Konfiguration steht in einer Datei was die Versionierung erleichtert. Der Bauprozess ist auch schön schnell. Matthias
Zero V. schrieb: > ST supported Yocto direkt Yocto ist komplex aber wenn ST das im Gegensatz zu Buildroot direkt unterstützt würde ich es trotzdem nutzen. Vielleicht vorher überprüfen wie es mit den benötigten Bibliotheken aussieht. Third-Party Libs einbinden kann aufwendig werden falls es noch keine Recipes dafür gibt. Für die eigenen Teile der FW gilt, je einfacher die Buildskripte/Makefiles/… sind desto besser funktionieren die Automatiken zur Recipe-Erstellung.
Blechbieger schrieb: > Yocto ist komplex aber wenn ST das im Gegensatz zu Buildroot direkt > unterstützt würde ich es trotzdem nutzen. Ich weiß nicht wirklich ob das ein gutes Argument ist. Schau Dir das CubeMX-Zeug an und was Du da bei den Mikrocontrollern für einen Stress mit hast: - Schlechtes Konzept mit viel generiertem Code der dadurch nur schwer wartbar ist (Eigene Änderungen oft nötig, gehen dann aber bei Regenerierung wg. Parameteränderung verloren) - Schlechte Codequalität in den Bibliotheken, man darf also oft deren Code debuggen gehen - Umbenennung vieler Optionen ggü. dem RefMan, man darf also das RefMan des µC lesen und dann das vom Cube bevor man versteht was da passiert. Unnötige doppelte Arbeit. Anderes Beispiel: ich hab neulich mit einem ToF-Abstandssensor von ST gearbeitet. Keine Registerdoku, lt. ST muss man deren Bibliothek verwenden. Das ist aber ein Monster was fast 60 kB Flash braucht, eine dicke, teilweise undokumentierte Schnittstelle zur Controller-HW braucht und dann springen mir in deren Code auch gleich beim ersten Blick noch 2 Buffer-Overflow-Bugs ins Auge... Alternativ gibts für den selben Sensor von Sparkfun eine Library, Reverse-Engineered. Braucht keine 10 kB Flash und war in 5 Minuten am Laufen. Für mich sind das alles Beispiele die mir klar sagen daß ST zwar Hardware kann aber nicht Software. Von daher würde ich ein überschaubareres System wie Buildroot jederzeit einem komplexerem wie Yocto vorziehen. Denn letztendlich kannst Du auf die Unterstützung durch ST nicht bauen und musst ggf. selbst Hand anlegen.
Gerd E. schrieb: > Schau Dir das CubeMX-Zeug Ja habe ich. Es ist ein Graus. Und das Thema ToF hatte ich auch mal verfolgt, als ich den Sensor testen wollte hatte ich dann kein Bock mehr mich mit extra Software rumzuärgern. Danke für eure Meinungen. Ich schau mir buildroot mal über die Feiertage an.
Wie kommen denn die BSP Updates und Patches der einzelnen Pakete und vom Kernel in Buildroot? gibt es da support?
In buildroot konfigurierst du dir einen Kernel aus einer beliebigen Quelle. Bei NXP z.B. was von https://source.codeaurora.org/external/imx/linux-imx/tree/?h=lf-5.10.y Wobei wir unsere Kernel nicht per buildroot bauen sondern extern da wir noch ein paar lokale Patches pflegen. Matthias
Zero V. schrieb: > Ich schau mir buildroot mal über die Feiertage > an. Fazit: buildroot ist leicht verständlich und ein sehr gutes Konzept, ich bleib dabei :-) yoctoUser schrieb: > Wie kommen denn die BSP Updates und Patches der einzelnen Pakete und vom > Kernel in Buildroot? ST unterstützt beim STM32MP1 den Yocto Buildprozess mit eigenen BSP und Patches. Die Patches kopiere ich in einen globalen Patchdirectory nach buildroot und das wars.
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.