mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Linux auf dem STM32 externes RAM


Autor: micha (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hey,

ich wollte mir ein Linux für STM32F446 Development Board bauen.
Dazu gibts es für Buildroot schon zwei Portierungen für das 
stm32f429_disco_defconfig und das stm32f469_disco_defconfig.

Die beiden Boards haben jeweis ein externes SDRAM das auch von 
bootloader konfiguriert wird 
(https://github.com/mcoquelin-stm32/afboot-stm32). Mein STM32F446 hat 
aber leider kein SDRAM.

Benötige ich zwingend ein externes SDRAM um Linux zum laufen zu 
bekommen? oder was muss ich umkonfigurieren damit es nur mit dem 
internen SRAM geht?

Viele Grüße
Micha

Autor: eher nicht (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
micha schrieb:
> Benötige ich zwingend ein externes SDRAM um Linux zum laufen zu
> bekommen? oder was muss ich umkonfigurieren damit es nur mit dem
> internen SRAM geht?

Linux mit 128kB RAM?
Kaum.
Linux mit der Lahmarschigen Gurke STM32F4?
Noch weniger.

Ganz Allgemein würde ich dir ans Herz legen, einen echten Prozessor zu 
verwenden, nicht ein Spielzeug wie den STM32F4.

Willst du damit etwas anfangen, wist du mindestens bei SAMA5 oder i.MX6 
UL einsteigen müssen. Darunter ist es im Höchstfall proof of concept, 
aber nichs brauchbares.
Selbst mit einem 500MHz SAMA5 würde ich mir kein brauchbares 
Desktop-System erwarten.
Denn das ist noch unter einem Raspberry-PI angesiedelt. Weit darunter.

Autor: Jim M. (turboj)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
micha schrieb:
> Benötige ich zwingend ein externes SDRAM um Linux zum laufen zu
> bekommen?

Ja. Linux kommt mit dem internen RAM nicht zurecht - das ist deutlich zu 
klein.


Welches Problem willst Du mit Linux lösen? Auf diesen MCUs nutzt man 
normalerweise Betriebssysteme mit kleinerem Footprint.

Autor: M. H. (bambel2)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Jim M. schrieb:
> Welches Problem willst Du mit Linux lösen? Auf diesen MCUs nutzt man
> normalerweise Betriebssysteme mit kleinerem Footprint.

Durchaus. Aber ich denke er will kein Problem lösen, sondern nur 
spielen.

Ein Linux bekommst du mit sehr viel Mühe auf 3 bis 4 MB RAM runter. 
Weniger geht nicht. Oder zumindest nicht, ohne massive Codeänderungen.

Aber außer als witziges Projekt sehe ich Linux auf STM32F4 nicht als 
sinnvoll an. Zumal der STM32 keine MMU hat und dardurch das 
Speichermanagement schon sehr viel overhead hat.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. H. schrieb:
> Zumal der STM32 keine MMU hat und dardurch das
> Speichermanagement schon sehr viel overhead hat.

Wird der Overhead nicht eher geringer, weil das Umschalten (inkl. TLB 
leeren, ggf. Cache leeren bei VIVT/VIPT-Cache) beim Kontextwechsel 
entfällt? Da dann alle Anwendungen im selben Adressraum laufen, hat man 
halt keine Trennung und die damit einhergehende Sicherheit und 
Stabilität mehr.

Die Frage ist natürlich, was eigentlich erreicht werden soll.

Autor: LinuyStm32Bordsupport (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: LinuyStm32Bordsupport (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: M. H. (bambel2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Wird der Overhead nicht eher geringer, weil das Umschalten (inkl. TLB
> leeren, ggf. Cache leeren bei VIVT/VIPT-Cache) beim Kontextwechsel
> entfällt?

Das Problem daran ist, dass der Kontextwechsel nicht entfällt. Alle 
Programme sind immernoch auf den selben virtuellen Adressraum gelinkt. 
Nur hat das eben das Problem, dass es keinen virtuellen Adressraum gibt, 
im näheren Sinne. Das Linux hat ohne MMU mehr Aufwand den 
Speicherbereich zu organisieren.

Hier gibt es eine Übersicht über die speichertechnischen 
Funktionalitäten:
https://www.kernel.org/doc/Documentation/nommu-mmap.txt

: Bearbeitet durch User
Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso,

M. H. schrieb:
> Das Problem daran ist, dass der Kontextwechsel nicht entfällt. Alle
> Programme sind immernoch auf den selben virtuellen Adressraum gelinkt.

Ich habe es so verstanden, dass die Programme einfach an 
unterschiedliche Adressen gepackt werden. Der Code muss dafür 
Position-Independant sein.

Autor: Micha (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
M. H. schrieb:
> Jim M. schrieb:
>> Welches Problem willst Du mit Linux lösen? Auf diesen MCUs nutzt man
>> normalerweise Betriebssysteme mit kleinerem Footprint.
>
>

Nun, man sagt ja immer das man Linux verwenden muss, da es alle Probleme 
lösen kann. Jetzt muss ich lesen dass Linux doch Dreck ist und man den 
Stm32 nativ angehen muss...

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:
> Nun, man sagt ja immer das man Linux verwenden muss, da es alle Probleme
> lösen kann.

Man kann es auch so sehen: Wenn man Linux verwendet, kann man auch 
dessen Fähigkeit zur Ansteuerung komplexer Prozessoren nutzen und es auf 
einem Cortex-A mit genug externem RAM laufen lassen. Dadurch erledigen 
sich die diversen Probleme mit uClinux. Wirklich teurer wird es dadurch 
nicht.

Autor: eher nicht (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Micha schrieb:
> Nun, man sagt ja immer das man Linux verwenden muss, da es alle Probleme
> lösen kann. Jetzt muss ich lesen dass Linux doch Dreck ist und man den
> Stm32 nativ angehen muss...

Natürlich sollst du den STM32 nativ angehen. Der STM32 wurde genau dazu 
entwickelt, um ihn nativ anzugehen. Schließlich ist er ein ja ein 
Microcontroller. Das steckt schon im Namen.

Wer das nicht will, nimmt halt ein vollerwertiges System mit SAMA5. Also 
mit einem echten Prozessor.

Beides hat seine Daseinsberechtigung. Die Einsatzbereiche sind völlig 
unterschiedlich, nichts davon ist die "einzig seelig machende Wahrheit".

Wer harte Echtzeit will, wird sich mit Linux hart tun, hat aber mit dem 
STM32 leichte Spiel.
Wer Netzwerk und Datenbank macht, hat mit dem STM32 viel Code am Hal, 
aber mit Linux ist das ziemlich einfach.

Was willst du denn jetzt genau tun?

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:
> Nun, man sagt ja immer das man Linux verwenden muss, da es alle Probleme
> lösen kann.

Wer ist "man"? Irgendwelche Vollspacken, die auf der YouTube-Universität 
ihren Unsinn verbreiten? Oder Du selbst?

> Jetzt muss ich lesen dass Linux doch Dreck ist und man den
> Stm32 nativ angehen muss...

Linux ist keineswegs Dreck, aber eben nicht für beliebige Einsatzzwecke 
geeignet.

Autor: micha (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ja es ist mir bewusst das der STM32 kein Raspi oder Atom ist aber er lag 
nun mal im Schrank rum. Mein Ziel ist es also es einfach mal zu 
versuchen.

ich bin jetzt so weit das ich eine der buildroot configs angepasst habe.
Dann erhalte ich einen bootloader (stm32f446.c) einen devicetree und ein 
xipImage.

Der Bootloader wird an Addresse 0x08000000 kopiert
Das xipImage Image an Adresse 0x08008000
#0  0x08000346 in start_kernel () at stm32f446.c:89
#1  0x0800045e in main () at stm32f446.c:191
(gdb) stepi
0x08000348  89    kernel(0, ~0UL, 0x08004000);
(gdb) where
#0  0x08000348 in start_kernel () at stm32f446.c:89
#1  0x0800045e in main () at stm32f446.c:191
(gdb) stepi
0x08008000 in ?? ()
(gdb) where
#0  0x08008000 in ?? ()
#1  0x0800034a in start_kernel () at stm32f446.c:89
#2  0x0800045e in main () at stm32f446.c:191
(gdb) where
#0  0x08008000 in ?? ()
#1  0x0800034a in start_kernel () at stm32f446.c:89
#2  0x0800045e in main () at stm32f446.c:191
(gdb) stepi
0x08008004 in ?? ()
(gdb) where
#0  0x08008004 in ?? ()
#1  0x0800034a in start_kernel () at stm32f446.c:89
#2  0x0800045e in main () at stm32f446.c:191
(gdb) stepi
0x08008008 in ?? ()
(gdb) where
#0  0x08008008 in ?? ()
#1  0x0800034a in start_kernel () at stm32f446.c:89
#2  0x0800045e in main () at stm32f446.c:191
(gdb) stepi
0x08009230 in ?? ()
(gdb) where
#0  0x08009230 in ?? ()
#1  0x0800800c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) stepi
0x08009232 in ?? ()
(gdb) Quit

Er scheint also Tatsächlich noch in den Kernel zu springen. Aber danach 
kommt ein HardFault Interrupt.

Die Ausgabe auf der Seriellen Schnittstelle ist:
stm32-bootH

Autor: Micha (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Linux ist keineswegs Dreck, aber eben nicht für beliebige Einsatzzwecke
> geeignet.

Beliebig verwendbar ist Windows doch auch nicht, aber jedet linuxer 
verspottet es

Autor: PittyJ (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Fang doch erst einmal mit einer Turing-Maschine an.
Das ist ein überschaubares Projekt.
Und man kann alles damit berechnen.

Autor: Markus F. (mfro)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Micha schrieb:
> aber jedet linuxer
> verspottet es

das arme Windows. Unterschätzt und verkannt.

Autor: eher nicht (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
micha schrieb:
> Ja es ist mir bewusst das der STM32 kein Raspi oder Atom ist aber
> er lag
> nun mal im Schrank rum. Mein Ziel ist es also es einfach mal zu
> versuchen.

Nochmal: Ohne externen RAM läuft das nicht.

Im Normalfall wird man unter 32 oder 64MByte nie anfangen. Aber einige 
Leute sollen es schon mit einstelligen MByte geschafft haben.

Beispiel:
https://electronics.stackexchange.com/questions/240227/minimum-requirements-of-a-microcontroller-to-run-embedded-linux
Da erzählt jemand, er hätte einen Minimal-Kernel mit 8MByte 
hochgebracht. Aber ohne Features.

Mit 0,125MBytes (128kB) wird das niemals klappen...

Also:
Ein (ziemlich wenig praxistaugliches) Proof of concept ist mit dem STM32 
möglich, aber nur mit externem RAM. Ohne gehts nicht.

Autor: Micha (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Markus F. schrieb:
> Micha schrieb:
> aber jedet linuxer
> verspottet es
>
> das arme Windows. Unterschätzt und verkannt.

Da ist schon einer :)

Autor: Cornelius (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Mich würde mal interessieren, ob man auf dem F7Disco den GCC 
installieren und compilieren könnte:

https://github.com/fdu/STM32F746G-disco_Buildroot

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eher nicht schrieb:
> Ein (ziemlich wenig praxistaugliches) Proof of concept ist mit dem STM32
> möglich, aber nur mit externem RAM. Ohne gehts nicht.

Man könnte ja mal einen Blick auf RetroBSD werfen. Das ist zwar nur ein 
2.11BSD statt Linux, aber sollte mit 128 KB RAM inklusive Userspace 
zufrieden sein.

Zielt im Augenblick aber auf die PIC32, nicht auf STM32... aber machbar 
sollte es sein.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was will man mit einem Linux ohne Netzwerk und das mangels Speicher 
höchstens ein Anwendungsprogramm ausführen kann? Da bliebt doch vom 
Betriebssystem nicht Sinnvolles mehr übrig.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Micha schrieb:
> Beliebig verwendbar ist Windows doch auch nicht, aber jedet linuxer
> verspottet es

Nö. Jedes dieser Betriebssysteme hat Einsatzgebiete, auf denen es 
vorteilhaft.

Pauschaler Spott eines "Lagers" beweist nur, dass es bei den jeweiligen 
Aktivisten nur um picklige Hinterwäldler handelt, die nicht über ihren 
Tellerrand hinausschauen können. Dies betrifft sowohl das Linux-Lager, 
Windows-Lager als auch beliebige andere Gebiete, in denen sich solche 
Aktivisten als besonders progressiv aufspielen können. Und wie so häufig 
bleibt an dieser Stelle auch nicht der obligatorische Hinweis erspart:

https://de.wikipedia.org/wiki/Best%C3%A4tigungsfehler

Autor: Cornelius (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
>Was will man mit einem Linux ohne Netzwerk und das mangels Speicher
>höchstens ein Anwendungsprogramm ausführen kann?
https://github.com/fdu/STM32F746G-disco_Buildroot
Das F7 hat einen Lan-Anschluss.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Cornelius schrieb:
>>Was will man mit einem Linux ohne Netzwerk und das mangels
> Speicher
>>höchstens ein Anwendungsprogramm ausführen kann?
> https://github.com/fdu/STM32F746G-disco_Buildroot
> Das F7 hat einen Lan-Anschluss.

Ich meinte das Linux, dass er in 128kB RAM quetschen wollte. Da ist für 
den Netzwerk-Treiber und IP Stack kein Platz.

Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Was will man mit einem Linux ohne Netzwerk und das mangels Speicher
> höchstens ein Anwendungsprogramm ausführen kann? Da bliebt doch vom
> Betriebssystem nicht Sinnvolles mehr übrig.

Man kann an einem STM32 problemlos einen Netzwerkchip betreiben, z.B. 
den ENC28J60 (wird von Linux unterstützt). SLIP oder PPP über eine 
serielle Schnittstelle geht auch problemlos.

Vor einigen Jahren hatte ich ein 486er Notebook mit 4 MB RAM und 
CF-Karte in ein X-Terminal (mit ein paar lokalen Anwendungen) 
verwandelt. OpenWrt unterstützt viele Router, die auch nicht viel mehr 
RAM haben. Die D-Box2 mit ihrem 66 MHz-PPC und grad mal 32 MB RAM war 
auch erstaunlich leistungsfähig.

Als Lernübung für eingebettete Systeme ist das nicht verkehrt. Es wird 
ziemlich sicher kein Desktop-System mit Ubuntu und Gnome, aber das ist 
meine alte Fritzbox auch nicht.

Und die Vorteile von Linux (existierende Treiber, gehärteter 
Netzwerkstack, fertige Infrastruktur von Compiler über Shell und 
Scriptsprachen bis Webserver) bleiben auch auf einem STM32 erhalten.

Die Idee grundsätzlich pauschal als Unfug abzutun greift aus meiner 
Sicht schlicht zu weit.

Stefanus F. schrieb:
> Ich meinte das Linux, dass er in 128kB RAM quetschen wollte. Da ist für
> den Netzwerk-Treiber und IP Stack kein Platz.

RetroBSD könnte das vielleicht. Falls nicht, wäre das eine gute Übung. 
:-)

: Bearbeitet durch User
Autor: eher nicht (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Die Idee grundsätzlich pauschal als Unfug abzutun greift aus meiner
> Sicht schlicht zu weit.

Doch, das ist Unfug. Und ztwar ziemlich dämlicher Unfug.

Ohne externes RAM geht es nicht mit Linux. Ausgeschlossen - 128kB 
reichen nicht für Linux.

Und mit externem RAM kann ein Microcontroller wie der STM32 seine 
Vorteile nicht mehr ausspielen. Und der Vorteil eines STM32 ist doch 
genau der, dass er als Chip an sich ein Stand-alone-System darstellt, 
mit integrierter Peripheri und so weiter. Den wirft man weg, wenn man 
ein RAM dranmacht, und das Teil Prozessor spielen lässt.
Dann bleibt der (für Prozessoren(!!!)) schwache Cortex-M4 übrig, der 
nicht für richtige Betriebssysteme entwickelt wurde. Es ist ein 
Microcontrollerkern.

Prozessor spielen können richtige Prozessoren naturgemäß besser, und so 
kostet der oben genannte SAMA5 mit 500MHz und passenden Prozessorkern 
sogar weniger als ein STM32F4.

Dazu kommen weitere Dinge, wie dass es für die viele wunderschöne 
STM32-Peripherie vermutlich keine fertigen Linux-Treiber geben wird, und 
die Linux-Unterstützung für den Cortex-A5 natürlich besser ausfällt.

Ein Microcontroller ist keine CPU. Linux ist ein Betriebessystem für 
richtige Computer, nicht für Microcontroller.

Nur um es zu wiederholen: Ein STM32F4 ist teurer als ein SAMA5 mit 
500MHz, dieser hat aber die dreifache Rechenleistung.
Warum das wohl so ist, hmm?
Man vergleiche die Datenblätter...

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:
> M. H. schrieb:
>> Jim M. schrieb:
>>> Welches Problem willst Du mit Linux lösen? Auf diesen MCUs nutzt man
>>> normalerweise Betriebssysteme mit kleinerem Footprint.
>>
>>
>
> Nun, man sagt ja immer das man Linux verwenden muss, da es alle Probleme
> lösen kann. Jetzt muss ich lesen dass Linux doch Dreck ist und man den
> Stm32 nativ angehen muss...

Offensichtlich hast du die eigentliche Frage übersehen, also nochmal:

>>> Welches Problem willst du mit Linux lösen?

Autor: Grobi G (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...auch mal was in den Raum werf... ist eine MMU nicht eine 
Grundvorrausetzung für ein Linux OS ? Also sprich keine MMU = kein Linux 
?
Es gab doch mal sowas wie FreeRTOS oder so für die stm32s wenn ich mich 
nicht irre, das sollte doch fürs Erste reichen. Irgendwo hab ich auch 
noch son altes f4diso boad rumfliegen und das war damals schon nur ein 
etwas schnellerer mit mehr internem RAM ausgerüsteter mikrocontroller 
und keine ich nenns mal klassische CPU.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grobi G schrieb:
> ...auch mal was in den Raum werf...
> ist eine MMU nicht eine Grundvorrausetzung für ein Linux OS ?
> Also sprich keine MMU = kein Linux ?

Im Prinzip schon, aber uClinux hat vor gut 15 Jahren den Linux-Kernel 
auf NOMMU-Architekturen portiert (z.B. den Palm Pilot mit m68k). 
Inzwischen ist die Unterstützung im normalen Kernel angekommen und wird 
auch benutzt.

Natürlich gibt es ohne MMU ein paar herbe Einschränkungen, z.B. gibt es 
keine Unterstützung für fork(), stattdessen muss man mit vfork() leben. 
ELF musste ein bisschen erweitert werden (fdPIC[*]), shared libraries 
sind nicht ganz so einfach uswusf.

[*] Der fdPIC-Loader wird den ELF-Loader wohl mittelfristig ersetzen; 
jedes ELF-Binary ist auch ein gültiges fdPIC-Binary.

Davon abgesehen ist das ein ganz normales Linux und viele Programme 
laufen ganz normal. Die üblichen Embedded-Anwendungen (z.B. Busybox) 
laufen sowieso.

eher nicht schrieb:
>> Die Idee grundsätzlich pauschal als Unfug abzutun greift aus meiner
>> Sicht schlicht zu weit.
> Ohne externes RAM geht es nicht mit Linux. Ausgeschlossen - 128kB
> reichen nicht für Linux.

Einverstanden. Trotzdem ist "Linux auf STM32" oder allgemeiner "Linux 
mit NOMMU" kein allzu großer Unfug. Es ist eine Frage des 
Anwendungsfalls.

Zudem ist der STM32 relativ weit verbreitet und daher eine gute Basis, 
um die Unterstützung für kleinere Architekturen (mit und ohne MMU) zu 
fördern.  Gibt zum Beispiel den jCore, der auf SH2 aufsetzt.

Ein kleinerer Kernel ist nicht nur für "wenig RAM"-Szenarien nützlich, 
sondern lässt auf dickeren CPUs auch mehr Cache für die Anwendungen 
übrig.

eher nicht schrieb:
> Und mit externem RAM kann ein Microcontroller wie der STM32 seine
> Vorteile nicht mehr ausspielen.

Warum nicht? Die meisten netten Features (Netzwerkstack, 
Hardwaretreiber, existierende Software) bekommt man trotzdem. Die 
Entwicklung kann ohne Emulation nativ auf dem PC erfolgen.

eher nicht schrieb:
> Dazu kommen weitere Dinge, wie dass es für die viele wunderschöne
> STM32-Peripherie vermutlich keine fertigen Linux-Treiber geben wird, und
> die Linux-Unterstützung für den Cortex-A5 natürlich besser ausfällt.

Ein Board mit STM32 und bisschen externem RAM lässt sich sicherlich 
einfacher entwerfen als eines mit Cortex-A5. Außerdem lässt sich dank 
der vielen Schnittstellen vieles relativ einfach anflanschen, zumal der 
STM32 als Controller elektrisch gutmütiger ist als eine richtige CPU. 
Das fängt schon mit den Versorgungsspannungen und Taktgebern an. :-)

Im menuconfig habe ich übrigens ziemlich viele STM32-Treiber gesehen. 
Keine Ahnung, ob damit sämtliche Peripherie abgedeckt ist, aber ein 
Großteil ziemlich sicher.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
S. R. schrieb:
> Man kann an einem STM32 problemlos einen Netzwerkchip betreiben, z.B.
> den ENC28J60 (wird von Linux unterstützt).

Das mag ja sein, aber in 128kB RAM (um die es hier geht) kriegst du nie 
und nimmer einen Linux Kern mit den Netzwerktreibern rein, die für 
TCP/IP notwendig sind.

Das kannst du nicht mit µIP vergleichen. µIP ist kleiner, hat aber 
nichts mit Linux zu tun.

: Bearbeitet durch User
Autor: eher nicht (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
S. R. schrieb:
> eher nicht schrieb:
>> Und mit externem RAM kann ein Microcontroller wie der STM32 seine
>> Vorteile nicht mehr ausspielen.
>
> Warum nicht? Die meisten netten Features (Netzwerkstack,
> Hardwaretreiber, existierende Software) bekommt man trotzdem. Die
> Entwicklung kann ohne Emulation nativ auf dem PC erfolgen.

Dann führen wir das doch mal aus:
Der STM32F4 ist teurer als ein richtiger Prozessor wie der SAMA5. Es 
gibt sogar noch billigere Prozessoren als den SAMA5.
So hat man schon mal höhere Grundkosten, bei sehr, sehr, sehr viel 
schlechteren Leistungsdaten.

Dann hat der STM32 keine "ordenltiche"*1) RAM-Schnittstelle. Oh, man 
kann natürlich SDAM anschließen, aber das ist teuer und langsam, und 
größere Chips sind schwierig zu bekommen. Ein richtiger Prozessor kann 
DDR3. DDR3 bekommt man in größer und kostengünstiger als SDRAM und viel 
schneller.

Dann ist ein STM32 schon vom Pinout her nicht gut geeignet. Das RAM 
belegt viele Pins und blockiert damit andere Peripherie. Bei richtigen 
Prozessoren hat man das Problem in der Form nicht, denn die benötigen 
RAM immer, das wurde also berücksichtigt.
Darum oft auch die BGA-Packages.

d.h. ein richtiges Prozessorsystem ist nicht nur billiger, es ist auch 
leistungsfähiger. Um Größenordnungen.
Wo du mit dem STM32 mit 200MHz und 32MB RAM herumkrebst, bekommst du für 
weniger Geld wahrscheinlich einen SAMA5 mit 128MB DDR3 und 500MHz. 
Dreifache Rechenleistung (ja, der Cortex-A5 ist schneller!) und 
vierfachen RAM.

Warum gibts den STM32 dann, und warum ist er so beliebt? Weil er ein 
guter Microcontroller ist.

Warum ist ein Prozessor dann so viel billiger? Beisielsweise hat er kein 
Flash, welches teuer ist. Er kann in einem anderen Fertigungsprozess 
produziert werden, was Flächeneffizienter ist.

Ein Prozessor ist dafür andersherum ein mieserabler Microcontroller.

Es ist das alte Spiel: Da richtige Werkzeug für die richtige Anwendung. 
Die Kettensäge schneidet schlecht Brot, mit dem Brotmesser sägt man ewig 
an einer Fichte.

*1) aus Sicht eines richtigen Prozessors!

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eher nicht schrieb:
> Es ist das alte Spiel: Da richtige Werkzeug für die richtige Anwendung.
> Die Kettensäge schneidet schlecht Brot, mit dem Brotmesser sägt man ewig
> an einer Fichte.

Sehr schöne Metapher. Ich kannte bisher nur die Variante mit dem LKW und 
Brötchen holen.

Autor: C.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte mal ein Debian Linux auf einem GNUBLIN am laufen, 180MHz, 32MB 
RAM
Es hat funktioniert, war aber kein vergnügen.

Man musste auch etwas Tricksen, ein Teil das RAMs wurde komprimiert, 
weil das dann immer noch schneller war, als eine Auslagerungsdatei auf 
der SD-Karte zu benutzen.

Ist lange her, damals gab es noch keine RPis

Autor: M. H. (bambel2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C.K. schrieb:
> Ich hatte mal ein Debian Linux auf einem GNUBLIN am laufen, 180MHz, 32MB
> RAM
> Es hat funktioniert, war aber kein vergnügen.

Eben. Selbst mit 32 MB RAM machts nicht wirklich Spaß. Und < 10 MB wird 
sehr eklig. Und mit eineigen KB ist es einfach unmöglich. Da sollte man, 
wenn man unbedingt ein OS will ein RTOS o.ä. nehmen. Ich finde schon das 
Raspberry Pi, vorallem die alten, obwohl die 700+ MHz, GPU und mehrere 
hundert MB RAM haben, ziemliche Krücken. Klar das läuft. Aber ein 
richtig tolles Erlebnis ist es irgendwie nicht. Liegt aber auch an den 
SD Karten. Wenn man da eine langsame hat, macht es das zur Tortur.

Durch die fehlende MMU des STM ist man auf PIE und andere Sachen 
angewiesen. Außerdem funktionieren gewisse Grundpfeiler von Linux ohne 
MMU einfach nicht. Man ist auf speziell kompilierte SW angewiesen. Schon 
allein aus dem Grund, dass der STM keinen arm-Befehlssatz unterstützt, 
sondern "nur" den Thumb2 Mode. Vorkompilierte ARM Software kann somit eh 
nicht genutzt werden.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Das mag ja sein, aber in 128kB RAM (um die es hier geht) kriegst du nie
> und nimmer einen Linux Kern mit den Netzwerktreibern rein, die für
> TCP/IP notwendig sind.

Ich hab einfach mal stillschweigend die 8 MB zusätzlichen RAM für den 
Kernel vorausgesetzt. In 128 KB geht es natürlich nicht, darum mein 
Hinweis auf RetroBSD. Antikes UNIX ginge in 128 KB natürlich auch. :-)

eher nicht schrieb:
> Darum oft auch die BGA-Packages.

Richtig, und ein BGA-Package setze ich nicht "mal eben so" mit dem 
Lötkolben auf ein kleines Board. Einen STM32 schon eher.

eher nicht schrieb:
> Warum gibts den STM32 dann, und warum ist er so beliebt?
> Weil er ein guter Microcontroller ist.

Und warum gibt es dann Linux dafür?
Weil er in Maximalausstattung "gerade so" dafür ausreicht.

Merke: Ich widerspreche dir fachlich nicht. Siehe unten.

M. H. schrieb:
> Ich finde schon das Raspberry Pi, vorallem die alten,
> obwohl die 700+ MHz, GPU und mehrere
> hundert MB RAM haben, ziemliche Krücken.

Wenn du da ein normales Desktop-Linux drauf laufen lassen willst, 
wundert mich das nicht. Auf einem STM32 oder den anderen kleinen 
Embedded-Kisten läuft das auch nicht vernünftig. Aber Linux gibt es eben 
auch woanders.

M. H. schrieb:
> Man ist auf speziell kompilierte SW angewiesen. Schon
> allein aus dem Grund, dass der STM keinen arm-Befehlssatz
> unterstützt, sondern "nur" den Thumb2 Mode.

Naja, "speziell kompiliert" ist ein bisschen übertrieben. Debian bietet 
es halt nicht vorkompiliert an, ja. Ansonsten ist Thumb2 unter Linux 
jetzt auch nicht so exotisch. Die höhere Codedichte reduziert auf den 
großen Prozessoren den Druck auf den Cache, lohnt sich also auch da.

----

Um das Thema abzuschließen: Ich halte Linux auf dem STM32 für technisch 
äußerst interessant und für manche Anwendungen nicht komplett verkehrt. 
Nicht unbedingt als erste Wahl, aber der Sprung von "AVR" zu "STM32" ist 
aus meiner Sicht wesentlich kleiner als der von "STM32" zu "richtiges 
Linux", zumindest wenn man von unten schaut.

Dass es möglich ist, zeigen die vielen Geräte, die Linux auch mit 
geringen Taktraten (unter 500 MHz) und wenig RAM (unter 64 MB) auf 
vergleichsweise exotischen Architekturen (MIPS, ARM9) erfolgreich 
einsetzen. Viele Vorteile von Linux bleiben auch auf solchen Systemen 
erhalten, die man mit z.B. FreeRTOS nicht so einfach bekommt. Für ein 
Desktop-System sind die allesamt nicht geeignet, aber das sollen sie 
auch nicht.

Einiges, was aus der Entwicklung für solche Umgebungen entsteht, ist 
auch auf großen Systemen nützlich. Und sei es das Bewusstsein, was der 
Kernel-Entwickler bekommt, wenn er mal nicht "eben so" 800 MB RAM 
verschleudern kann.

Autor: jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Richtig, und ein BGA-Package setze ich nicht "mal eben so" mit dem
> Lötkolben auf ein kleines Board. Einen STM32 schon eher.

Dafür gibt es SOMs. Wie das:
https://www.microchip.com/design-centers/32-bit-mpus/sip-som/system-on-module

S. R. schrieb:
> Und warum gibt es dann Linux dafür?

Weil es Leute gibt, die das als proof of concept gemacht haben.

Mal im Ernst, kein Mensch wird das produktiv einsetzen wollen. Ein Profi 
nimmt das kostengünstigere Prozessorsystem, ein Hobbyist eine SOM oder 
schlicht Raspberry PI, eventuell aauch als Comute-Module:
https://www.raspberrypi.org/products/compute-module-3/

Ein SOM auf eine Platine löten oder einen Sockel für das Compute-Module 
ist sinnvoller und einfacher als diese Krücke.

Die Unterstützung für dieses STM32-Linux dürfte auch eher mau sein. Ich 
denke mal, wenn man das ernsthaft benutzen will, darf man sich 
wahrscheinlich für die meiste Peripherie erst einmal Treiber schreiben.

Da ist es einfacher, das mit Free-RTOs und der HAL oder gleich bare 
metal zu machen.

Beim SOM gibte Support vom Hersteller, beim Rasberry PI Comute Module 
hat man die gesamte Community. Da dürfte ein Großteil fertig sein.

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur mal so nebenbei, uCLinux lief schon vor 12 Jahren auf meinem uCSimm, 
ein System mit MC68EZ328, 16Mhz und 2MB Flash sowie 8MB RAM. Mit 2.4 
Kernel und kompletter Ausstattung inkl. Webserver, Framebuffer und 
diversen selbstgebastelten Treibern für Roboter Hardware.
Die ganze Nummer war überhaupt nicht langsam und als Steuerrechner 
durchaus brauchbar.
Wenn man sich ein Devboard mit RAM, wie z.B. das F429 Disco besorgt, 
kann das durchaus klappen. Allerdings sollte man sich anschauen, wie man 
komprimierte Flash Images herstellt. In den RAM wird so gut wie alles 
aus dem Flash dekomprimiert, deswegen brauchts 8MB.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Matthias S. schrieb:
> Mit 2.4
> Kernel

Ja, daaaamals - war ja kurz nachm Krieg wirhattenjanix - da konnte man 
auch noch aufm PC einfach einen Kernel auf eine 1.44MByte grosse Floppy 
schreiben und dahinter hat noch ein kleines rootfs gepasst und das ganze 
war auch noch bootfaehig. Die Zeiten sind lang vorbei :-/

Gruss
WK

Autor: jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Ja, daaaamals - war ja kurz nachm Krieg wirhattenjanix - da konnte man
> auch noch aufm PC einfach einen Kernel auf eine 1.44MByte grosse Floppy
> schreiben und dahinter hat noch ein kleines rootfs gepasst und das ganze
> war auch noch bootfaehig. Die Zeiten sind lang vorbei :-/

Vor allem ist das aus Bastlersicht völlig unsinnig. Ein uralter 
Raspberry PI 1 vom Flohmarkt schlägt jede STM32 Alternative um Längen 
(vermutlich auch preislich), und im Gegenzu dazu ist das Linux auf dem 
Ding ausgereift.

Wenn es natürlich um ein "proof of concept" geht, ja dann kann man das 
schon machen. Es ist ohne Frage eine Leistung, auf einer so kleinen CPU 
hinzubekommen, und sicher ein lehrreiches Hobby.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Matthias S. schrieb:
> Die ganze Nummer war überhaupt nicht langsam und
> als Steuerrechner durchaus brauchbar.

Das wollen die nicht sehen.

Matthias S. schrieb:
> Allerdings sollte man sich anschauen, wie man komprimierte
> Flash Images herstellt. In den RAM wird so gut wie alles
> aus dem Flash dekomprimiert, deswegen brauchts 8MB.

Der Kernel kann auch XIP, für sich selbst und für Userspace. Wenn man 
also genügend gemappten Flash zur Verfügung hat und mit der 
Performance-Einbuße leben kann, braucht man weniger RAM.

jemand schrieb:
> Es ist ohne Frage eine Leistung, auf einer so kleinen CPU
> hinzubekommen, und sicher ein lehrreiches Hobby.

Gleichzeitig lernt man viel über Linux, viel über STM32 und viel über 
Architekturen im Allgemeinen. Und man bekommt ein halbwegs nutzbares 
System.

"Raspi kann ja jeder."

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.