Guten Morgen, seit Linux 4.2 gibt es wohl den STM32F429-Discovery-Board support im Linux Mainline-Kernel - man kann sich daher das uralt ungepflegte ucLinux (2.6er Kernel) sparen :) Hat das schonmal jemand getestet? Ich vermute mal, Peripherie wie USB Host/Device oder das Hardware-SDKarten Interface wird nicht funktionieren? VG Mampf
:
Bearbeitet durch User
Früher habe ich auch mit so Sachen experimentiert. Heute frage ich mich aber ob man den kleinen Kerl, der dafür eigentlich nicht gemacht ist, damit quälen soll. Zumal die Einschränkungen nicht auf sich warten lassen und 'echte' Linux Boards sogar günstiger sind.
pegel schrieb: > Heute frage ich mich aber ob man den kleinen Kerl, der dafür eigentlich > nicht gemacht ist, damit quälen soll. > Zumal die Einschränkungen nicht auf sich warten lassen und 'echte' Linux > Boards sogar günstiger sind. Jaaaa, ansich hast du Recht :) Die SOCs sind aber recht bastlerunfreundlich und die Hürden für ein Custom-Board recht hoch ... Der STM32F429 kostet nur einen 10er und der ist gerade noch so an der Grenze, wo man noch gut damit arbeiten kann. Die STM32-Controller sind ziemliche Schwergewichte und die Peripherie komplex ... Wär super, wenn es da etwas geben würde, das einem die Arbeit abnimmt ... Linux drauf und funktioniert, wäre mein Wunsch gewesen :) Meine Hoffnung ist, dass ST die Peripherie nicht auch selbst von Scratch entwickelt sondern nur als IP-Core lizensiert ... Offenbar ist das beim LCD-Controller so, da gibt es ein Youtube-Video, wo auf dem Discovery-Board ein Linux mit LCD + Touch läuft ...
:
Bearbeitet durch User
Vielleicht ist eine Kombi aus beiden die Lösung. Das Linux Board für Grafik, Netzwerk, Verschlüsselung und all die feinen Linux Sachen kommuniziert über SPI oder RS232 mit einem STM32 bei dem die umfangreiche Peripherie über HAL programmiert wird. Für Bastler sicher preislich machbar und sehr flexibel. Alternativ ein RTOS für den STM32.
hah, womöglich ein kleiner Teil des STM32-Linux-Problems gelöst: https://www.spinics.net/lists/linux-mmc/msg40093.html Dort schreibt jemand: > The SD controller found in STM32 MCUs happens to be yet another variant > of the ARM PrimeCell PL18x SD host controller, for which the mmci > driver exists. und > I tested this on my STM32F469-disco board, that is able to boot from an > SD card, and write/read to/from it. Jetzt fehlt noch USB, dann bin ich zuversichtlich ;-)
Und noch die eigentlichen Patches: https://patchwork.kernel.org/project/linux-mmc/list/?submitter=72687 Man beachte das Datum ... Januar 2017! Gutes Timing, würde ich sagen xD
Beitrag #4976338 wurde vom Autor gelöscht.
Mampf F. schrieb: > Der STM32F429 kostet nur einen 10er und der ist gerade noch so an der > Grenze, wo man noch gut damit arbeiten kann. Braucht das Linux dann auch ein SDRAM? Das würde den Bastelaufwand jetzt nicht gerade kleiner machen. > Die STM32-Controller sind ziemliche Schwergewichte und die Peripherie > komplex ... Wär super, wenn es da etwas geben würde, das einem die > Arbeit abnimmt ... Linux drauf und funktioniert, wäre mein Wunsch > gewesen :) Es gibt ja den HAL und es gibt auch zu der ganzen Peripherie auch Beispiele (die dann die HAL benutzen).
Markus K. schrieb: > Braucht das Linux dann auch ein SDRAM? Das würde den Bastelaufwand jetzt > nicht gerade kleiner machen. Ja, das sicherlich. Flash ist mit 2MB gerade genug, dass man da einen Kernel + Busybox reinbekommt und dann wäre noch ca 1MB für eigene Programme übrig. Daher wäre es wünschenswert, Code von SD-Karte ausführen zu können. Oder MP3s von SDKarte lesen zu können^^ Aber das interne RAM ist viel zu wenig. Ich hab irgendwo eine Memory-Map mit laufendem Linux gesehen und 2MB RAM sind da auf jedenfall schon mal weg. Markus K. schrieb: > Es gibt ja den HAL und es gibt auch zu der ganzen Peripherie auch > Beispiele (die dann die HAL benutzen). Hmm ja ... Aber ich würde gerne das Betriebssystem von der eigentlichen Anwendung entkoppeln und die Standard-Treiber nutzen. Wieso nicht von 25 Jahren Entwicklung profitieren, falls es möglich ist?^^ Auch wenn man HAL verwendet, handelt es sich um eine spezialisierte Applikation und man darf jedesmal neu damit anfangen. Ich denke, mit einem µC in der Größenordnung, sollte man das nicht mehr müssen. Für alles andere nehme ich ja dann eh AVRs^^ *edit*: Ein Punkt auf meiner Rechercheliste ist, wie man über einen per RS232-angeschlossenen ESP8266 zum Netzwerk-Device umkonfiguriert. Der ESP versteht out-of-the-box AT-Commandos und man bräuchte wohl nur einen Modem-Treiber oder irgendwas, was Linux ja schon lange kann :) Oder alternativ einen WLAN-USB-Stick ...
:
Bearbeitet durch User
Mampf F. schrieb: > Markus K. schrieb: >> Braucht das Linux dann auch ein SDRAM? Das würde den Bastelaufwand jetzt >> nicht gerade kleiner machen. > > Ja, das sicherlich. Und dazu wahrscheinlich noch ein Display? Dann hast Du schon ganz ordentlich Pins belegt. Aber ich verstehe, jeder hat eine andere Definition von "bastelfreundlich". Mampf F. schrieb: > Markus K. schrieb: >> Es gibt ja den HAL und es gibt auch zu der ganzen Peripherie auch >> Beispiele (die dann die HAL benutzen). > > Hmm ja ... Aber ich würde gerne das Betriebssystem von der eigentlichen > Anwendung entkoppeln und die Standard-Treiber nutzen. Wieso nicht von 25 > Jahren Entwicklung profitieren, falls es möglich ist?^^ Wenn ich mir die Linuxprojekte bei der Arbeit so ansehe, dann sehe ich, dass die alle auch eigene Treiber geschrieben haben. Linuxtreiber, was vermutlich deutlich aufwändiger ist als bei irgendeinem kleinen RTOS. > Auch wenn man HAL verwendet, handelt es sich um eine spezialisierte > Applikation und man darf jedesmal neu damit anfangen. Ob der Linuxkernel Deine API ist oder der ST-HAL ist doch nur von Bedeutung, wenn Du öfters mal den Controller wechselst. > Ich denke, mit einem µC in der Größenordnung, sollte man das nicht mehr > müssen. Je nachdem was Du damit machst ist der nicht so übermäßig groß und bei einem Linux kannst Du dann vieles auch nicht optimieren (jedenfalls nicht ohne die Treiber zu ändern, was Du ja gerade nicht willst).
Markus K. schrieb: > Und dazu wahrscheinlich noch ein Display? Nein, Display brauch ich keins :) Die Kunst ist ja auch immer zu wissen, welche Plattform man für welches Projekt einsetzt ... Bin da nicht festgefahren und wenn es mir sinniger erscheint, einen Raspi mit Display zu verwenden mache ich das. Oder einen AVR für klitzekleine Sachen. Oder einen FPGA für hoch-parallele DSP-Algorithmen mit harten Echtzeitanforderungen. Oder einen PC für - hmm - PC-Sachen :) Markus K. schrieb: > Wenn ich mir die Linuxprojekte bei der Arbeit so ansehe, dann sehe ich, > dass die alle auch eigene Treiber geschrieben haben. Linuxtreiber, was > vermutlich deutlich aufwändiger ist als bei irgendeinem kleinen RTOS. Das glaub ich dir gerne! Bislang dachte ich, der STM32 wäre Standard und keine exotische Plattform, für die das noch notwendig wäre. Aber evtl irre ich mich da ... Markus K. schrieb: > Ob der Linuxkernel Deine API ist oder der ST-HAL ist doch nur von > Bedeutung, wenn Du öfters mal den Controller wechselst. Naja, ich denke, ob Linux Embedded Sinn macht oder nicht, müssen wir nicht mehr diskutieren ... Da haben sich sicher schon viele Leute damit auseinander gesetzt und die Antwort ist vermutlich: It depends ...^^ Markus K. schrieb: > Je nachdem was Du damit machst ist der nicht so übermäßig groß und bei > einem Linux kannst Du dann vieles auch nicht optimieren (jedenfalls > nicht ohne die Treiber zu ändern, was Du ja gerade nicht willst). Kann gut sein, dass ich es zum Laufen bekomme und dann feststelle, dass es mir nicht taugt :) Ich denke, die 1-5 Tage Arbeit, das zu testen, sind es wert. Wenn Linux drauf läuft und die Peripherie unterstützt, die ich wollte, mir aber das ganze nicht performant genug ist, wird es unter Erfahrung verbucht und wandert in die "Toolbox" für Anwendungen, wo das dann wieder passend ist. *edit*: Hmm, vlt sollte ich auch mal nach einer Alternative für die STM32 schauen, die noch bastlerfreundlich sind und die explizit von Linux vollumfänglich unterstützt werden ...
:
Bearbeitet durch User
Markus K. schrieb: > Braucht das Linux dann auch ein SDRAM? Das würde den Bastelaufwand jetzt > nicht gerade kleiner machen. "Brauchen" ist wohl der falsche Ausdruck. Ja, wenn man sowas Dickes wie ein von der MDT herkommendes OS auf nen µC draufpresst, dann kann man jede Menge RAM dringendst gebrauchen. Ebenso braucht man ne Menge RAM, wenn man ein Display anschließt (ich meine ein richtiges Display). Ich habe so das Gefühl bei derartigen Aktionen, als wenn jemand einen Amischlitten aus den 60ern in seinen Keller pfercht, wo er zwar stehen und bewundert werden kann, aber mangels Platz lediglich 50 cm vor und zurück fahren kann. Meine Idee wäre schlichtweg, sich eine Art Miniatur-OS selber einfallen zu lassen, was dann bequem in 64K oder 128K hineinpaßt, kein aufgeblasenes Multitasking hat (ne MMU gibt es ja nur bei ARM9 oder eben dickeren Cortex-A) und Anwendungen von SD in den RAM laden und ausführen kann. Das sollte für die Dinge, die man mit einem Cortex-M so machen kann, wohl ausreichen. W.S.
Mampf F. schrieb: > Markus K. schrieb: >> Wenn ich mir die Linuxprojekte bei der Arbeit so ansehe, dann sehe ich, >> dass die alle auch eigene Treiber geschrieben haben. Linuxtreiber, was >> vermutlich deutlich aufwändiger ist als bei irgendeinem kleinen RTOS. > > Das glaub ich dir gerne! Bislang dachte ich, der STM32 wäre Standard und > keine exotische Plattform, für die das noch notwendig wäre. > > Aber evtl irre ich mich da ... Meine Beispiele bezogen sich nicht auf Linux auf dem STM32, sondern auf andere Platformen, für die es durchaus vom Hersteller eine Linuxdistribution gibt. Aber das ändert ja nix daran, dass es nötig sein kann Treiber zu schreiben.
W.S. schrieb: > Meine Idee wäre schlichtweg, sich eine Art Miniatur-OS selber einfallen > zu lassen, was dann bequem in 64K oder 128K hineinpaßt, kein > aufgeblasenes Multitasking hat (ne MMU gibt es ja nur bei ARM9 oder eben > dickeren Cortex-A) und Anwendungen von SD in den RAM laden und ausführen > kann. Bin mir nicht sicher, aber kann das U-Boot nicht alleine schon? :)
W.S. schrieb: > Meine Idee wäre schlichtweg, sich eine Art Miniatur-OS selber einfallen > zu lassen, was dann bequem in 64K oder 128K hineinpaßt, kein > aufgeblasenes Multitasking hat (ne MMU gibt es ja nur bei ARM9 oder eben > dickeren Cortex-A) und Anwendungen von SD in den RAM laden und ausführen > kann. Das sollte für die Dinge, die man mit einem Cortex-M so machen > kann, wohl ausreichen. Schau Dir mal NuttX an. Ist POSIX-kompatibel und hat eigentlich alles, was man so benötigt. Lässt sich sehr gut auf fast jede Speichergröße hin optimieren. Das läuft übrigens auch schon auf AVR. Wir setzen das für unsere STM32-Projekte standardmäßig ein und sind sehr zufrieden (läuft unter BSD-Lizenz): http://www.nuttx.org
Mampf F. schrieb: > Die SOCs sind aber recht bastlerunfreundlich und die Hürden für ein > Custom-Board recht hoch ... Wenn "Custom-Board", dann nehme ich das raspberry-Computer-Modul Braucht nur einen passenden Steckplatz auf der Platine und alle wirklich kritischen Teile sind schon draufgelötet. 5V anschließen, Software drauf, läuft. Zusatzhardware nach Bedarf.
Chris D. schrieb: > Schau Dir mal NuttX an. Ach nööö... nicht nochmal. Das hatte ich mir vor einigen Jahren mal angeschaut und fand, daß es allenfalls als RT-Scheduler-Kernel durchgehen kann. Ist also meilenweit von jeglicher Art echtem OS entfernt. Da wäre die Bettybase aus der Lernbetty ja fast noch ein richtiges OS dagegen.. ;-) Aufgeblasen kann ja jeder, aber wirklich funktionell eben nicht. Es gibt ne ganze Menge von Tralala-OS-Erfindern, wo man nur den Kopf schütteln kann, z.B. ECOS und so. Wenn man genau hinguckt, ist das alles herzlich realitätsfern, genauso wie eben ein Linux auf einen viel zu kleinen µC draufquetschen zu wollen. Zumeist sind das mäßige bis schlechte Versuche, einen Scheduler mit preemptiver Taskverwaltung hinzubekommen, mehr nicht. Kurzum, ICH brauche sowas nicht und ich finde den Versuch, sowas wie ein Linux auf nen MMU-freien µC draufzupfropfen, herzlich vergeblich. Kann ja funktionieren, aber eben nur wie der Cadillac im Keller. W.S.
W.S. schrieb: > Chris D. schrieb: >> Schau Dir mal NuttX an. > > Ach nööö... nicht nochmal. > > Das hatte ich mir vor einigen Jahren mal angeschaut Selbst Schuld - da hat sich nämlich einiges getan.
Chris D. schrieb: > Selbst Schuld - da hat sich nämlich einiges getan. Nee, hab eben grad mal nachgeschaut: "The goal is to provide implementations of most standard POSIX OS interfaces to support a rich, multi-threaded development environment for deeply embedded processors. NON-GOALS: It is not a goal to provide the level of OS features like those provided by Linux. In order to work with smaller MCUs, small footprint must be more important than an extensive feature set." Danke, keine weiteren Fragen, Kienzle. Es ist eben doch nicht im geringsten über den damaligen Ansatz hinausgekommen. Hab mir grad mal den Ordner "arch" angesehen. 51 MB im Umfang, rund 30 verschiedene Architekturen angeblich enthalten, aber wenn man sich mal auf die Suche nach dem eigentlichen Fleisch macht, sieht man lediglich, daß das ganze echt JÄMMELICH aussieht. Mal ein Beispiel für den seriellen Datenverkehr:
1 | while ((getreg32(CONSOLE_BASE+A1X_UART_LSR_OFFSET) & UART_LSR_THRE) == 0); |
2 | /* Send the character */
|
3 | putreg32((uint32_t)ch, CONSOLE_BASE+A1X_UART_THR_OFFSET); |
Klaro, gelle? Kein echter Treiber, nur Polling-Wichs. Danke, nicht mit mir. Aber ein Sack voll großlaberiger Kommentare a la " * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS " und so weiter. Nee, danke. Die Leute sind Schaumschläger und das Produkt ist dezent gesagt "mäßig". Ich kenne dafür auch noch aussagekräftigere Ausdrücke. W.S.
Schreiber schrieb: > Wenn "Custom-Board", dann nehme ich das raspberry-Computer-Modul Oh das ist in der Tat sehr interessant ... Muss ich mal drüber nachdenken ... Die Wiederverwendbarkeit wär halt ein super Feature :)
NIk schrieb: > Was hälst du von Zephyr: Na das, was die selber schreiben: Zitat: "Extensive suite of services. Offers a number of familiar services for development: Multi-threading Services for priority-based, non-preemptive and preemptive threads with optional round robin time-slicing. Interrupt Services for compile-time registration of interrupt handlers. Memory Allocation Services for dynamic allocation and freeing of fixed-size or variable-size memory blocks. Inter-thread Synchronization Services for binary semaphores, counting semaphores, and mutex semaphores. Inter-thread Data Passing Services for basic message queues, enhanced message queues, and byte streams. Power Management Services such as tickless idle and an advanced idling infrastructure." Eben noch ein RT-Scheduler, sonst nix. Kein API, kein I/O, kein Apploader, keine Shell, kein Filesystem, keine Treiberschicht, keine Grafik, .. ach was. W.S.
W.S. schrieb: > Klaro, gelle? Kein echter Treiber, nur Polling-Wichs. Danke, nicht mit > mir. Naja, es gibt vielleicht elegantere Möglichkeiten aber immerhin funktioniert es. Der von dir herauskopierte Quelltext müsste für einen Allwinner A10 bzw. A13 sein. Alleine, das Nuttx überhaupt auf Systemen von AVR bis Cortex-A läuft und es eine grundlegende Hardwareabstraktion gibt finde ich schon beachtlich. Andere Treiber sind auch durchaus mehr auf Geschwindigkeit ausgelegt, z.B. nutzt der SPI-Treiber für den STM32 standardmäßig DMA. W.S. schrieb: > Aber ein Sack voll großlaberiger Kommentare a la > " * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > " > und so weiter. Der Mann ist Amerikaner. Dafür kann er nichts. W.S. schrieb: > Nee, danke. Die Leute sind Schaumschläger und das Produkt ist dezent > gesagt "mäßig". Ich kenne dafür auch noch aussagekräftigere Ausdrücke. Also wenn man Nuttx auf seine Hardwaretreiber reduziert, dann ist es mit Sicherheit nur mäßig aber man bekommt eben deutlich mehr geboten, z.B. verschiedene Dateisysteme oder einen IP-Stack und alles ist sehr modular, obwohl die einzelnen Module wiederum perfekt zusammenarbeiten. Im übrigen sehe ich in Nuttx auf keinen Fall das Allheilmittel für jegliche Problemstellung und das sieht der Hauptautor hinter Nuttx ebenfalls so. Hier mal ein Zitat von ihm von vor vier Jahren: > I created NuttX just because I wanted to. I have written embedded RTOSs > for many years and just wanted the freedom to write the one I wanted. > So I do this for fun not money or popularity. So it does not target any > demographic that would support popularity. In fact, I think NuttX is best > suited only for a smaller niche audience: Somewhere between the tiny OSs > like FreeRTOS and ChibiOS and the big OSs like Linux. Among the middle- > size RTOSs, it is still smaller than RTEMS, VxWorks, and Integrity; > probably larger than RT-Thread; perhaps an open source alternative to uC/OS. > NuttX is too complex for the typical one-electronic-engineer projects > and probably too small for higher end software developments. Nachzulesen hier: http://nuttx.yahoogroups.narkive.com/qHO9Ew3K/need-infos-on-nuttx#post22 Schaumschlägerei klingt für mich anders.
Christopher J. schrieb: > Naja, es gibt vielleicht elegantere Möglichkeiten aber immerhin > funktioniert es. Jaja.. per Polling. Selbst bei einem kleinen OS will man ne ordentliche I/O-Verwaltung haben, die die Ströme zwischenpuffert, eben damit man dies nicht selber zu tun braucht, damit man seinen eigenen Nutz-Kram nicht blockiert. Also, anstatt ordentliche Lowlevel-Treiber mit unifizierter Oberfläche zu schreiben, versucht der Autor, die darunter liegende HW zu "verunifizieren" mit sowas: "getreg32(...)" - und dann fehlt ihm die Puste, um einen wirklich benutzbaren HW-Treiber zu schreiben. Aber die Klappe aufreißen wie das Krokodil. Nee, in diesen Dingen ist die olle Lernbetty dem Nuttx sogar noch voraus - und das will was heißen. Ich sehe da genau die Denke, die auch in der ST-Lib steckt: keine wirkliche HAL, sondern nur ein Einschmieren der HW mit Soße. Was bleibt? Ein schlichter Scheduler, wie es ihn schon dutzendfach woanders gibt. Allerdings mit dem Anspruch, den du zitiert hast: zu kompliziert gemacht, um damit ein Einmann-Projekt zu verbessern und zu klein, um für ein Mehrmann-Projekt zu taugen - eben nur aus Lust am Schreiben geschrieben. Ich denke mal, das reicht jetzt. W.S.
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.