mikrocontroller.net

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


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

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

Autor: Tanenbaum's Eleve (Gast)
Datum:

Bewertung
-22 lesenswert
nicht lesenswert
Rup schrieb:
> 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.

"Linux is obsolete"

Autor: hmmmm.. (Gast)
Datum:

Bewertung
-9 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
1 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
12 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
-8 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
-8 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
6 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
1 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
-3 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
3 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
-1 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)

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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