Hier gibt es ein Bare-Metall Betriebssystem für die RasPies: https://github.com/rsta2/circle Welche Vorteile könnte so etwas gegenüber einem Linux Betriebssystem haben? Wofür könnte man es benutzen?
Beitrag #6827176 wurde von einem Moderator gelöscht.
Die Geschwindigkeit duerfte ganz deutlich ueber einem Linux liegen. Zusaetzlich hast du noch den Vorteil das dein Programm nicht andauernd von einem Betriebsystem unterbrochen wird. Damit hat man mehr kontrolle ueber das was man machen will. Und dann wollen wir mal nicht vergessen das die meisten hier nicht mit Unix oder Linux aufgewachsen sind. Viele Raspberryanwender haben nur sehr rudimentaeres wissen ueber Unixoide Betriebsysteme. Da duerfte die Einarbeitung in eine baremetall System deutlich einfacher sein. Ich hab z.B in den 90er schonmal eigene Kerneldriver fuer Linux geschrieben. Ich bin mir aber sicher das ich das fuer ein aktuellen Kernel nicht mehr koennte ohne erstmal wieder kraeftig zu lernen. Und jetzt haeng doch mal an ein Raspberry irgendein neues cooles IC wo du nicht von anderen den Source abschreiben kannst und mach mal alles selber. Danach verstehst du dann den Reiz. :-) Allerdings verzichtet man natuerlich auch auf viel. Es gibt Gruende warum Linux mittlerweile die Welt beherrscht. Wer das nicht versteht kann ja mal einen Netzwerkstack selber schreiben.... Olaf
> Ist das nicht ein Oxymoron? Das ist das natuerliche wuchern von Unkraut! Eigentlich braeuchte man nur ein main.c und ein makefile mit der toolchain. Und dann kommt einer und sagt, hach ein Treiber fuer I2c waere nett damit ich faul und doof bleiben kann, dann kommt der naechste und sagt hach ich will aber ein Display an I2C anstecken und da waere es doch nett wenn ich das nicht auch noch selber programmieren kann. Und ueberhaubt eine Grafikumgebung fuer das Display waere nett. Oh...jetzt ist es ganz schoen kompliziert, wir brauchen einen Debugger. Hm...am besten uebers Netzwerk. Und dann ist ja auch C/C++ so schwierig. Geht nicht was einfacheres? Angeblich programmieren die Anfaenger doch alle in Phyton? Das will ich auch! Und der Prof in der Uni nimmt immer Matlab. Wieso kann ich das nicht auch auf dem Controller machen? Und dann hast du ein voll ausgebautes Linux, eine Birne nutzt letztlich Millionen Arbeitsstunden um eine LED Blinken zu lassen womit er einen Ghz Multicore voll beschaeftigt und traeumt von Energiesparen und Klimawandelverhinderung waerend der Raspi 5W braucht. Olaf :-)
Olaf schrieb: > Ich hab > z.B in den 90er schonmal eigene Kerneldriver fuer Linux geschrieben. Ich > bin mir aber sicher das ich das fuer ein aktuellen Kernel nicht mehr > koennte ohne erstmal wieder kraeftig zu lernen. Da sind seither mehr als 20 Jahre vergangen und Linux-Treiber für irgendwelche Sensoren etc. sind heutzutage sehr einfach zu basteln. Meist gibt es etwas mehr oder weniger Ähnliches, wo man sich Teile abschauen kann. Schwierig ist es nur wenn man z.B. ein neues Netzwerkprotokoll oder eine GPU einbauen will oder einen neuen Prozessor grundsätzlich unterstützen. Das scheint mir hier aber nicht die Aufgabenstellung zu sein. Lernen muss man jede Systemumgebung - selbst wenn man den Chip in Assembler oder irgendein modernes RTOS in C programmieren will. > Und jetzt haeng doch mal an ein Raspberry irgendein neues cooles IC wo > du nicht von anderen den Source abschreiben kannst und mach mal alles > selber. Danach verstehst du dann den Reiz. :-) Das geht auch vom User-Space aus... Da kann man I2C oder SPI oder GPIOs auch direkt steuern. Aber ein neuer Chip wo man den Source nirgends abschreiben kann ist auf jedem System "reizvoll" :)
:
Bearbeitet durch User
Beitrag #6827790 wurde von einem Moderator gelöscht.
Olaf
>Die Geschwindigkeit duerfte ganz deutlich ueber einem Linux liegen.
Vielleicht ist es auch eher möglich, Echtzeitanwendungen damit zu
schreiben.
Mich würde die Gesammtcodegröße und die Compilierzeit für das "Hello
World" interessieren. Dazu habe ich erst mal keine Angaben gefunden. Die
Frage ist auch, ob man jedesmal das gesamte System compilieren muss oder
ob man nur Teile hochladen kann.
Wenn man USB und den Bildschirm nicht nutzt, kann man wohl relativ zuverlässige Echtzeitanwendungen realisieren: https://github.com/rsta2/circle/blob/master/doc/realtime.txt
Ich werde den Verdacht nicht los dass bei circle versucht wird, einen Raspberry auf das Niveau eines Microcontrollers zu degradieren.
Olaf schrieb: > Eigentlich braeuchte man nur ein main.c und ein makefile mit der > toolchain. Klar, bei einem Cortex-A. Da braucht es mindestens mal noch eine gute Portion Assembler für die Exceptions, gerne auch noch Binary Blobs für SDRAM Initialisierung. Und die Peripherie ist so komplex dass das eine sehr, sehr lange main.c wird. Bei Multicore CPUs ist ein RTOS dazu auch angezeigt. Dazu kommt dann Thread-Synchronisation, MMU-Konfiguration (nötig für den Cache), Atomics,... Alles machbar, aber schon eine andere Hausnummer als ein AVR-Projekt mit einer main.c. Für die TI Sitara gibt's das ganze übrigens auch schon vom Hersteller direkt fertig, in Form diverser Libraries, eines optionalen RTOS und der zugehörigen CCS IDE, und sogar einer Peripherie-Dokumentation. Aber die TI SoC sind ja ein paar Cent teurer als die Broadcom SoC, oh nein...
> Vielleicht ist es auch eher möglich, Echtzeitanwendungen damit zu > schreiben. Vielleicht. Was aber auch interessant ist, solche Systeme starten extrem schnell. Ein Linux auf dem Raspberry braucht ja auch >10s. Sowas kann fuer manche Anwendungen auch wichtig sein. Mein Autoradio bootet beim einschalten auch jedesmal 10-15s. Da moechte ich den Programmieren immer persoenlich die Eier abschneiden weil mich das so nervt. > Mich würde die Gesammtcodegröße und die Compilierzeit für das "Hello > World" interessieren. Ich hab mir das gestern Abend mal kurz runtergeladen. Ich war geradezu baff erstaunt das configure und make einfach so ohne irgendeinen Firlefanz und Libarieproblem durchgelaufen ist. Das war wie 1995 als Linux in hochform war. Ich hab nicht auf die Uhr geschaut, aber das war so im einstelligen Sekundenbereich. Ein HelloWorld alleine ohne das System dahinter geht sicherlich <<1s. [olaf] ~/sources/Raspberry/circle/sample/01-gpiosimple: time make -j16 CPP main.o CPP kernel.o LD kernel.elf DUMP kernel.lst COPY kernel.img WC kernel.img => 36700 real 0m0.094s user 0m0.116s sys 0m0.035s Die Doku koennte vielleicht etwas besser sein. Es gibt da lediglich ein Verzeichnis mit ein paar Textfiles. Das wird den ganzen Klassen mit ihre Methoden nicht so gerecht. > Ich werde den Verdacht nicht los dass bei circle versucht wird, einen > Raspberry auf das Niveau eines Microcontrollers zu degradieren. Aehem, ein Raspberry ist ein Microcontroller. > (nötig für den Cache), Atomics,... Alles machbar, aber schon eine andere > Hausnummer als ein AVR-Projekt mit einer main.c. Man muss es ja nicht immer alles verwenden. Vielleicht reicht einem ja ein Core mit 1Ghz irgendeine kleine Anwendung und man weiss es einfach nur zu Schaetzen das man Raspberry ueberrall preiswert hinterher geworfen bekommt. Olaf
Olaf schrieb: > Aehem, ein Raspberry ist ein Microcontroller. Beim RP2040 mit Cortex-M würde ich zustimmen, aber nicht beim Raspberry Pi. Im Raspberry Pi arbeitet ein Cortex-A SOC, der ist näher an einem Laptop oder Smartphone.
Olaf (Gast) >Ich hab mir das gestern Abend mal kurz runtergeladen. Ich war geradezu >baff erstaunt das configure und make einfach so ohne irgendeinen >Firlefanz und Libarieproblem durchgelaufen ist. Das war wie 1995 als >Linux in hochform war. Super, vielen Dank dafür. Ich zögere immer ein ganze Weile, bevor ich mich in die Intallationsabgründe eines neuen System stürze. >> (nötig für den Cache), Atomics,... Alles machbar, aber schon eine andere >> Hausnummer als ein AVR-Projekt mit einer main.c. >Man muss es ja nicht immer alles verwenden. Vielleicht reicht einem ja >ein Core mit 1Ghz irgendeine kleine Anwendung und man weiss es einfach >nur zu Schaetzen das man Raspberry ueberrall preiswert hinterher >geworfen bekommt. Für DSP-Anwendungen kann man nicht genügend Rechenleistung haben, braucht aber vielfach kein Betriebssystem bzw. nur die notwendigsten Zugriffe auf Speicher, SPI und DA-Wandler. Da verzichte ich gerne auf den Overhead eines Betriebssystems für alles und reduziere das auf die Bedürfnisse der Anwendung.
Olaf schrieb >Ich hab mir das gestern Abend mal kurz runtergeladen. Ich war geradezu >baff erstaunt das configure und make einfach so ohne irgendeinen >Firlefanz und Libarieproblem durchgelaufen ist. Das war wie 1995 als >Linux in hochform war. Jetzt habe ich es auch mal ausprobiert und Du hast recht: Das lässt sich ohne irgendwelche Probleme auf eine Ubuntu21-System compilieren: [code git clone https://github.com/rsta2/circle.git cd circle/ ./makeall cd sample/ cd 01-gpiosimple/ make [/code] Jetzt fehlt nur noch die Installation auf einem RPI.
Das System muss auch bereits einen gewissen Reifegrad haben wenn man sich mal die Projektliste anschaut: https://github.com/rsta2/circle/wiki/List-of-Circle-based-projects Eigentlich fehlt mir hauptsaechlich an einer coolen Projektidee um damit mal schnell was hochzuziehen. :-) > Für DSP-Anwendungen kann man nicht genügend Rechenleistung haben, > braucht aber vielfach kein Betriebssystem bzw. nur die notwendigsten > Zugriffe auf Speicher, SPI und DA-Wandler. Die hast du trotzdem. Das System schein Klassen fuer mehr oder weniger den kompletten Raspberry mitzuliefern. https://github.com/rsta2/circle/blob/master/doc/classes.txt Olaf
>Das System muss auch bereits einen gewissen Reifegrad haben wenn man >sich mal die Projektliste anschaut: >https://github.com/rsta2/circle/wiki/List-of-Circle-based-projects In der Projektliste gibt's hier den Roland-Synthesizer. Das geht schon ziemlich in die Signalverabeitungsrichtung: https://github.com/dwhinham/mt32-pi
>In der Projektliste gibt's hier den Roland-Synthesizer. Das geht schon >ziemlich in die Signalverabeitungsrichtung: >https://github.com/dwhinham/mt32-pi Scheint ein Retroprojekt zu sein: https://www.youtube.com/watch?v=wYOk2CSc798
Olaf schrieb: > > Aehem, ein Raspberry ist ein Microcontroller. > Da würde ich den jetzt nicht einordnen wollen. Microcontroller sind für mich mehr so CPUs ohne virtuellen Speicher. Ein Raspi (insbesondere der PI400 auf meinem Tisch )hat die Leistung eines Pentium 3. Und den würde ich nicht unter Microcontroller einordnen. Und wenn ich Bar Metal programmieren möchte, dann nehmen ich Arm-M oder -R. Die die Features der -A Architketur kann ich gar nicht ausnutzen.
Olaf schrieb: > Man muss es ja nicht immer alles verwenden. Vielleicht reicht einem ja > ein Core mit 1Ghz Wenn man aber die MMU und damit den Cache nicht aktiviert wird der Core gewaltig ausgebremst. Daher ist dieser Aufwand quasi Pflicht. PittyJ schrieb: > Die die Features der -A Architketur kann ich gar nicht ausnutzen. Anwendungsprozessoren wie Cortex-A kommen häufig mit leistungsfähigen Peripherien wie SDRAM-Controller, LCD/Display-Interfaces (RGB, HDMI, DP, MIPI-SDI), gleich mehreren SDMMC-Interfaces, USB HS, Ethernet, Audio, DMA, und auch einfacheren Peripherie-Einheiten mit üppiger Ausstattung wie z.B. eine große Zahl an I²C-Interfaces, und natürlich jeder Menge Rechenleistung. Nebenbei sind sie auch noch absurd billig, sodass man sich fragt warum Mikrocontroller mit ihrer im Vergleich geradezu mickrigen Ausstattung deutlich teurer sein können. Für Projekte mit Multimedia-Aspekten (z.B. Digital Signage mit hoher Bildqualität) kann das schon interessant sein. Wobei man dann schon gute Gründe braucht nicht einfach Linux zu nutzen.
Ich hätte hier noch eine Frage zum Installationsvorgang auf dem RasPi. Unter Installation ( https://github.com/rsta2/circle ) steht folgendes: "Copy the Raspberry Pi firmware (from boot/ directory, do make there to get them) files along with the kernel.img (from sample/ subdirectory) to a SD(HC) card with FAT file system. Put the SD(HC) card into the Raspberry Pi." Reicht es beim RasPi wirklich, die Dateien auf eine SD zu schreiben? Normalerweise braucht es bei PCs doch speziell gekennzeichnete Bootsektoren und man muss ein Image vollständig auf eine Partition schreiben.
chris_ schrieb: > Normalerweise braucht es bei PCs doch speziell gekennzeichnete > Bootsektoren Das war mal so, vor UEFI. Der Raspberry Pi hat zwar kein UEFI, aber auch er kann direkt ab dem Start FAT32 Dateisysteme lesen. Der Raspberry Pi 4B hat seinen Bootloader in einem EEPROM, alle anderen Modelle laden ihn von der Datei /bootcode.bin auf der FAT32 formatierten SD Karte. Siehe https://www.raspberrypi.org/documentation/computers/raspberry-pi.html#raspberry-pi-4-boot-eeprom sowie die darunter folgenden Kapitel.
> Reicht es beim RasPi wirklich, die Dateien auf eine SD zu schreiben?
Ich gebs zu, ich hab es jetzt noch nicht probiert, aber wenn es da
steht?
Die Dinger booten ja alles erstmal irgendeine interne Firmware die dann
halt machen kann was der Hersteller fuer richtig hielt.
Das machen ja "normale" Mikrocontroller auch so wenn sie sich per RS232
oder USB flashen lassen.
Olaf
Noch was.... Immerhin laedt sich die Entwicklungsumgebung ja ein bootcode.bin von Raspberry runter und installiert das auch. Ganz so baremetallic wie man denkt ist das System damit ja nicht. 52kb als Bootloader, man ueberlege sich mal was man da alles rein bekommt. :) Olaf
chris_ schrieb: > Reicht es beim RasPi wirklich, die Dateien auf eine SD zu schreiben? > Normalerweise braucht es bei PCs doch speziell gekennzeichnete > Bootsektoren und man muss ein Image vollständig auf eine Partition > schreiben. Wie du schon schreibst, ist der Bootsektor für den PC gemacht. Der Raspi hat eine ganz andere CPU-Architektur und kann den darin enthaltenen Code daher gar nicht ausführen.
Markus schrieb: > Vielleicht ist es auch eher möglich, Echtzeitanwendungen damit zu > schreiben. Wenn die aktuelle Echtzeitfähigkeit des Linux auf dem RPi tatsächlich nicht ausreichen sollte, kann man auch den RPi mit Linux im AMP betreiben. Man lässt das Linux auf 3 Kernen laufen, dort hat man dann noch den gesamten Komfort des Linux und auf dem 4 Kern kann eine bare metal Anwendung in C/C++ laufen die wirklich harte Echtzeit machen kann. Die Kommunikation zwischen zwischen dem Linux und der Anwendung auf dem 4 Kern wird z.B. über shared memory realisiert. Solche Projekte gibt es schon. Nichtsdesto trotz finde ich das circle Projekt recht interessant auch wenn ich gerade keinen Anwendungsfall für mich sehe. Edit: Hier mal ein Beispiel für AMP auf dem RPi: https://telmomoya.blogspot.com/2016/10/asymmetric-multi-processing-amp-with.html
:
Bearbeitet durch User
> Wie du schon schreibst, ist der Bootsektor für den PC gemacht. Der Raspi > hat eine ganz andere CPU-Architektur und kann den darin enthaltenen Code > daher gar nicht ausführen. Ach wo. Es muss ja keiner im Bootsektor stehenden Code ausfuehren. Aber man kann ja schauen wo eine Partition anfaengt und dann von dort Daten laden/schreiben. Das hab ich schon 2005 mit einem Renesas R8C13 gemacht damit der auf einer SD-Karte daten ablegen konnte die ein PC einfach so lesen kann. > Nichtsdesto trotz finde ich das circle Projekt recht interessant auch > wenn ich gerade keinen Anwendungsfall für mich sehe. Das ist das Hauptproblem unserer Zeit. Es gibt deutlich mehr Mikrocontroller als Projekte. :-D Olaf
Olaf schrieb: > Es gibt deutlich mehr > Mikrocontroller als Projekte. Das empfinde ich nicht als Hauptproblem, die fehlende Zeit um die Menge an Schubladenprojekte abzuarbeiten ist das Problem :)
Markus schrieb: > Welche Vorteile könnte so etwas gegenüber einem Linux Betriebssystem > haben? Wofür könnte man es benutzen? Es gibt jede Menge 3D-Vorlagen für jede Menge 3D-Drucker, aber du kannst natürlich trotzdem dein Pferdchen fürs Schach selbst konstruieren. Immer empfehlen kann ich Batteriefächer...(auf meins bin ich ganz besonders stolz...) Ich krieg mich heute wohl nicht mehr ein :-) Rainer
Rainer V. schrieb: > Immer empfehlen kann ich Batteriefächer Gibt kein Holz mehr? In der Zeit wo ich einen 3D Drucker kaufe und mich mit der Software auseinander setze, kann ich für den Rest meines Lebens hölzerne Batteriefächer bauen. Im Gegensatz zu den labilen Plastikdingern von Conrad brechen die hölzernen auch nicht von alleine nach ein paar Jahren auseinander.
So, hab gerade mal das blinkende Testprogramm auf eine SD-Karte kopiert. Der erste Versuch hat nicht geklappt weil ein Raspberry wohl kein FAT12 unterstuetzt. :-) Dann hab ich auf einer grossen 2GB karte mit FAT32 mal alles aus boot da rueberkopiert, die config32 in config umgenannt, die arm7 datei erzeugt und draufkopiert und die kernel.img aus sample/01.. und es blinkt 10x. Das hier ist nun auf der SD-Karte: ls /run/media/olaf/245E-A98B/ armstub7-rpi4.bin bootcode.bin COPYING.linux fixup.dat README start.elf bcm2711-rpi-400.dtb config32.txt fixup4cd.dat kernel.img start4cd.elf bcm2711-rpi-4-b.dtb config64.txt fixup4.dat LICENCE.broadcom start4.elf bcm2711-rpi-cm4.dtb config.txt fixup_cd.dat Makefile start_cd.elf Keine Ahnung ob man wirklich alles braucht, aber ist ja Platz mit zum abwinken da. Da zeigt sich auch der Gewinn von dem System. Ich hab einen Raspberry1 in der kleinsten Ausbaustufe mit 512MB Ram und genommen. Auf so einer Magerkiste will man vermutlich heute auch kein Linux mehr haben. Das Teil ist von 2011, wie die Zeit vergeht... Olaf
interessant finde ich es auch, aber wie war das nochmal gemeint wenn man eine Frau interessant nennt? :) Gibt es auch andere Wege ein neues Programm zu übertragen oder zu debuggen? Immer über das Turnschuhnetzwerk ist auf Dauer doch extrem lästig?
> Gibt es auch andere Wege ein neues Programm zu übertragen oder zu > debuggen? Steht doch in der Doku.... Olaf
Erst mal danke an alle für eure Beiträge. Nun entwickelt sich dieser Thread doch noch zu einer sehr nützlichen Hife. Johannes S. (jojos) >Gibt es auch andere Wege ein neues Programm zu übertragen oder zu >debuggen? Immer über das Turnschuhnetzwerk ist auf Dauer doch extrem >lästig? Es gibt serielle Bootloader: https://github.com/rsta2/circle/blob/master/doc/bootloader.txt >The Circle project has an integrated serial bootloader, which can be used to >speed-up the development process and to make it more comfortable. The bootloader >has been adapted from the well-known bootloader by David Welch. Für den neuen Bootloader muss man Node.js installieren weil er in Java-Script geschrieben ist. Das finde ich schon wieder eher störend.
> Erst mal danke an alle für eure Beiträge. Nun entwickelt sich dieser > Thread doch noch zu einer sehr nützlichen Hife. Ich kann nur jedem empfehlen einmal den Dokulink durchzulesen den ich oben gepostet habe. Der duerfte jede Frage beantworten die hier im Thread aufgetreten ist. (z.B auch nach Hello World) Die von mir zu Anfang geaeusserte Kritik bezueglich Doku ist damit hinfaellig. Grob zusammengefasst: Circle ist nicht nur einmal main.cpp und dann bist du an der Reihe, es ist eher so ein Android fuer MaennerInnen. Also c++, makefiles, beliebige(=Emacs) Editoren verwendbar, gdb Nutzung moeglich, fuer so ziemlich alles was ein Raspberry an Hardware mitbringt sind Klassen verfuegbar. Um z.B mal eine der Ausgangsfragen zu beantworten, wenn man schon immer mal auf die schnelle was mit einem Mikrocontroller machen wollte aber da auch gerne einen HDMI ausgang haette, dann ist das schon relativ cool. Aehnliches koennte man zum Anschluss einer USB-Tastatur sagen. Oder zum spielen mit einem Multitaskingsystem mit mehreren Cores. Was mir nicht ganz so gefaellt ist die Benennung von Klassen und Methoden. Da finde ich Qt besser. Aber das ist vielleicht auch Geschmack und Gewoehnungssache. > Für den neuen Bootloader muss man Node.js installieren weil er in > Java-Script geschrieben ist. Das finde ich schon wieder eher störend. Ja so ein quatsch nervt natuerlich. Warum sollte jemand der schon c++ kann noch Java benutzen. Ich saege mir doch auch nicht freiwillig einen Arm ab. Olaf
Olaf schrieb: > wenn man schon immer > mal auf die schnelle was mit einem Mikrocontroller machen wollte aber da > auch gerne einen HDMI ausgang haette, dann ist das schon relativ cool. > Aehnliches koennte man zum Anschluss einer USB-Tastatur sagen. Oder zum > spielen mit einem Multitaskingsystem mit mehreren Cores. ...und was machst du sonst noch?? Ich meine, wenn's nicht nur auf die Schnelle gehen sollte...
> ...und was machst du sonst noch?? Ich meine, wenn's nicht nur auf die > Schnelle gehen sollte... Ich verstehe deine Frage nicht wenn es denn eine sein sollte. Olaf
Olaf schrieb: > Ich verstehe deine Frage nicht wenn es denn eine sein sollte. > > Olaf Ja Klar, am besten wäre es, wenn es dich gar nicht gäbe..dummmdeppp
Stefanus: >Siehe >https://www.raspberrypi.org/documentation/computers/raspberry-pi.html#raspberry-pi-4-boot-eeprom >sowie die darunter folgenden Kapitel. Ich habe mir den Link jetzt gerade angeschaut, aber der scheint mir speziell für den RPi4. Hier gibt es eine bessere Beschreibung des Bootvorgangs und der scheint recht aufwendig: https://raspberrypi.stackexchange.com/questions/10442/what-is-the-boot-sequence Wenn ich es richtig sehe, sind es folgende Files die gebraucht werden: bootcode.bin loader.bin config.txt cmdline.txt bcm2835.dtb kernel.img Meine Frage wäre jetzt noch: müssen die im obersten Verzeichnis liegen, oder irgendwo sonst?
Olaf: >Der erste Versuch hat nicht geklappt weil ein Raspberry wohl kein FAT12 >unterstuetzt. :-) Welchen RPi hast du benutzt? RPi4? Ich würde gerne einen Zero benutzen. Die oben gezeigten Datein scheinen aber für den RPi4 zu sein und ich sehe im Moment nicht, wie ich die Boot-Dateien für den Zero erzeugen kann.
Stefan ⛄ F. schrieb: > Siehe > https://www.raspberrypi.org/documentation/computers/raspberry-pi.html#raspberry-pi-4-boot-eeprom > sowie die darunter folgenden Kapitel. chris_ schrieb: > Ich habe mir den Link jetzt gerade angeschaut, aber der scheint mir > speziell für den RPi4. Nein, darunter gibt es Absätze für die älteren Modelle. Ich habe die extra dieses Kapitel verlinkt, damit du die Unterschiede zwischen Modell 4B und den älteren wahrnimmst.
> Meine Frage wäre jetzt noch: müssen die im obersten Verzeichnis liegen, > oder irgendwo sonst? Also bei mir liegt das alles im Hauptverzeichnis und es geht. So wie es aussieht unterstuetzt circle einmal ein relativ einfaches fat Filesystem welches keine Unterverzeichnisse kennt und einmal die Implementation von elmchan. Daher wuerde ich denken das zumindest beim booten erstmal auf die einfacher Implementation zurueckgegriffen wird. Aber letztlich ist das ja auch ziemlich egal oder? Wenn man jetzt anfaengt ueber einen dickes System mit allen Bells&Whistles nachzudenken kommt IMHO recht schnell die Frage auf warum dann nicht gleich Linux? Hier gibt es im uebrigen einen Thread vom Autor wo man diverse Designentscheidungen und Hintergruende nachvollziehen kann: https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=90130 Olaf
Ok, ich habe jetzt einfach den gesamten Inhalt des /boot Ordners ins Hautpverzeichnis der SD-Karte kopiert. Dann habe ich das Beispiel sample/01-gpiosimple mit make kompiliert und die erzeugte Datei kernel.img extra rüber kopiert und siehe da, die LED am RPi Zero blinkt. Verwirrt hat mich die Bezeichnung dieser Dateien im /boot Ordner: bcm2711-rpi-400.dtb bcm2711-rpi-4-b.dtb bcm2711-rpi-cm4.dtb Ich ging davon aus, dass diese für den Chip auf dem RPi4 gemacht sind und auf dem Zero nicht funktionieren.
Rainer V. schrieb: > Ja Klar, am besten wäre es, wenn es dich gar nicht gäbe..dummmdeppp Warum muß jetzt wieder gepöbelt werden?
> mit make kompiliert und die erzeugte Datei kernel.img extra rüber > kopiert und siehe da, die LED am RPi Zero blinkt. DA bin ich schon weiter. Ich kann schon Text auf meinen Monitor am HDMI ausgeben. :-p Olaf
Markus schrieb: > Olaf >>Die Geschwindigkeit duerfte ganz deutlich ueber einem Linux liegen. Das halte ich für eine insgesamt recht gewagte Vermutung. > Vielleicht ist es auch eher möglich, Echtzeitanwendungen damit zu > schreiben. Das geht mit Linux doch auch?!
> Das geht mit Linux doch auch?!
Echtzeit ist ein weiter begriff. Und Linux hat IMHO erst seit kurzem
angefangen sowas in den Kernel zu integrieren. Wuerdest du dich trauen
mit Linux DIREKT Schrittmotore zu steuern die sagen wir mal Teil einer
Fraese oder eines 3D-Druckers sind? Und falls es mittlerweile geht, dann
vielleicht einen Regelkreis eines Servomotor? Man kann die Schraube
immer weiter anziehen und irgendwann sind dann einfachere und
ueberschaubarere System vermutlich im Vorteil.
Olaf
Olaf schrieb: > Ja so ein quatsch nervt natuerlich. Warum sollte jemand der schon c++ > kann noch Java benutzen. Ich saege mir doch auch nicht freiwillig einen > Arm ab. Weil man auf Sicherheit steht? Sprich: nicht mit jedem kleinen Programmierfehler (da gibt es leider unzählige Möglichkeiten) gleich eine Sicherheitslücke aufreißen möchte. Das genau ist nämlich, was C/C++ seit Anbeginn der Zeit tut. Und immer weiter tut, trotz nunmehr mehrerer Jahrzehnte Erfahrung, die zeigen, dass es eben genau das tut. C/C++ ist in sich schlicht NICHT dafür designed, sicheren Code zu liefern. Sondern nur dafür, was immer der Dummbratzen von Programmierer eingibt, in einen Maschinencode umzusetzen, der mit höchstmöglicher Geschwindigkeit läuft. Das ist gleich doppelt Scheiße. Erstens ist diese "höchstmögliche" Geschwindigkeit der C/C++-Compiler (bzw. des von ihnen generierten Maschinencodes) doch sehr häufig noch einiges vom tatsächlichen Optimum entfernt. Zweitens wird halt auch jeder Programmierfehler ganz optimal schnell abgebildet. Also völliger Rotz. Zu langsam, um gegen Assembler anstinken zu können, Zu unsicher, um gegen wirkliche Hochsprachen anstinken zu können. Völlige Rotze. Und trotzdem die wichtigsten Sprachen. Das ist das, was ICH erstaunlich finde. Sagt einiges über deren Benutzer aus. Zumindest über die, die sie gerne benutzen und nicht nur mit Bauchschmerzen.
Olaf schrieb: > Echtzeit ist ein weiter begriff. Das stimmt, und leider wird er meistens falsch verwendet. > Und Linux hat IMHO erst seit kurzem > angefangen sowas in den Kernel zu integrieren. Die Realtime-Patches werden zwar erst jetzt in den Mainline-Kernel integriert, aber vorhanden und nutzbar sind sie schon lange. Zudem gibt es in Multicore-Systemen schon länger die Möglichkeit, bestimmte Kerne des Prozessors mithilfe des Bootparameters "isolcpus" vom Prozeßscheduler des Systems zu isolieren, und dann innerhalb des laufenden Linux-Systems bestimmte Prozesse mit dem Befehl taskset(1) exklusiv an ebendiese CPU-Kerne zu binden. > Man kann die Schraube > immer weiter anziehen und irgendwann sind dann einfachere und > ueberschaubarere System vermutlich im Vorteil. Dann kann es je nach Zeitbeschränkungen und den Anforderungen an die benötigte Rechenleistung natürlich sinnvoller sein, den Echtzeit-Teil auf einem oder mehreren angeschlossenen Mikrocontrollern zu realisieren.
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.