Linux-ähnliches Betriebssystem für AVR

Das wird ja immer absurder. Ein AVR braucht kein Betriebssystem. Wer da 
nicht gescheit drauf programmieren kann mit den begrenzten Ressourcen, 
der sollte sich was anderes suchen.

hmmmm.. schrieb:
> Das wird ja immer absurder.

Naja, so ein Tiny mit 4K und zwanzig Prozessen hast doch was.

An sich ein sehr schönes Projekt, nur ist es leider überflüssig. So ein 
Kernel braucht einfach zu viele Ressourcen, die ja eh schon knapp sind.

Namaste

Rup schrieb:
> Hallo, ich möchte hier mein AVR-Betriebssystem vorstellen.
>
> Jahrelanges Programmieren im Linux-Kernel sind nicht spurlos an mir
> vorübergegangen, und so ist aus meinen Projekten über die Jahre ein
> Kernel entstanden, der erschreckende Ähnlichkeit mit dem Linux-Kernel
> hat.

Ähemm..

Nun, ich bin kein Linuxer, ich benutze auch keine AVR's. Deswegen sehe 
ich das ganze mit eben dem Abstand, der dir offensichtlich fehlt.

Stell dir vor, jemand will dein Projekt für irgend etwas benutzen. 
Dieser Jemand hat nen Mac-Aero oder einen Windows-PC und er will als 
Allererstes die Pins seines AVR zu seinem Projekt zuordnen. Dann will er 
natürlich auch per Serieller den Chip mit seinem PC kommunizieren lassen 
- weswegen er auf dein Projekt aufmerksam geworden ist. Natürlich will 
er auch ein paar eigene Kommandos hineinprogrammieren, die ganz 
projektabhängig sind. Ebenso natürlich all die Funktionalität, die sein 
Projekt erfordert.

Wie macht er das?

Wo findet er in deinem Projekt überhaupt einen Anfang? OK, er kann sich 
mit dem TC das ganze Archiv irgendwo hin auspacken und dann drin 
herumstochern. Und dann?
Warum gibt es keine Dokumentation?
Klarstellung: das ist eine Datei im PDF Format (was jeder lesen kann und 
was auch ordentlich mit Inhaltsverzeichnis, Kapiteln usw. strukturiert 
ist),
- die eine Einführung hat,
- die die Funktionsprinzipien erläutert,
- die Anwendung des Ganzen erläutert,
- die Systemvoraussetzungen erläutert
kurzum, die jemanden, der das Projekt noch nicht in- und auswendig 
kennt, didaktisch sinnvoll in selbiges einführt und ihm zeigt, wie man's 
benutzt.

Eine .rst Datei kann ich mir per TC ansehen, aber jemand anderes kann 
es mit den üblichen Bordmitteln nicht. Abgesehen davon sind die beiden 
Dateien eher auch ein Labern über Coding Styles und Lizenzregeln - und 
bei weitem keine Dokumentation.

Ansonsten ist mir aufgefallen, daß eine Vielzahl von deinen Quellen 
geradezu verseucht sind mit unzähligen #ifdef's. Das ist 
grottenschlecht, denn das setzt voraus, daß man nur mit einer ganz 
bestimmten Installation dein Projekt überhaupt übersetzen kann, weil 
erst noch - je nach irgendwelchen Kriterien - Definitionen oder Header 
mit Definitionen per Skript o.ä. erstellt werden müssen, um all diese 
#ifdef#s richtig zu bedienen.

Mein Rat wäre, das Ganze dramatisch einzukürzen. Alle wirklich zum 
eigentlichen Projekt benötigten Dateien in ein einziges Verzeichnis 
hinein, selbstverständlich nichts anderes als .c und .h Dateien, dazu 
ein Shellscript oder Batchdatei (je nach OS) zum Übersetzen und für die 
eigentlichen Tools jeweils eine .xcl (extended command line Datei), um 
Shellscript/Batchdatei klein und übersichtlich zu halten. Dazu im selben 
Verzeichnis die aus einem fehlerfreien Übersetzungslauf entstandenen 
Dateien (.o und .elf und .hex oder .bin) nebst Linkerliste. Die nicht 
zum Projekt gehörigen sonstigen Dateien (Dokumentation und etwaige 
Nebensachen) gehören in ein anderes Verzeichnis.

Und ein Makefile allenfalls nur zusätzlich. Als Linuxer versteht man 
offenbar die Abneigung gegen Make nicht. Dazu sag ich dir, daß ich auf 
meinem Arbeitsrechner über die Jahre ein gutes halbes Dutzend völlig 
verschiedener Make's gleichzeitig hatte. Das gab und gibt regelmäßig 
Streß und Fehlschläge, weil all diese Make's jeweils völlig 
unterschiedliche Syntax haben und keines die Makefiles eines anderen 
versteht. Und allen anderen, die eben NICHT Linux fahren, geht es ganz 
genau so.

Und: möglichst alle #ifdef's aus dem Projekt entfernen. Wenn dein 
Projekt wirklich wenigstens einigermaßen universell ist, dann sollte es 
auch ohne Breitseiten von #ifdef's auskommen.

Insbesondere soll es aber exakt in DER Version, die im 
Projektverzeichnis steht, übersetzbar sein, OHNE daß es auf 
Definitionen von außerhalb des Projektverzeichnisses angewiesen ist. 
Also keine Definitionen auf der Aufrufzeile des Compilers oder aus 
externen Quellen.

Ein solcherart aufgesetztes Projekt wird jeder mit jedem OS benutzen 
können, sofern er über einen zur Zielplattform geeigneten Compiler 
verfügt. So aber, wie sich das mir derzeit darstellt, ist dein Projekt 
wohl nur für dich selber brauchbar.

W.S.

Max G. schrieb:
> Liebe Kritiker: ChibiOS, Contiki, Segger embOS, FreeRTOS
> sind euch nie untergekommen? Ihr braucht sie nicht und glaubt deswegen,
> niemand bräuchte sie?

Der TO schreibt aber Linux-ähnlich und zumindest RTOS als 
Echtzeit-Betriebssystem ist m.E. nicht Linux-Ähnlich.

Hätt der TO ehrlicherweise von einem für Minimalsysteme simplifizierten 
Multitaskfähigen Mikrokernel geschrieben und sich nicht grosskötzig 
Linux-System auf die Fahnen geschrieben wär den Kritikern ein Grossteil 
des Substanz entzogen.

Aber Mglw ist es lediglich ein Plagiat der bereits genannten.

Danke fürs testen und sorry für die Bugs. Wird in der nächsten Version 
behoben.

Silvano C. schrieb:
> Erst einmal grosses Kompliment zu deinem Projekt, ich wollte schon
> immer
> ein kleines OS für den AVR implementieren (aus Freude und zum verstehen
> wie ein OS funktioniert), hab aber nie Zeit gefunden. Wollte nun dein
> Projekt testen, habe aber bei `make menuconfig` folgende Fehlermeldung
> erhalten:
>  GEN     arch/avr/devs
> arch/avr/scripts/decode_packs: 28: arch/avr/scripts/decode_packs: Bad
> substitution

Scheint als ob das script bash benötigt. Zur Abhilfe kannst du in der 
ersten Zeile von arch/avr/scripts/decode_packs /bin/sh durch /bin/bash 
ersetzen.

>  XMLDEC  ATmega8.atdf
> arch/avr/scripts/decode_packs: 60: arch/avr/scripts/decode_packs: php:
> not found

Hab ich wohl vergessen zu erwähnen, es wird auch ein php-Interpreter 
benötigt.

Gruss Rup

Silvano C. schrieb:
> arch/avr/scripts/decode_packs: 28: arch/avr/scripts/decode_packs: Bad
> substitution

Dieser Fehler (Bad substitution) kommt mit hoher Wahrscheinlichkeit von 
dash, welches bei Ubuntu anstelle von bash in /bin/sh verwendet wird.

> PHP Fatal error:  Uncaught Error: Class 'DOMDocument' not found in
> /home/cortesis/Downloads/rupsched/arch/avr/scripts/decode_pack.php:421

Benötigt wird auch die PHP-Erweiterung php-dom:

sudo apt-get install php-dom

Silvano C. schrieb:
> ./arch/avr/include/asm/system.h:41:18: error: ‘MCUCR_SM_IDLE’ undeclared (first 
use in this function)

Ich hab wohl zu lange vergessen, auf meinem atmega328 zu testen. Die 
angehängte Datei gehört nach arch/avr/include/asm, dann sollte es 
klappen.

W.S. schrieb:
> Und: möglichst alle #ifdef's aus dem Projekt entfernen. Wenn dein
> Projekt wirklich wenigstens einigermaßen universell ist, dann sollte es
> auch ohne Breitseiten von #ifdef's auskommen.

Bei einem Kernel kommt man nicht ohne ifdefs aus, wenn man expliziten 
Code hinschreiben will. Ausserdem ist generell nichts gegen ifdefs 
einzuwenden. Der Code ist so gut lesbar.

W.S. schrieb:
> So aber, wie sich das mir derzeit darstellt, ist dein Projekt
> wohl nur für dich selber brauchbar.

Offenbar nicht. Ich habe es mal eben ausgecheckt, konfiguriert, 
übersetzt, dabei sind nicht mal Minuten vergangen.

W.S. schrieb:
> Und ein Makefile allenfalls nur zusätzlich

Wie bitte? Konzept von Make verstanden? Langsam verstehe ich, warum in D 
der Fachkräftemangel beklagt wird.


An den TO: weiter so, das ist ein schöner, aufgeräumter Anfang, die paar 
"#if 1" sind jetzt keine Kritik wert. Solche minimal-OS sind nämlich 
schick für schmale 32 bit uC, wie die STM32 oder ZPU-Architektur auf dem 
FPGA. Da musst du allenfalls zwar gegen eCos, freeRTOS oder NuttX 
antreten, aber findest sicher eine Zielgruppe, die auch konstruktive 
Beiträge liefert, anstatt hier auf Embedded Marcel-R-Ranicki zu machen.

Was du sicher noch für erleichterte Anwendung bereitstellen könntest, 
ist ein Dockerfile, damit sich auch Windows-Nutzer mal 'schnell' das 
Ding auschecken können.

Axel S. schrieb:
> Aber die von dir favorisierten Batch-Skripte

Ach laß mal.

So ein simples Batch-Skript ist wohl die allereinfachste Methode, 
jemandem, der in ein ihm ansonsten unbekanntes Projekt hineinschaut, zu 
zeigen, was da zum Projekt dazugehört und was nicht und was 
schlußendlich zusammengelinkt wird. Na klar, man kann sowas auch verbal 
formulieren, aber ne Batchdatei ist stringenter und genauso gut lesbar.


Ob der Leser dann anschließend nun:

- sämtliche C-Dateien in seine Lieblings-IDE hineinkippt und sich von 
dieser sein Projektfile machen läßt,

- oder sich ein Makefile schreibt - wenn er denn darin so geübt ist wie 
du,

- oder schlichtweg den Pfad zu seinen Tools in besagtes Batchfile (oder 
Shellscript, je nach Gusto) einpflegt und dann diese Datei einfach so 
benutzt,

ist Sache des Lesers.
Aber es ist eben gut, wenn man in einem Projekt die Variante des 
allerkleinsten gemeinsamen Nenners vorfindet. Alles andere bedeutet 
nämlich, die Toolchain und/oder das Betriebssystems und/oder die IDE 
und/oder die Verzeichnisstruktur des Verfassers benutzen zu müssen. Das 
ist ne Einengung. Nun mag es sein, daß dieses dem Verfasser schnurz ist. 
Aber weshalb hat er dann das Ganze überhaupt veröffentlicht?


Axel S. schrieb:
> weil ich selber auch ein paar Tage gebraucht
> habe, bis mir das Konzept dahinter (und dessen Genialität) klar war

Eben. Ein Makefile liest man nicht eben einfach so, mal ganz abgesehen 
davon, daß da jeder Hersteller sein Extrasüppchen kocht. Nimm man eins 
von Embarcadero und vergleiche das mit dem von Fujitsu... Und wenn du 
das 3. oder 4. Make dir angelesen hast, dann bringst du alle bisherigen 
im Kopf durcheinander. Nee, Make ist zumindest für mich keine Option. 
Und was ich schon seit langer Zeit von den GCC-Leuten kenne, ist, daß 
dort Makefiles und Linkerscripte ganz häufig kopiert und dann angepaßt 
werden - eben weil kaum einer sowas noch selbst schreiben kann. Das ist 
ein bissel so wie mit den .inf Dateien bei Windows.

Abgesehen davon ist es mir schnurz, ob nun command.com ein Fossil ist 
oder nicht, solange es im OS noch irgend etwas gibt, was zumindest 
dessen allereinfachste Kommandos auszuführen gestattet - und das wird 
auch in den nächsten 20..30 Jahren so sein, da bin ich mir sicher.

W.S.

Axel S. schrieb:
> Bei mir funktioniert es. "make menuconfig" genauso wie "make". Nur
> hochgeladen habe ich es bis jetzt nicht. Im Prinzip sollte ein Arduino
> nano doch funktionieren, oder? Zumindest für die UART Tests.

Wenn die Baudrate, die CPU und die CPU-Frequenz im menuconfig richtig 
eingestellt sind, sollte es funktionieren. Ich kann mich erinnern, dass 
der Adruino-Bootloader Probleme macht, wenn man eine Baudrate unter 
19200 einstellt, hatte aber noch nicht die Möglichkeit das Problem zu 
debuggen.

Armin S. schrieb:
> Was mich etwas irritiert sind die Linux Includes. Kannst du da etwas
> darueber erzaehlen?

Das ganze verwendet wo es as Performance- und Platzgründen möglich ist, 
die selben APIs wie im Linux-kernel intern.
Ich hab auch schon darüber nachgedacht, ganze Header-Files direkt vom 
Linux-Kernel zu übernehmen, aber die sind meist zu komplex und benötigen 
wieder andere Headerfiles. Jedes mal wenn ich eine neue Funktion 
benötige, schaue ich im Linux-Kernel nach, wie das dort implementiert 
ist, und wähle nach Möglichkeit die selben Namen für Headerfiles, Makro- 
und Funktionsnamen.

Für Dinge, die im Linux-Kernel nicht zu finden sind, verwende ich 
include/rupsched.
Im Prinzip ist das ganze Ding darauf ausgelegt, den Code-Klau aus dem 
Linux-Kernel zu vereinfachen, deshalb auch die selbe Lizenz, das Kernel 
Build-System und die selbe Verzeichnisstruktur.

Sehr geehrter TO,

auf der Projektseite existiert keinerlei Impressum und 
Datenschutzerklärung konnten wir auch nicht finden. Wir ersuchen Sie 
höflichst, diese Fehler zu beheben, die benötigten Informationen sind 
leicht im Internet zu finden.

Mit freundlichen Grüßen
ein überkonzentrierter Abmahnanwalt

Freut mich sehr, dass es nicht nur negatives Feedback gibt.

Fitzebutze schrieb:
> An den TO: weiter so, das ist ein schöner, aufgeräumter Anfang, die paar
> "#if 1" sind jetzt keine Kritik wert. Solche minimal-OS sind nämlich
> schick für schmale 32 bit uC, wie die STM32 oder ZPU-Architektur auf dem
> FPGA. Da musst du allenfalls zwar gegen eCos, freeRTOS oder NuttX
> antreten, aber findest sicher eine Zielgruppe, die auch konstruktive
> Beiträge liefert, anstatt hier auf Embedded Marcel-R-Ranicki zu machen.

Die Portierung auf andere Prozessoren ist schon sehr lange geplant, und 
wenn ich mal ein Projekt auf einem anderen Microcontroller hab, werd ich 
das in Angriff nehmen. Die nötige Infrastruktur ist vorhanden, alle 
AVR-spezifischen Sachen sind in arch/avr bzw. drivers/avr abgekapselt.

> Was du sicher noch für erleichterte Anwendung bereitstellen könntest,
> ist ein Dockerfile, damit sich auch Windows-Nutzer mal 'schnell' das
> Ding auschecken können.

Ich kenn mich leider überhaupt nicht mit Docker aus, aber vielleicht 
findet sich jemand, für den das kein Problem ist, ich werd das dann 
gerne mit dazupacken.

Zu der entstandenen Diskussion über den Sinn von Makefiles möchte ich 
noch anmerken, dass mein Projekt die Makefiles des Linux-Kernels (mit 
nur wenigen Änderungen) enthält und verwendet. Es sind insgesamt 145 kB 
an Makefiles enthalten und die Kernel-Makefiles sind das komplexeste, 
was mir bisher an Makefiles untergekommen ist.

Da ich das Projekt so linuxähnlich wie möglich halten will, hab ich auch 
nicht vor, daran etwas zu ändern.

Im Übrigen hab ich gerade Version 0.5.1 released, downloadbar von der 
Website (wo auch ein bisschen Dokumentation steht)

Ich finde das Gejammer diverser Kollegen hier mehr als peinlich.

Warum soll man auf einem AVR nicht mal zum Spaß ein unixoides 
Betriebssystem laufen lassen? Unix kommt aus einer Zeit da wäre einer 
der größeren AVRs locker als Zielplatform durchgegangen (wir ignorieren 
mal von-Neumann und Harvard).

Ein ATmega bringt bis zu 22 MIPS. Das erste unixoide Betriebssystem, mit 
dem ich erfolgreich kommerziell gearbeitet habe, lief auf einem 
Prozessor mit 2,7 MIPS. Die erste Unix-Workstation, die ich verwendete, 
lief auf einem Prozessor mit 5,4 MIPS - und hatte vier Terminals 
angebunden. Die legendäre SPARCstation 1 hatte 12,5 MIPS.

Im Vergleich zu den Rechnern auf denen Unix entstanden waren das bereits 
Superrechner. Eine PDP-11/20 von 1970 hat über den Daumen gepeilt 0,02 
MIPS (MIPS als Maßeinheit wurde erst 10 Jahre später erfunden). 
Taktfrequenz war, glaube ich, 1,25 MHz. Eine PDP-7, auf der die ersten 
Unix-Versuche stattfanden, hatte vielleicht 0,002 MIPS und sagenhafte 4K 
Worte Speicher (mit 18 Bits/Wort) bis 64K Worte (Speicher-Vollausbau), 
Taktfrequenz so um die 600 kHz.

oder in Pascal, damit es dann genau stabil läuft wie das legendäre Apple 
Os damals...

apropro, in Pascal gab es ja Betriebssysteme..aber gab es auch welche in 
Basic:)

Oder gab er kompilierte Basicprogramme erst ab Qbasic?

Kim P. schrieb:
> Oder gab er kompilierte Basicprogramme erst ab Qbasic?
Nein, natürlich nicht:
https://de.wikipedia.org/wiki/BASCOM_(Microsoft)

Rup schrieb:
> Da ich das Projekt so linuxähnlich wie möglich halten will, hab ich auch
> nicht vor, daran etwas zu ändern.

Bloss nicht auf das Trollgeunke hören. Der Linux-ähnliche Ansatz kommt 
typischerweise bei allen ernsthaften Entwicklern gut an.
Vielleicht kennst du ja auch antares von 'nekromant'. Die Strategie, so 
uC-Systeme zu bauen und zu testen ist eigentlich optimal, gerade wenn 
man Konfigurationen für viele Architekturen verwalten muss.

Was Docker angeht, unterschreibe ich prof7bits Aussage. Du kannst so 
deine ganzen Build-Setups und allenfalls Regresstests in die Cloud 
packen, z.B. klonst du unter hub.docker.com dein Entwicklungssystem und 
packst ein einfaches YML-File dazu, was definiert, wie was 
getestet/gebaut werden soll, wenn du bei github (u.a.) Änderungen 
eincheckst.
Das ist für meine Kunden schon länger "state of the art", wird auch 
exzessiv mit Hardwaredesigns gemacht und spart massiv Zeit. Kostet zudem 
keinen Cent extra.

Damit führt das auch das Gestänkere von W.S. ad absurdum, der Container 
ist die funktionierende Referenz (und läuft auch unter Klicki-Bunti-OS), 
so kann man den auch dem Kunden irgendwann in die Hand drücken: "Mach 
selber". Das ist für mich nachhaltige Entwicklung.

Leider hier im Forum hat das Gehate und Getrolle offenbar frustrierter 
Frickler derart zugenommen, dass sich die Frage stellt, ob es überhaupt 
noch Sinn macht, hier zu posten aka Perlen vor die Säue zu werfen. 
Fazit: Dickes Fell zulegen, und es nicht als Massstab für die Qualität 
der eigenen Software nehmen, wenn die üblichen Threadvandalen ihre 
Meinungsmache betreiben oder schlicht den Sinn von Opensource nicht 
verstehen.

Könnte ein recht cooles Projekt sein, also erstmal Daumen rauf! Ist aber 
etwas schwer zu sagen, denn die Dokumentation sagt leider nahezu nichts 
aus.

Wieviel RAM/ROM belegt ein System in welcher konkreten Konfiguration?

Welche von Linux her gewohnten Features gehen und welche nicht?

Wie sehr muß man sagen wir ein Konsolenprogramm vom Linux-Userland 
anpassen?

Was ist mit Threading, geht das über etwas wie Posix-Threads mitsamt 
Mutexes, Conditions und so?

Dynamische Speicher-Allozierung? Was ist mit Speicherfragmentierung, wo 
es ja kaum einen virtuellen Adreßraum geben kann?

Daß man zum Build PHP braucht, ist aber auch für Linuxverhältnisse schon 
ungewöhnlich. Ich entsinne nicht, daß man das z.B. beim Kernel bräuchte.

Zur Datenschutzerklärung: nimm raus, daß Du IP-Adressen nicht als 
persönliche Daten betrachtest. Es ist irrelevant, was Du denkst, denn es 
ist gesetzlich bereits als persönliches Datum definiert, exakt um solche 
Manöver zu verhindern.

Schreib einfach, daß sie nach angemessener Zeit gelöscht werden - je 
kürzer die Zeit ist, desto angemessener. Krisenmaßnahmen brauchen keine 
Daten, die ein halbes Jahr alt sind. Eine Woche sollte dafür reichen.

Direkt einen bewußten Verstoß gegen die DSGVO auch noch einzugestehen, 
ist wohl die ungeschickteste Variante.

Nikolaus S. schrieb:
> Es gab übrigens mal uCLinux [...]
> Scheint sich aber seit 2016 nicht mehr weiterzuentwickeln.

Nein, weil es vollkommen sinnlos war. Es war nämlich zu groß fürs 
interne RAM und mußte deswegen in externes RAM geladen werden. Nicht 
nur, daß man STM32 gerade nimmt, weil man kein externes RAM bestücken 
will (ansonsten kann man auch gleich Cortex-A und normales Linux 
nehmen), sondern Code daraus läuft auch noch um größenordnungsmäßig 
einen Faktor 10 langsamer als aus dem ROM.