mikrocontroller.net

Forum: Projekte & Code Linux-ähnliches Betriebssystem für AVR


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Rup (Gast)
Datum:
Angehängte Dateien:

Bewertung
13 lesenswert
nicht lesenswert
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.
Autor: hmmmm.. (Gast)
Datum:

Bewertung
-11 lesenswert
nicht lesenswert
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.

Autor: Märchen Zuhörer (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
hmmmm.. schrieb:
> Das wird ja immer absurder.

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

Autor: 123789 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Carl D. (jcw2)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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
Autor: Max G. (l0wside) Benutzerseite
Datum:

Bewertung
17 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
-9 lesenswert
nicht lesenswert
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.

Autor: Tanenbaum's Eleve (Gast)
Datum:

Bewertung
-9 lesenswert
nicht lesenswert
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.

Autor: Silvano C. (silch12)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
 XMLDEC  ATmega8.atdf
arch/avr/scripts/decode_packs: 60: arch/avr/scripts/decode_packs: php: not found
BAD XML ATmega8.atdf
arch/avr/Makefile:122: recipe for target 'arch/avr/devs' failed
make: *** [arch/avr/devs] Error 1

Mein System ist ein Ubuntu 18.04.1 mit dem Kernel 4.15

Gruss silch12

: Bearbeitet durch User
Autor: Rup (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Silvano C. (silch12)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
arch/avr/scripts/decode_packs: 28: arch/avr/scripts/decode_packs: Bad substitution
 XMLDEC  ATmega8.atdf
PHP Fatal error:  Uncaught Error: Class 'DOMDocument' not found in /home/cortesis/Downloads/rupsched/arch/avr/scripts/decode_pack.php:421
Stack trace:
#0 {main}
  thrown in /home/cortesis/Downloads/rupsched/arch/avr/scripts/decode_pack.php on line 421
BAD XML ATmega8.atdf
arch/avr/Makefile:122: recipe for target 'arch/avr/devs' failed
make: *** [arch/avr/devs] Error 1

Autor: Rup (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Silvano C. (silch12)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Konfiguration hat jetzt funktioniert, auch mit /bin/sh
Beim erzeugen des Images sind jetzt aber weitere Fehler aufgetreten:
In file included from ./arch/avr/include/asm/system.h:6:0,
                 from kernel/sched.c:12:
kernel/sched.c: In function ‘_schedule’:
./arch/avr/include/asm/system.h:41:18: error: ‘MCUCR_SM_IDLE’ undeclared (first use in this function)
   set_sleep_mode(MCUCR_SM_IDLE); \
                  ^
./arch/avr/include/asm/io.h:9:51: note: in definition of macro ‘out’
 #define out(reg, val)     ((*(volatile u8*)reg) = val)
                                                   ^
./arch/avr/include/asm/system.h:41:3: note: in expansion of macro ‘set_sleep_mode’
   set_sleep_mode(MCUCR_SM_IDLE); \
   ^
kernel/sched.c:353:3: note: in expansion of macro ‘safe_halt’
   safe_halt();
   ^
./arch/avr/include/asm/system.h:41:18: note: each undeclared identifier is reported only once for each function it appears in
   set_sleep_mode(MCUCR_SM_IDLE); \
                  ^
./arch/avr/include/asm/io.h:9:51: note: in definition of macro ‘out’
 #define out(reg, val)     ((*(volatile u8*)reg) = val)
                                                   ^
./arch/avr/include/asm/system.h:41:3: note: in expansion of macro ‘set_sleep_mode’
   set_sleep_mode(MCUCR_SM_IDLE); \
   ^
kernel/sched.c:353:3: note: in expansion of macro ‘safe_halt’
   safe_halt();
   ^
./arch/avr/include/asm/system.h:23:25: error: ‘MCUCR_SE’ undeclared (first use in this function)
  out(MCUCR, in(MCUCR) | MCUCR_SE); \
                         ^
./arch/avr/include/asm/io.h:9:51: note: in definition of macro ‘out’
 #define out(reg, val)     ((*(volatile u8*)reg) = val)
                                                   ^
./arch/avr/include/asm/system.h:42:3: note: in expansion of macro ‘do_sleep’
   do_sleep(); \
   ^
kernel/sched.c:353:3: note: in expansion of macro ‘safe_halt’
   safe_halt();
   ^
scripts/Makefile.build:305: recipe for target 'kernel/sched.o' failed
make[1]: *** [kernel/sched.o] Error 1
Makefile:1061: recipe for target 'kernel' failed
make: *** [kernel] Error 2

Werde es morgen wiederversuchen.

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

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fitzebutze (Gast)
Datum:

Bewertung
7 lesenswert
nicht lesenswert
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.

Autor: Armin S. (knall_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
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.

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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

Autor: Rup (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rup (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Abmahnung incoming (Gast)
Datum:

Bewertung
-7 lesenswert
nicht lesenswert
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

Autor: Rup (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rup (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.
Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Marten Morten (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Frank K. (frank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
make
  UPD     include/config/kernel.release
  UPD     include/generated/uapi/linux/version.h
  UPD     include/generated/utsrelease.h
  AR      tests/built-in.a
sorry - this program has been built without plugin support
make[1]: *** [scripts/Makefile.build:449: tests/built-in.a] Fehler 1
make: *** [Makefile:1058: tests] Fehler 2

Welches "program" ist da gemeint?
avr-gcc --version
avr-gcc (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
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.
Autor: Kim P. (Gast)
Datum:

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

Autor: Kim P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Tom (Gast)
Datum:

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

Autor: Fitzebutze (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Nikolaus S. (Firma: Golden Delicious Computers) (hns)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Dieser Beitrag kann nur von angemeldeten Benutzern beantwortet werden. Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.