mikrocontroller.net

Forum: Compiler & IDEs Windows-Toolchain für RaspberryPi gesucht


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: Ralf (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

ich hab einen Rpi 3B+ in die Hände bekommen und wollte mich nun mal 
etwas näher mit dem Teilchen beschäftigen.

Also brauch ich freilich nun erstmal eine Toolchain. Mein blauäugiger 
Ansatz war, Gurgl nach einer Windows Toolchain zu befragen, aber so 
richtig fündig bin ich nicht geworden - mit ziemlicher Sicherheit suche 
ich falsch oder das was ich gern hätte gibt's nicht für Windows :D

Was ich mir so als Ziel gesteckt habe:
- Entwicklung generell für Raspbian
- erste einfache Programme in C/C++ für die Shell entwickeln (das 
Äquivalent zu Windows Konsolenanwendungen)
- später auch Programme mit GUI
- Treiberentwicklung => nicht über Libs für GPIO, I2C, SPI o.ä. als 
Userprogramm, sondern das was für Linux echte Treiber sind (unter Linux 
heisst das glaube ich Modul bzw. fest in den Kernel implementiert, ist 
das so korrekt?)
- Und natürlich dann auch mal den Kernel selbst kompilieren

So richtig schlau werde ich aus dem Angebot an IDEs/Toolchains nun 
nicht, ob ich mit einer einzigen Umgebung alles oben genannte 
abgeklappert bekomme :/ Wäre halt schön wenn es sowas gibt.

Schön wär's wie gesagt wenn's da etwas für Windows gibt. Wobei Linux in 
einer VM laufen zu lassen nach meiner Definition nicht "für Windows" 
bedeutet ;P
Allerdings: wenn die strikte Empfehlung "mach's auf nem Linux-Host" 
lautet, dann beuge ich mich der Empfehlung - genug Rechner hab ich zur 
Verfügung, so isses nich'. Ich schrecke nur ein wenig vor dem 
"manuellen" Konsolenhandling, Scripting, etc. zurück, welches man unter 
Linux wohl braucht, um den Kernel, etc. zu bauen (Achtung: Halbwissen!!! 
Diesen Eindruck habe ich halt gewonnen, als ich mir Tutorials zum 
Kernelbau etc. angeschaut habe).

Für Anregungen, etc. und auch Literaturtipps bin ich dankbar.

Grüße

Autor: 900ss D. (900ss)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Diese Toolchain hab ich unter Windows genutzt.
Funktioniert sehr gut. Als IDE hab ich Eclipse genutzt.

https://gnutoolchains.com/raspberry/

Autor: Harri (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich baue die Sachen immer gleich auf dem Zielsystem per SSH. Der Pi 
liegt im Netz (ohne Tastatur und Display) und die Entwicklung läuft über 
mehrere SSH-Sitzungen.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@900ss:
Und damit könnte ich mit einer Toolchain alles was ich vorhabe 
erschlagen?

@Harri:
Okay, das heisst der PC ist eigentlich nur mein "Terminal"? Die ganze 
Scripterei etc. würde dann auf mich zukommen, korrekt? Wobei es da ja 
vielleicht Vorlagen gibt... wie lange dauert denn da ein bspw. ein 
Kernelbuild?

Ralf

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für Programme (C/C++) benutze ich die ECLIPSE IDE mit passenden 
Crosscompiler für Arm. Wie das Ganze installier wird ist hier 
https://github.com/awesomebytes/xenorasp/wiki/Crosscompile-a-program-from-your-computer-to-your-Raspberry-Pi 
beschrieben.
Vorteil der ECLIPSE IDE ist, das man diese auch noch für andere 
Programmiersprachen benutzen kann.

Shell- und Phytonscripte mache ich meist mit PSPad 
(http://www.pspad.com/de/) und dem BitVise SSH 
Clienten(https://www.bitvise.com/ssh-client-download). Mit der 
Kombination beider Programme arbeitet man per SSH auf dem RasPi. Mit 
dieser Kombi lassen sich generell alle Textdateien auf dem RasPi sehr 
gut bearbeiten.

Kernel und Module würde ich direkt auf dem Raspi compilieren. Ebenso 
Programme die nur als Sourcecode erhältlich sind. So ist sicher 
gestellt, das alle Abhängigkeiten passen. Man kann es natürlich auch per 
Crosscompiler auf dem PC machen, aber dann muß man sicher stellen, das 
die Sourcen/Headerfiles zum auf dem Pi laufenden Kernel passen. Wenn man 
da mehrere Pi mit verschiedenen Kernelversionen hat verliert man da 
schnell den Überblick.

Die beschriebene Vorgehensweise hat sich bei mir seit mehreren Jahren 
bewährt.

Autor: 900ss D. (900ss)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich habe nur Programme für die Shell damit gebaut.

Keine Treiber, Kernel oder GUIs.

Kernel habe ich unter Linux auf dem PC mit Crosstoolchain gebaut. Ich 
hatte keine Lust Stunden zu warten wenn das auf dem Raspi gebaut wird.

Heute würde ich wohl alles auf unter Linux auf einem PC 
crosscompilieren.
Ich hatte das Linux in einer VM und damit geht es auch recht gut. Als 
IDE hier auch Eclipse.

Autor: Ernstmeiner (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ralf schrieb:
> So richtig schlau werde ich aus dem Angebot an IDEs/Toolchains nun
> nicht, ob ich mit einer einzigen Umgebung alles oben genannte
> abgeklappert bekomme :/ Wäre halt schön wenn es sowas gibt.

Warum so unflexibel?

> Schön wär's wie gesagt wenn's da etwas für Windows gibt. Wobei Linux in
> einer VM laufen zu lassen nach meiner Definition nicht "für Windows"
> bedeutet ;P
> Allerdings: wenn die strikte Empfehlung "mach's auf nem Linux-Host"
> lautet, dann beuge ich mich der Empfehlung

Ich empfehle dir, auf eine IDE zu verzichten und einfach den Editor 
deines Geschmacks, make, g++ und gdb zu verwenden. Alles kein Hexenwerk, 
sich in eine IDE einzuarbeiten dauert länger und man hat am Ende 
meistens weniger Vorteile davon. Du kannst die Verbindung zum RPi im 
Makefile über SSH machen, etwa so wie hier -> 
https://stackoverflow.com/questions/37286273/using-ssh-and-rsync-in-makefile
Und ja, besonders rate ich dir, Windows zu knicken. Warum sollte das 
unter Windows besser gegen als unter Linux?

> Ich schrecke nur ein wenig vor dem
> "manuellen" Konsolenhandling, Scripting, etc. zurück, welches man unter
> Linux wohl braucht, um den Kernel, etc. zu bauen (Achtung: Halbwissen!!!
> Diesen Eindruck habe ich halt gewonnen, als ich mir Tutorials zum
> Kernelbau etc. angeschaut habe).

> - Treiberentwicklung

LOL! Als wenn jemand ein Haus bauen will, aber nicht weiß, wie die 
Schachtel mit den Nägeln auf geht.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ralf schrieb:
> - Treiberentwicklung => nicht über Libs für GPIO, I2C, SPI o.ä. als
> Userprogramm, sondern das was für Linux echte Treiber sind (unter Linux
> heisst das glaube ich Modul bzw. fest in den Kernel implementiert, ist
> das so korrekt?)

Das geht nur unter Linux selbst. Den Kernel komplett zu kompilieren 
dürfte auf dem R-PI ziemlich lange dauern. Daher sollte man das auf 
einem leistungsfähigen PC mit Linux machen. Dazu gehört dann natürlich 
ggf. das Arbeiten mit DTB's, Bootloader, Images usw. An deiner Stelle 
würde ich auch auf dem PC mit Linux arbeiten - so lernst du den Umgang 
mit Linux, der Shell usw. Aus irgendwelchen Gründen läuft der GCC & Co 
unter Linux auch schneller...

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend zusammen,

vielen Dank für die zahlreichen Tipps und Hinweise.

@Zeno:
Die von dir erwähnten Programme schaue ich mir gerne an.

> Kernel und Module würde ich direkt auf dem Raspi compilieren. Ebenso
> Programme die nur als Sourcecode erhältlich sind. So ist sicher
> gestellt, das alle Abhängigkeiten passen. Man kann es natürlich auch per
> Crosscompiler auf dem PC machen, aber dann muß man sicher stellen, das
> die Sourcen/Headerfiles zum auf dem Pi laufenden Kernel passen. Wenn man
> da mehrere Pi mit verschiedenen Kernelversionen hat verliert man da
> schnell den Überblick.
Das muss ich mir genauer anschauen, wenn ich dann mal soweit bin :)
Ein Nebenziel wäre es ja dann, wenn ich bspw. einen Treiber für 
was-auch-immer schreibe, diesen dann auch zur Verfügung zu stellen.
Die Idee hier wär gewesen, jeweils die Module zur Verfügung zu stellen. 
Aber was du geschrieben hast, zeigt mir ein Problem auf, an das ich gar 
nicht gedacht hab: wenn das jeweils exakt zum jeweiligen Kernel passen 
muss (was eigentlich logisch ist), dann müsste ich in dem Fall jedesmal 
neue Module raushauen... Ich schätze, den Sourcecode zur Verfügung zu 
stellen, wär da die praktikablere Variante :)

@900ss:
> Kernel habe ich unter Linux auf dem PC mit Crosstoolchain gebaut. Ich
> hatte keine Lust Stunden zu warten wenn das auf dem Raspi gebaut wird.
Wie lange dauert ein Kernelbuild denn im Schnitt auf dem Pi und 
verglichen auf dem PC?

> Heute würde ich wohl alles auf unter Linux auf einem PC
> crosscompilieren. Ich hatte das Linux in einer VM und damit geht es auch
> recht gut. Als IDE hier auch Eclipse.
Ja, ich komme mehr und mehr zu dem Schluss, das ebenfalls so zu machen 
:)

@ Ernstmeiner:
> Warum so unflexibel?
Ist es denn wirklich unflexibel, wenn man alles mit einem Werkzeug 
erschlagen kann? ;)
Wobei man da sicherlich sagen muss, dass es nix bringt, wenn man ein 
Tool hat, das alles kann, aber nix richtig.

> Ich empfehle dir, auf eine IDE zu verzichten und einfach den Editor
> deines Geschmacks, make, g++ und gdb zu verwenden. Alles kein Hexenwerk,
> sich in eine IDE einzuarbeiten dauert länger und man hat am Ende
> meistens weniger Vorteile davon. Du kannst die Verbindung zum RPi im
> Makefile über SSH machen, etwa so wie hier ->
> https://stackoverflow.com/questions/37286273/using-ssh-and-rsync-in-makefile
Schaue ich mir an, danke.

> Und ja, besonders rate ich dir, Windows zu knicken. Warum sollte das
> unter Windows besser gegen als unter Linux?
Wo hab ich gesagt dass es besser geht? :D
Es ging mir eher darum, mich nicht erst in eine völlig neue OS-Umgebung 
einlernen zu müssen, bevor ich ans eigentliche Programmieren kann. Du 
weisst schon, Strom sucht sich auch den Weg des geringsten Widerstands 
(wobei er ihn im Gegensatz zum Menschen immer gleich beim ersten Versuch 
findet grins )

> LOL! Als wenn jemand ein Haus bauen will, aber nicht weiß, wie die
> Schachtel mit den Nägeln auf geht.
Auf das hab ich gewartet - Botschaft angekommen :)

@erlkoenig:
> Das geht nur unter Linux selbst. Den Kernel komplett zu kompilieren
> dürfte auf dem R-PI ziemlich lange dauern. Daher sollte man das auf
> einem leistungsfähigen PC mit Linux machen. Dazu gehört dann natürlich
> ggf. das Arbeiten mit DTB's, Bootloader, Images usw. An deiner Stelle
> würde ich auch auf dem PC mit Linux arbeiten - so lernst du den Umgang
> mit Linux, der Shell usw. Aus irgendwelchen Gründen läuft der GCC & Co
> unter Linux auch schneller...
Ja, ich glaub's langsam auch, dass das so geschickter sein wird.

Hab mir nun auch ein paar Bücher zum Pi gekauft. Und das "Linux Device 
Drivers" PDF hab ich auch schon gefunden - da werd ich die erste Zeit 
wohl vorerst mal mit Lesen verbringen :)

Nochmals danke an alle und Grüße

Ralf

Autor: 900ss D. (900ss)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Ernstmeiner schrieb:
> LOL! Als wenn jemand ein Haus bauen will, aber nicht weiß, wie die
> Schachtel mit den Nägeln auf geht.

Du Dummschwätzer. Jeder fängt mal an. Ach nein, du hast das alles gleich 
gekonnt ohne Lernphase.

Autor: Ernstmeiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf schrieb:
> @ Ernstmeiner:
>> Warum so unflexibel?
> Ist es denn wirklich unflexibel, wenn man alles mit einem Werkzeug
> erschlagen kann? ;)

Du hast Recht, das war zu verallgemeinert. Im Endeffekt ist es eine 
Frage der Philosophie. Klar hat eine Software, die alles erschlägt 
Vorzüge. Man kann es aber auch so machen, dass man sich für jede 
Teilaufgabe das tool rauspickt, dass die Aufgabe (möglicherweise nach 
persönlichem Ermessen) am besten erfüllt. Ich fände es z.B. schlecht, 
wenn ich mit jeder IDE, die ich benutzen wollte, mich an einen neuen 
Editor gewöhnen müsstem, weil der eben meist mit eingeflochten ist. Ich 
habe einen Lieblingseditor, der ist eine Konstante. Ich ändere an meiner 
toolchain nur das, was angepasst werden muss, nicht jedesmal alles, nur 
weil ich eine neue Sprache ö.ä. verwende.

>> Und ja, besonders rate ich dir, Windows zu knicken. Warum sollte das
>> unter Windows besser gegen als unter Linux?
> Wo hab ich gesagt dass es besser geht? :D

Nirgends. Ich will meinen Rat auch gar nicht inhaltlich begründen. Kann 
ich möglicherweise gar nicht, ich habe Windows noch nie benutzt. Ich 
wollte nur, dass du dir Linux nicht entgehen lässt. :)

> Es ging mir eher darum, mich nicht erst in eine völlig neue OS-Umgebung
> einlernen zu müssen, bevor ich ans eigentliche Programmieren kann. Du
> weisst schon, Strom sucht sich auch den Weg des geringsten Widerstands
> (wobei er ihn im Gegensatz zum Menschen immer gleich beim ersten Versuch
> findet grins )

Wie gesagt: Sich in komplexe IDEs einzuarbeiten ist oft auch nicht 
einfach.

>> LOL! Als wenn jemand ein Haus bauen will, aber nicht weiß, wie die
>> Schachtel mit den Nägeln auf geht.
> Auf das hab ich gewartet - Botschaft angekommen :)

Wer weiß, wenn du die Schachtel erstmal aufbekommen hast, kann auch 
alles ganz schnell gehen. Vielleicht bist du ja ein Überflieger.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>  Ich schrecke nur ein wenig vor dem
> "manuellen" Konsolenhandling, Scripting, etc. zurück, welches man unter
> Linux wohl braucht, um den Kernel, etc. zu bauen (Achtung: Halbwissen!!!

Das gilt so allgemein als Vorteil der einem das Leben erleichtert. .-)

Natuerlich wird das erstmalige uebersetzen eines neuen Kernels direkt 
auf dem Raspberry viele Stunden dauern, aber das laeuft ja nur einmal. 
Danach wird auch da nur der von dir geaenderte Source uebersetzt. Und 
wenn man Module nutzt dann sowieso.

Allerdings frag ich mich was fuer Treiber du gerade fuer den Raspberry 
programmieren willst. Die Besonderheit eines solchen Systems ist es ja 
das dort Linux bereits Treiber fuer jede vorhandene Hardware mitbringt. 
Sinnvoll waere sowas also nur wenn man vorhandene Treiber verbessern 
will. Naja, ausser vielleicht du baust komplett neue USB-Hardware.

Olaf

Autor: Parlim :D (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Raspberry Pi 4 compilert den Kernel in einer Stunde.

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wobei sich natürlich die Frage stellt warum der TO als Anfänger einen 
Kernel compilieren will.

Autor: Koernel Panik (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> warum der TO als Anfänger einen Kernel compilieren will.

Richtig. Wenn dann etwas was auch einen realen Nutzen hat.

Z.B. einen xvnc mit xrandr-Extensions.
Aber wetten das er das nicht schafft?

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ernstmeiner:
>> Wo hab ich gesagt dass es besser geht? :D
> Nirgends. Ich will meinen Rat auch gar nicht inhaltlich begründen. Kann
> ich möglicherweise gar nicht, ich habe Windows noch nie benutzt.
Ah, also das exakte Gegenstück zu mir ^^

>Ich wollte nur, dass du dir Linux nicht entgehen lässt. :)
Ich schau's mir gerne an. Aber fühl dich deswegen nicht dazu genötigt, 
dir Windows anzutun :D Wenn du's bis jetzt nicht gebraucht hast, dann 
sei froh :)

>>> LOL! Als wenn jemand ein Haus bauen will, aber nicht weiß, wie die
>>> Schachtel mit den Nägeln auf geht.
>> Auf das hab ich gewartet - Botschaft angekommen :)
> Wer weiß, wenn du die Schachtel erstmal aufbekommen hast, kann auch
> alles ganz schnell gehen. Vielleicht bist du ja ein Überflieger.
Na, Überflieger eher nicht, aber zumindest lernfähig :)

@Olaf:
>> Ich schrecke nur ein wenig vor dem "manuellen" Konsolenhandling,
>> Scripting, etc. zurück, welches man unter Linux wohl braucht, um den
>> Kernel, etc. zu bauen (Achtung: Halbwissen!!!)
> Das gilt so allgemein als Vorteil der einem das Leben erleichtert. .-)
Ach so :)

> Natuerlich wird das erstmalige uebersetzen eines neuen Kernels direkt
> auf dem Raspberry viele Stunden dauern, aber das laeuft ja nur einmal.
> Danach wird auch da nur der von dir geaenderte Source uebersetzt. Und
> wenn man Module nutzt dann sowieso.
Ah, okay. Ich dachte, dass das ganze Spiel dann jeweils ganz von vorn 
beginnt. D.h. der zeitintensivste Teil ist das Übersetzen, nicht das 
Linken, korrekt?

> Allerdings frag ich mich was fuer Treiber du gerade fuer den Raspberry
> programmieren willst. Die Besonderheit eines solchen Systems ist es ja
> das dort Linux bereits Treiber fuer jede vorhandene Hardware mitbringt.
> Sinnvoll waere sowas also nur wenn man vorhandene Treiber verbessern
> will. Naja, ausser vielleicht du baust komplett neue USB-Hardware.
Auf nem PC vielleicht, aber der PI verleitet doch dazu, auch mal einen 
Chip ranzupappen, der nicht unterstützt wird. Ideal, um unter die 
Linux-Motorhaube zu gucken und den Maschinenraum näher kennen zu lernen.

@Parlim:
> Der Raspberry Pi 4 compilert den Kernel in einer Stunde.
Danke für die Info.

@bitverdreher:
> Wobei sich natürlich die Frage stellt warum der TO als Anfänger einen
> Kernel compilieren will.
Berechtigte Frage. Einfach damit ich's mal gemacht hab - und um sehen, 
wie sich Änderungen auswirken. Wobei ich meine Liste im Eingangspost 
nach meiner Auffassung chronologisch so geschrieben habe, dass ich Stück 
für Stück tiefer einsteige. D.h. dann aber auch: Kernel zuletzt - und da 
sollte ich zumindest kein blutiger Anfänger mehr sein.

Ralf

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ralf schrieb:
> Auf nem PC vielleicht, aber der PI verleitet doch dazu, auch mal einen
> Chip ranzupappen, der nicht unterstützt wird. Ideal, um unter die
> Linux-Motorhaube zu gucken und den Maschinenraum näher kennen zu lernen.

Das einzige was Du an einem Raspi anpappen kannst, geht über die PIOs. 
Dazu braucht man keine Kernelmodule um solcherlei HW zu integrieren.
Gerade beim Raspi sehe ich wenig Sinn darin, einen Kernel zu 
kompilieren, da die HW Auswahl hier ja doch recht übersichtlich ist und 
man davon ausgehen kann, daß für diese HW der Kernel schon optimiert 
wurde.

Aber um auf die Ausgangsfrage zurückzukommen:
Ich entwickle alles direkt auf dem Raspi selbst via ssh oder VNC. So 
langsam ist der auch wieder nicht, als da man sich die Arbeit mit dem 
Crosskompilieren machen müßte.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Auf nem PC vielleicht, aber der PI verleitet doch dazu, auch mal einen
> Chip ranzupappen, der nicht unterstützt wird. Ideal, um unter die
> Linux-Motorhaube zu gucken und den Maschinenraum näher kennen zu lernen.

Wo willst du den denn was dran pappen? Du hast auf dem Header nur 
Portleitungen, RS232, SPI und I2C und dafuer gibt es bereits einen 
Treiber. Du kannst Bausteine dort direkt ansprechen. Nagut, zumindest am 
SPI-Treiber gibt es so einiges zu verbessern.
BTW: Die IO-Ports des Raspberrys sind nicht die staerksten. Bei wilden 
Kabelaufbauen, noch dazu mit langen Leitungen und hohen Frequenzen, kann 
ich nur empfehlen direkt am Pi einen Bustreiber zu verbauen.

> Berechtigte Frage. Einfach damit ich's mal gemacht hab - und um sehen,
> wie sich Änderungen auswirken. Wobei ich meine Liste im Eingangspost

Da spricht ja auch grundsaetzlich nichts gegen. Es gab Zeiten da hat 
jeder Linuxuser wenigstens einmal im Monat einen neuen Kernel erzeugt. 
Erst in den letzten 10Jahren sind die durchschnittlichen Faehigkeiten 
eines Linuxuser auf ein Niveau abgesunken wo sowas fuer meisten nicht 
mehr in Betracht kommt. .-)

Olaf

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Auf nem PC vielleicht, aber der PI verleitet doch dazu, auch mal einen
>> Chip ranzupappen, der nicht unterstützt wird. Ideal, um unter die
>> Linux-Motorhaube zu gucken und den Maschinenraum näher kennen zu lernen.
@bitverdreher:
> Das einzige was Du an einem Raspi anpappen kannst, geht über die PIOs.
> Dazu braucht man keine Kernelmodule um solcherlei HW zu integrieren.
> Gerade beim Raspi sehe ich wenig Sinn darin, einen Kernel zu
> kompilieren, da die HW Auswahl hier ja doch recht übersichtlich ist und
> man davon ausgehen kann, daß für diese HW der Kernel schon optimiert
> wurde.
Warum? RTC: I2C/SPI. ADC/DAC: I2C/SPI. GPIO-Expander: I2C/SPI. PMIC: 
I2C/SPI. LCD: I2C/SPI.
Mir ist schon klar, dass es eine Schnittstelle aus dem Userspace auf 
I2C/SPI gibt, aber ich dachte, solche Sachen wie ein RTC-Treiber sind im 
Kernel direkt integriert. Oder versteh ich das zugrunde liegende Konzept 
nicht? Sind in Linux "nur" die Schnittstellen im Kernel und alles 
weitere wie RTC, etc. sind im Userspace?
Wie holt denn dann ein Kernel die Uhrzeit?

@Olaf:
> Wo willst du den denn was dran pappen? Du hast auf dem Header nur
> Portleitungen, RS232, SPI und I2C und dafuer gibt es bereits einen
> Treiber. Du kannst Bausteine dort direkt ansprechen. Nagut, zumindest am
> SPI-Treiber gibt es so einiges zu verbessern.
Siehe oben - ich kann mir einfach nicht vorstellen, dass im Kernel 
Treibertechnisch nach der physikalischen Schnittstelle Schluss ist.

> BTW: Die IO-Ports des Raspberrys sind nicht die staerksten. Bei wilden
> Kabelaufbauen, noch dazu mit langen Leitungen und hohen Frequenzen, kann
> ich nur empfehlen direkt am Pi einen Bustreiber zu verbauen.
Danke für den Hinweis :)

Ralf

Autor: Bauform B. (bauformb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf schrieb:
> ich dachte, solche Sachen wie ein RTC-Treiber sind im
> Kernel direkt integriert.

Sind sie, und zwar ein paar Dutzend:
$ /srv/eagle/ns82-14$ ll /srv/kernel/linux-4.12-amd/drivers/rtc/*.c | wc -l
157
Dein Hauptproblem wäre, einen RTC-Chip zu finden, der noch nicht 
eingebaut ist ;)

Wie lange der RPi braucht, um einen Kernel zu kompilieren, hängt stark 
davon ab, wie gut (= klein) du ihn konfigurierst. Ich weiß jetzt nicht, 
wie sehr die Raspbian-config schon abgespeckt ist, aber normalerweise 
werden Module für alle bekannte USB-Hardware, für ISDN, DECNET usw. 
gebaut. Da kannst du sparen.

Die nächste Bremse ist die Platte, SD-Karte kannst du vergessen. Ich 
kopiere die kompletten Kernelquellen in ein tmpfs, übersetze dort und 
kopiere das Ergebnis zurück. Allerdings braucht das wahrscheinlich 2GB 
RAM.

Auf jeden Fall lohnt sich "make -jx", wobei x ungefähr gleich der Anzahl 
der CPUs sein sollte.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es wäre vermutlich alles einfacher wenn Du Dir Linux auf dem PC zulegst, 
notfalls erst mal als virtuelle Maschine. Du wirst ohnehin nicht umhin 
kommen dich tiefer mit diesem System zu beschäftigen und es wird vieles 
leichter wenn das Entwicklungssystem die gleichen Werkzeuge hat und 
genauso "tickt" wie die Zielplattform.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Bauform B.
>> ich dachte, solche Sachen wie ein RTC-Treiber sind im
>> Kernel direkt integriert.
> Sind sie, und zwar ein paar Dutzend:$ /srv/eagle/ns82-14$ ll
> /srv/kernel/linux-4.12-amd/drivers/rtc/*.c | wc -l
> 157
> Dein Hauptproblem wäre, einen RTC-Chip zu finden, der noch nicht
> eingebaut ist ;)
Verflixt, daran hab ich nicht gedacht :D Aber es gibt sicherlich genug 
I2C-Tierchen in meiner Bastelkiste, die der PI nicht kennt.
Es geht ja drum, nen Treiber zu basteln, erstmal "egal" für was.

> Wie lange der RPi braucht, um einen Kernel zu kompilieren, hängt stark
> davon ab, wie gut (= klein) du ihn konfigurierst. Ich weiß jetzt nicht,
> wie sehr die Raspbian-config schon abgespeckt ist, aber normalerweise
> werden Module für alle bekannte USB-Hardware, für ISDN, DECNET usw.
> gebaut. Da kannst du sparen.
Okay, das seh ich ja dann, wenn ich mich "groß" genug für nen Kernel 
fühle. Da gibt's wahrscheinlich ja auch entsprechende 
Konfigurationstools.

> Die nächste Bremse ist die Platte, SD-Karte kannst du vergessen. Ich
> kopiere die kompletten Kernelquellen in ein tmpfs, übersetze dort und
> kopiere das Ergebnis zurück. Allerdings braucht das wahrscheinlich 2GB
> RAM.
tmpfs = temporäres Filesystem im RAM?

> Auf jeden Fall lohnt sich "make -jx", wobei x ungefähr gleich der Anzahl
> der CPUs sein sollte.
Das hatte ich gelesen, der Faktor soll glaub ich 1.5 x CPU sein.

@prof7bit:
> Es wäre vermutlich alles einfacher wenn Du Dir Linux auf dem PC zulegst,
> notfalls erst mal als virtuelle Maschine. Du wirst ohnehin nicht umhin
> kommen dich tiefer mit diesem System zu beschäftigen und es wird vieles
> leichter wenn das Entwicklungssystem die gleichen Werkzeuge hat und
> genauso "tickt" wie die Zielplattform.
Ja, die Entscheidung Linux zu nehmen ist ja mittlerweile auch gefallen, 
passt.

Ralf

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die einfachste Variante einen Kernel cross-plattform zu bauen die ich 
bislang mit eigenen Augen gesehen und selbst erleben durfte war ein auf 
Docker basierendes Build-Script (Das war damals für einen Rock64 aber es 
gibt wohl das gleiche in grün auch für Raspi). Letztendlich musste man 
nur die Quellen auspacken, in das Verzeichnis gehen und das Script 
starten.

Da war ein Dockerfile dabei das on-the-fly einen Container mit einer 
kompletten Build-Umgebung mit cross-toolchain und allem nötigen 
Brimborium hochgezogen hat und dann innerhalb dieses Containers den 
Build durchgeführt hat. IMHO übrigens eine der absoluten 
Killer-Anwendungen für Docker.

Sowas würd ich auf jeden Fall mal ins Auge fassen bzw. näher anschauen 
um die Mechanismen zu verstehen, das kannst Du auch für eigene Projekte 
verwenden so daß das Projekt im Handumdrehen auf praktisch jedem 
beliebigen Linuxrechner (eventuell sogar auf Windows mit 
Linux-Subsystem) gebaut werden kann ohne vorher eine halbe Tonne an 
Abhängigkeiten zu installieren, weil es einfach on-the-fly nach 
Anweisungen im mitgelieferten Dockerfile einen Container mit genau 
definierter und absolut reproduzierbarer Umgebung hochzieht und den 
Build dann da drinnen ausführt!

: Bearbeitet durch User
Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
> Natuerlich wird das erstmalige uebersetzen eines neuen Kernels direkt
> auf dem Raspberry viele Stunden dauern, aber das laeuft ja nur einmal.

Das würde ich mir nicht antun...

Olaf schrieb:
> Danach wird auch da nur der von dir geaenderte Source uebersetzt. Und
> wenn man Module nutzt dann sowieso.

Es sei denn man verändert die Konfiguration grundlegend o.ä.

Das würde ich mir nicht antun. Auf einem leistungsfähigen PC dauert das 
unter einer Minute.

Bernd K. schrieb:
> ohne vorher eine halbe Tonne an
> Abhängigkeiten zu installieren

Das ist auch nicht soo wild... Das kann man ja mit einem Kommando 
installieren:
sudo apt-get install build-essential gcc-arm-linux-gnueabihf pkg-config flex bison perl bc openssl

Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es schon Windows sein muss, würde ich die WSL1 nehmen. Die hat auch 
binfmt-misc support. Dann machst du folgendes (in der WSL):

 1) Qemu user static installieren "apt-get install qemu-user-static"
 2) "sudo /etc/init.d/binfmt-support start"
 3) Mit rsync in der WSL vom raspi alle Dateien des rootfs kopieren. 
Aber nicht nach /mnt/*/, bei den "Windowsnativen" Verzeichnissen gehen 
Dateien mit Sonderzeichen kaputt, btw. können nicht erstellt werden.
 4) Kopiere das qemu static binary ins image. Ich weis grad nicht, ob 
man arm oder armeb braucht, also einfach mal alle rein schieben "cp 
/usr/bin/qemu-{arm,armeb,aarch64}-static /pfad/zu/raspi-rootfs/usr/bin/"
 5) Jetzt kannst du mit "chroot /pfad/zu/raspi-rootfs/" in dem lokalen 
raspian rootfs arbeiten.

Dinge, die man da dann noch verbessern könnte, wären:
 1) /dev /sys und /proc und /mnt mounten (ein bind mount geht auch). Auf 
meinen linux systemen mounte ich "/" als rshared und "/" auf 
/anderes-rootfs/rootfs/ als rbind,rshared, und symlinke /dev, /proc, 
/sys, /home, /mnt, /media, /etc/passwd*, /etc/groups*, /etc/shadow* 
/etc/subuid* und /etc/subgid*, aber die rshared optuion gibt's in der 
wsl1 wohl noch nicht. Auf meinem rechner hab ich noch ein script, das 
mit sudo und chroot ein paar tricks macht, so das ich einfach als 
normaler user schreiben kann "uch raspi nano bla.txt", und es chrootet 
automatich ins richtige rootfs, wechselt zum richtigen Benutzer und 
Verzeichnis welches dem im hauptsystem entspricht, und führt dann das 
Program aus. Eventuell kann ich die Skripts heute abend mal posten, 
obwohl, eventuell gibts dafür schon bessere lösungen.

 2) Statt 1 könnte man aus dem raspi rootfs gleich eine eigene WSL 
machen. Das ist aber ein ziemlicher krampf, das zum laufen zu bekommen, 
weil man die binfmt-misc registriert bekommen muss befor die WSL irgend 
ein Programm startet.

 3) Für grafische Anwendungen braucht man noch einen X server. Ich 
verwende den von cygwin.
   3.1) 
https://x.cygwin.com/docs/ug/setup.html#setup-cygwin-x-installing
   3.2) Eine verknüpfung anlegen mit folgendem Inhalt (kann man auch in 
den autostart packen, erzeugt aber leider ein nerfiges Fenster (das man 
aber gefahrlos schliessen kann)):
C:\cygwin64\bin\sh.exe -l -i -c "HOME=/cygdrive/c/Users/benutzername/ startxwin -- -listen tcp -audit 0 &"
   3.3) In der WSL (und dem chroot) eine verknüpfung erstellen:
ln -s /mnt/c/Users/benutzername/.Xauthority ~/.Xauthority"

Fürs entwickeln mit IDE am besten eine IDE in der WSL/dem chroot darin 
installieren. Du kannst die auch auf windows installieren, wenn du, 
verknüpfungen für das direkte Starten das gewünschte gcc/make/etc. 
anlegst (kann etwas aufwendig sein, bis das läuft), und diese dann in 
deiner windows IDE einträgst. Ist aber weniger konfortabel, finde ich. 
Das X11 von Cygwin hat aber auch kleinere macken, das Kopieren geht 
nicht immer so wie es soll.

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.