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. Es gibt auch eine Homepage mit ausführlicheren Informationen und einem git-Repository: http://www.rupert-eibauer.de/rupsched Als Beispielprogramm liegt auch ein Musikplayer bei, der gespeicherte Noten abspielt. Zur einfacheren Konfiguration hab ich song.config angehängt, welches im Rupsched-Verzeichnis mit dem Namen .config gespeichert werden sollte. Vor dem Compilieren kann man das System konfigurieren mit "make menuconfig". Hier sollte auf jeden Fall der passende Controller und die CPU-Frequenz ausgewählt werden. Damit könnnen auch alle Kernelfeatures sowie eine Applikation oder ein Test ausgewählt werden. "make rupsched.hex" oder "make rupsched.bin" erzeugt dann das Image für den Controller. "make upload" compiliert und lädt das Programm dann direkt auf den Controller, sofern avrdude installiert ist und im menuconfig richtig konfiguriert wurde. Es würde mich freuen, erfolreiche Testberichte auf anderer Hardware zu lesen, selbst habe ich nur atmega8 und atmega328 zur Verfügung.
:
Beitrag #5685146 wurde von einem Moderator gelöscht.
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
Märchen Zuhörer schrieb: > hmmmm.. schrieb: >> Das wird ja immer absurder. > > Naja, so ein Tiny mit 4K und zwanzig Prozessen hast doch was. Mehr hatten früher auch richtig große Maschinen nicht. Nur waren damals die Scheduler im Quadral-System programmiert (DNA) und zweibeinig. ;-)
:
Bearbeitet durch User
Willkommen auf µC.net - da gibt sich jemand Mühe, stellt einen Scheduler mit Seriell-Treibern zur Verfügung, und dann kommt die Fraktion "brauche ich nicht". Liebe Kritiker: ChibiOS, Contiki, Segger embOS, FreeRTOS sind euch nie untergekommen? Ihr braucht sie nicht und glaubt deswegen, niemand bräuchte sie? @Rup (den TO): nicht unterkriegen lassen, das ist der normale Ton hier. Ich selbst wäre ja neugierig, bin aber auf MSP430 und STM32 unterwegs.
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.
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:
1 | GEN arch/avr/devs |
2 | arch/avr/scripts/decode_packs: 28: arch/avr/scripts/decode_packs: Bad substitution |
3 | XMLDEC ATmega8.atdf |
4 | arch/avr/scripts/decode_packs: 60: arch/avr/scripts/decode_packs: php: not found |
5 | BAD XML ATmega8.atdf |
6 | arch/avr/Makefile:122: recipe for target 'arch/avr/devs' failed |
7 | make: *** [arch/avr/devs] Error 1 |
Mein System ist ein Ubuntu 18.04.1 mit dem Kernel 4.15 Gruss silch12
:
Bearbeitet durch User
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
Rup schrieb: > 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 Ich denke am bash liegts nicht. Nach Installation von php ist der Fehler verschwunden, allerdings ein neuer entstanden:
1 | arch/avr/scripts/decode_packs: 28: arch/avr/scripts/decode_packs: Bad substitution |
2 | XMLDEC ATmega8.atdf |
3 | PHP Fatal error: Uncaught Error: Class 'DOMDocument' not found in /home/cortesis/Downloads/rupsched/arch/avr/scripts/decode_pack.php:421 |
4 | Stack trace: |
5 | #0 {main}
|
6 | thrown in /home/cortesis/Downloads/rupsched/arch/avr/scripts/decode_pack.php on line 421 |
7 | BAD XML ATmega8.atdf |
8 | arch/avr/Makefile:122: recipe for target 'arch/avr/devs' failed |
9 | make: *** [arch/avr/devs] Error 1 |
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
Die Konfiguration hat jetzt funktioniert, auch mit /bin/sh Beim erzeugen des Images sind jetzt aber weitere Fehler aufgetreten:
1 | In file included from ./arch/avr/include/asm/system.h:6:0, |
2 | from kernel/sched.c:12: |
3 | kernel/sched.c: In function ‘_schedule’: |
4 | ./arch/avr/include/asm/system.h:41:18: error: ‘MCUCR_SM_IDLE’ undeclared (first use in this function) |
5 | set_sleep_mode(MCUCR_SM_IDLE); \ |
6 | ^ |
7 | ./arch/avr/include/asm/io.h:9:51: note: in definition of macro ‘out’ |
8 | #define out(reg, val) ((*(volatile u8*)reg) = val) |
9 | ^ |
10 | ./arch/avr/include/asm/system.h:41:3: note: in expansion of macro ‘set_sleep_mode’ |
11 | set_sleep_mode(MCUCR_SM_IDLE); \ |
12 | ^ |
13 | kernel/sched.c:353:3: note: in expansion of macro ‘safe_halt’ |
14 | safe_halt(); |
15 | ^ |
16 | ./arch/avr/include/asm/system.h:41:18: note: each undeclared identifier is reported only once for each function it appears in |
17 | set_sleep_mode(MCUCR_SM_IDLE); \ |
18 | ^ |
19 | ./arch/avr/include/asm/io.h:9:51: note: in definition of macro ‘out’ |
20 | #define out(reg, val) ((*(volatile u8*)reg) = val) |
21 | ^ |
22 | ./arch/avr/include/asm/system.h:41:3: note: in expansion of macro ‘set_sleep_mode’ |
23 | set_sleep_mode(MCUCR_SM_IDLE); \ |
24 | ^ |
25 | kernel/sched.c:353:3: note: in expansion of macro ‘safe_halt’ |
26 | safe_halt(); |
27 | ^ |
28 | ./arch/avr/include/asm/system.h:23:25: error: ‘MCUCR_SE’ undeclared (first use in this function) |
29 | out(MCUCR, in(MCUCR) | MCUCR_SE); \ |
30 | ^ |
31 | ./arch/avr/include/asm/io.h:9:51: note: in definition of macro ‘out’ |
32 | #define out(reg, val) ((*(volatile u8*)reg) = val) |
33 | ^ |
34 | ./arch/avr/include/asm/system.h:42:3: note: in expansion of macro ‘do_sleep’ |
35 | do_sleep(); \ |
36 | ^ |
37 | kernel/sched.c:353:3: note: in expansion of macro ‘safe_halt’ |
38 | safe_halt(); |
39 | ^ |
40 | scripts/Makefile.build:305: recipe for target 'kernel/sched.o' failed |
41 | make[1]: *** [kernel/sched.o] Error 1 |
42 | Makefile:1061: recipe for target 'kernel' failed |
43 | make: *** [kernel] Error 2 |
Werde es morgen wiederversuchen.
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.
Cooles Projekt! Hut ab! Ich plane damit rumzuspielen und es ggf. sogar in einem naechsten Projekt mal zu testen. Was mich etwas irritiert sind die Linux Includes. Kannst du da etwas darueber erzaehlen?
Nettes Projekt. Muß ich mir bei Gelegenheit mal etwas näher anschauen. Rup schrieb: > Benötigt wird auch die PHP-Erweiterung php-dom: > sudo apt-get install php-dom 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. Mein System: Debian Jessie (8.11) auf x86_64. Neben den offensichtlichen Paketen (ohnehin installiert) mußte ich noch php5-cli nachinstallieren. Das zieht php5-common mit rein, was seinerseits php-dom enthält. PS: ich verwende das GIT repo, nicht das angehängte ZIP für 0.5.0
:
Bearbeitet durch User
W.S. schrieb: > Und ein Makefile allenfalls nur zusätzlich. Als Linuxer versteht man > offenbar die Abneigung gegen Make nicht Dazu muß man kein Linuxer sein. Ich verstehe und akzeptiere, daß du make nicht verstehst und deswegen nicht nutzt. Ich kann das sogar ein kleines bißchen nachvollziehen, weil ich selber auch ein paar Tage gebraucht habe, bis mir das Konzept dahinter (und dessen Genialität) klar war. Nur: das war vor 25 Jahren. Es ist ganz sicher nicht so, daß make keine Einschränkungen hätte - deswegen gibt es ja auch so viele "verbesserte" Nachfolger: ant, bake, cook, cake, ... Aber die von dir favorisierten Batch-Skripte, gar noch für ein Fossil wie command.com sind mit Sicherheit keine Alternative. Schon gar keine bessere.
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.
W.S. schrieb: > 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. Komisch. Dieses Problem habe ich noch nie gehabt. Ich dachte immer, man würde Build-Hilfen zu einem Projekt tun, damit der Anwender das bauen (lassen) kann. Seien es nun Makefiles, IDE Projektfiles, .BAT oder sonstwas. > 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. Also ich bevorzuge ja, wenn da etwas dabei ist, das ich einfach nur nutzen kann. Eine .BAT für command.com gehört da regelmäßig nicht dazu. Und wenn ich Code veröffentliche, dann lege ich i.d.R. ein Makefile dazu. Das tut dann auch. Einfach nur "make" tippen und geht. Aber das ist nur die halbe Miete. Denn ein Makefile kann etwas, was die von dir favorisierte .BAT nicht kann: es kann selektiv nur die Teile eines Projekts neu bauen, die neu gebaut werden müssen. Das mag bei einem Spielprojekt mit 5 .h und 5 .c Files egal sein. Bei einem großen Projekt mit vielleicht 10.000 Files aber nicht mehr. Klar, eben um dieses Problem zu lösen, wurde make ja erfunden. > Aber es ist eben gut, wenn man in einem Projekt die Variante des > allerkleinsten gemeinsamen Nenners vorfindet. Tja. Da zähle ich make nun mal einfach dazu. Wer sich einen C-Compiler installiert, will eigentlich immer auch make haben. Und wenn man nicht sowieso auf einem System mit GNU Userland unterwegs ist, dann will man i.d.R. GNU make haben. Aber da der avr-gcc schon GNU ist, spricht auch nichts gegen GNU make. >> 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 Doch. Ein Makefile liest man genauso wie ein Programm in jeder anderen Programmiersprache. Das setzt natürlich voraus, daß man die Sprache kennt. Bei make ist die Hürde ein bißchen höher, weil es nicht - wie die meisten Programmiersprachen - imperativ ist, sondern deklarativ [1]. Aber klar, wenn man make dogmatisch ablehnt, weil man irgendwann irgendwo damit mal ein Problem gehabt hat, dann wird das natürlich nichts. "Was der Bauer nicht kennt, frißt er nicht" sagt der Volksmund. Na gut, dann muß der Bauer halt verhungern. [1] https://de.wikipedia.org/wiki/Deklarative_Programmierung
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)
Beitrag #5727499 wurde von einem Moderator gelöscht.
Beitrag #5727945 wurde von einem Moderator gelöscht.
Beitrag #5727962 wurde von einem Moderator gelöscht.
Beitrag #5728050 wurde von einem Moderator gelöscht.
Beitrag #5728295 wurde von einem Moderator gelöscht.
Beitrag #5728470 wurde von einem Moderator gelöscht.
Ich wuerde noch empfehlen statt einen eigenen Git Server zu verwenden, das Projekt auf Gitlab.com (mein Favorit) oder Github zu veroeffentlichen. Man kann viel leichter mal einen Blick reinwerfen und einfach via Merge/Pull Requests auch wieder etwas zurueckgeben.
:
Bearbeitet durch User
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.
Rup schrieb: > Ich kenn mich leider überhaupt nicht mit Docker aus Ist aber sehr empfehlenswert: man kann damit unkompliziert scriptgesteuert eine genau definierte Umgebung hochziehen lassen in der man dann ein programm ausführt (zum Beispiel den build von irgendwas mit extrem kniffligen Abhängigkeiten). Letztendlich läuft das so: Du legst eine Textdatei an (das Dockerfile) indem steht sinngemäß drin: * nimm ein minimales Ubuntu 18.10.2 (oder was auch immer) * installiere dieses * installiere jenes * lege diesem Benutzer an * lade selbiges herunter und kopiere es dorthin * mounte dieses verzeichnis dorthin * starte jenes Dazu gehört ein Satz Kommandozeilenwerkzeuge mit denen man das obige ausführen kann, ein Image kann nach obigem Plan gebaut werden (und in dem Zustand gecached damit es beim zweiten Mal nicht neu gebaut werden muss) und dann kann man sich dort quasi jederzeit hinein chrooten lassen und irgendwas darin ausführen. Also zum Beispiel könntest Du ein Script schreiben das wenn man es ausführt ein genau definiertes Linuxsystem als Docker-Image aufsetzt, das momentane Arbeitsverzeichnis dort drin irgendwohin mountet und dann eine shell darin startet. Und auf dieser shell würden dann all Deine make Aufrufe anstandslos funktionieren weil die ganze Umgebung exakt so ist wie geplant. Das ist hervorragend geeignet um hochkomplexe Buildsysteme zum Beispiel mit exotischer cross-Toolchain und hastenichgesehn idiotensicher zu verpacken. Der Nutzer könnte das auschecken, dann "make shell" sagen, dann rödelt es ein paar Minuten um das Image zu bauen (nur beim ersten Mal, danach nur noch ein paar ms) und plopp ist er in einer shell, umgeben von einer ganz genau definierten und reproduzierbaren Umgebung in der das "make menuconfig" und "make all" oder was immer da laufen soll reibungslos durchlaufen und ihm einen Kernel für irgendeine exotische Plattform bauen ohne daß er auch nur das geringste an seinem eigenen System herumschrauben oder kontaminieren musste. Es lohnt sich wirklich, gerade für so Sachen wie Du sie machst! Extrem nützlich! Definitiv ein Tool das In Deinen Werkzeugkasten gut hineinpassen würde!
:
Bearbeitet durch User
Beitrag #5728699 wurde von einem Moderator gelöscht.
1 | make |
2 | UPD include/config/kernel.release |
3 | UPD include/generated/uapi/linux/version.h |
4 | UPD include/generated/utsrelease.h |
5 | AR tests/built-in.a |
6 | sorry - this program has been built without plugin support |
7 | make[1]: *** [scripts/Makefile.build:449: tests/built-in.a] Fehler 1 |
8 | make: *** [Makefile:1058: tests] Fehler 2 |
Welches "program" ist da gemeint?
1 | avr-gcc --version |
2 | avr-gcc (GCC) 4.8.1 |
3 | Copyright (C) 2013 Free Software Foundation, Inc. |
4 | This is free software; see the source for copying conditions. There is NO |
5 | warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. |
Config ist mit "make oldconfig" erzeugt worden. Version ist git 9fbad725bd4cb0db5be1c399e22633a5d5dd8dc4
Beitrag #5728804 wurde von einem Moderator gelöscht.
Beitrag #5729210 wurde von einem Moderator gelöscht.
Beitrag #5729253 wurde von einem Moderator gelöscht.
Beitrag #5729780 wurde von einem Moderator gelöscht.
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?
Beitrag #5729969 wurde von einem Moderator gelöscht.
Beitrag #5729972 wurde von einem Moderator gelöscht.
Beitrag #5730025 wurde von einem Moderator gelöscht.
Beitrag #5730029 wurde von einem Moderator gelöscht.
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.
Es gab übrigens mal uCLinux mit ähnlicher Zielsetzung (allerdings für größere Microcontroller). https://de.wikipedia.org/wiki/ΜClinux https://en.wikipedia.org/wiki/ΜClinux Die Homepage http://www.uclinux.org ist momentan nicht erreichbar, aber https://web.archive.org/web/20181113230737/http://www.uclinux.org/ geht. Scheint sich aber seit 2016 nicht mehr weiterzuentwickeln. Was ich am hier vorgestellten Ansatz interessant finde ist dass er die Tools&Build-Infrastruktur übernimmt sowie Coding Style und manche Funktionsnamen, die in entsprechenden Kreisen bekannt ist, aber (im Gegensatz zu uCLinux) keinen Fork macht und dann mühsam versucht Unnötiges rauszunehmen. Also Bottom-Up-Neubau mit modernem Werkzeug statt Zerlegen... Schön wäre es wenn das auf Github o.Ä. liegen (gespiegelt) würde oder es einen GitWeb-Zugang gäbe. Dann könnte man per Web-Browser im Code stöbern.
:
Bearbeitet durch User
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.
Beitrag #5730925 wurde von einem Moderator gelöscht.
Beitrag #5730941 wurde von einem Moderator gelöscht.
Nop schrieb: > 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 Ehm...uClinux ist längst als 'nommu'-Variante in der Mainline drin. Und wird definitiv weiter gewartet. Und 'sinnlos' dürfte es für nur ganz wenige Architekturen gewesen sein. Ansonsten macht es sehr viel Sinn, für Hardware-Ansteuerungen und single-User auf den ganzen Virtualisierungs-Overhead zu verzichten. rupsched geht aber in eine andere Richtung. Da geht's wohl eher um Organisationsstruktur und Konfigurationsmanagement die linuxig sein soll. Weitere Linux-Ansätze machen auf 8-Bittern in der Tat wenig Sinn (pragmatisch gedacht).
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.