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
Diese Toolchain hab ich unter Windows genutzt. Funktioniert sehr gut. Als IDE hab ich Eclipse genutzt. https://gnutoolchains.com/raspberry/
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.
@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
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.
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.
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.
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...
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
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.
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.
> 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
Der Raspberry Pi 4 compilert den Kernel in einer Stunde.
Wobei sich natürlich die Frage stellt warum der TO als Anfänger einen Kernel compilieren will.
> 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?
@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
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.
> 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
>> 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
Ralf schrieb: > ich dachte, solche Sachen wie ein RTC-Treiber sind im > Kernel direkt integriert. Sind sie, und zwar ein paar Dutzend:
1 | $ /srv/eagle/ns82-14$ ll /srv/kernel/linux-4.12-amd/drivers/rtc/*.c | wc -l |
2 | 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.
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.
@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
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
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:
1 | sudo apt-get install build-essential gcc-arm-linux-gnueabihf pkg-config flex bison perl bc openssl |
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)):1 | 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:
1 | 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.
Harri schrieb: > die Entwicklung läuft über > mehrere SSH-Sitzungen. Ich mounte ein Verzeichnis am PC mit dem Raspberry, so kann ich am PC das Programm editieren (Notepad++) und über SSH den Code kompilieren, starten und testen.
Olaf schrieb: > Es gab Zeiten da hat > jeder Linuxuser wenigstens einmal im Monat einen neuen Kernel erzeugt. Damals wurde Linux ja auch nur von denen genutzt, die keine Freundin oder Familie hatten und nie aus dem Haus kamen. Die brauchten halt eine Beschäftigung.
Ralf schrieb: > - Entwicklung generell für Raspbian > - erste einfache Programme in [...] für die Shell entwickeln (das > Äquivalent zu Windows Konsolenanwendungen) > - später auch Programme mit GUI Lazarus / Freepascal, mit Crosscompiler für Linux ARM. Läuft auf dem Windows PC, kann Konsolenprogramme, Programme mit GUI kompilieren für den Raspi. Die schiebst Du dann übers Netzwerk rüber, machst sie ausführbar und kannst sie starten. Da brauchst Du keine Toolchain für und musst nicht mit makefiles rummachen. Achja, und natürlich Zugriff auf den Raspi per VNC. Auch ein Raspi kann GUI, der muss nicht in der Konsole laufen. Das ist nur was für Leute, die im letzten Jahrhundert hängengeblieben sind oder sich unbedingt Schmerzen zufügen wollen. Soll ja so Leute geben. Da kann man dann in der GUI auch gleich noch seine config-Files mit Geany editieren, abgelegte Daten überprüfen, sich Daten grafisch anzeigen lassen... Wir haben 2019, und auch das ist schon halb rum.
> anzeigen lassen... Wir haben 2019, und auch das ist schon halb rum.
Es war schon vor >20Jahren unter Unix problemlos moeglich ein Programm
auf einer Kiste zu starten das seine Grafik auf einem anderen Rechner
aufgemacht hat. Bloss Windowsbubis kannten das nicht. .-) Das geht nicht
erst seit 2019. Die Nutzung eines Terminals ist nur bis heute ueblich
geblieben weil das fuer bestimmte Anwendungen leistungfaehiger ist.
Ein Beispiel? Keiner wuerde heute noch auf die Idee kommen etwas zu
programmieren ohne einen Debugger nutzen zu koennen. Und es ist total
cool und einfach das aus einer IDE zu machen. Wenn du dir aber mal den
Funktionsumfang des gdb anschaust dann wirst du sehen das du bei richtig
komplexen, selten Bugs doch lieber die Kommandozeile nutzt.
Olaf
Olaf schrieb: > Es war schon vor >20Jahren unter Unix problemlos moeglich ein Programm > auf einer Kiste zu starten das seine Grafik auf einem anderen Rechner > aufgemacht hat. Nein? Doch! Ohhh! Genauso lief das im Computerpool der FH. Und? Was ändert das dran, dass es auch 20 Jahre noch später Leute gibt, die meinen man müsse zwingend mit Kommandozeile und ssh rumeiern? Der Witz vom Raspi ist ja, dass ich ihn durchlaufen lasse. Den Linux- oder Windows-PC nicht. Und da kann ich jederzeit eine VNC Sitzung zum Raspi aufmachen und habe jedesmal den Bildschirm so vor mir, wie ich ihn verlassen habe. Wenn ich das mit ssh mache, kann ich mir zwar ein Programm mit X11 "rüberholen", aber das startet jedesmal neu. Ich würde aber gern die Datenerfassung über mehrere Tage laufen haben. Und nicht jedesmal mehrere Programme wieder aufmachen. Du kannst ja gern auf diesen Komfort verzichten, ich will nicht wieder nach 1995 zurück, computertechnisch.
Karl K. schrieb: > Was ändert das dran, dass > es auch 20 Jahre noch später Leute gibt, die meinen man müsse zwingend > mit Kommandozeile und ssh rumeiern? Weil das meiste was man bei der Fernwartung eines Rechners machen will auf der Kommandozeile erheblich schneller und einfacher geht vielleicht?
Ralf schrieb: > 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). Du willst Treiber schreiben und Kerne kompilieren hast aber Angst vor der Konsole? Pass deine Ziele deinen Fähigkeiten an oder erweitere deine Fähigkeiten!
Karl K. schrieb: > Freepascal Eingangspost gelesen? Er will C/C++. > musst nicht mit makefiles rummachen. Warum sollte man nicht? Es ist simpel, man lernt es einmal und kann es danach Sprachenunabhängig jederzeit verwenden, anstatt sich in x IDEs einzuarbeiten. > Achja, und natürlich Zugriff auf den Raspi per VNC. Auch ein Raspi kann > GUI, der muss nicht in der Konsole laufen. Eingangspost gelesen? Er will auch Kommandozeile. Er wird seine Gründe haben. > Das ist nur was für Leute, > die im letzten Jahrhundert hängengeblieben sind oder sich unbedingt > Schmerzen zufügen wollen. Soll ja so Leute geben. Wie bekommt man von Kommandozeilen Schmerzen? Wie benutzt du deine GUI-Programme automatisiert in Scripts? Wie reichst du bei Bedarf den output eines deiner GUI-Programme an ein anderes Programm weiter? Wozu braucht ein Treiber eine GUI? > Da kann man dann in der GUI auch gleich noch seine config-Files mit > Geany editieren, abgelegte Daten überprüfen, sich Daten grafisch > anzeigen lassen > Lazarus Und warum empfiehlst du ihm einen Texteditor und eine IDE? Da merkt man sofort, dass du unbedingt loswerden willst, was DU benutzt und fast platzt, wenn du das nicht kannst. > muss nicht in der Konsole laufen. Das ist nur was für Leute, > die im letzten Jahrhundert hängengeblieben sind Aber Freepascal empfehlen. Schon klar.
:
Bearbeitet durch User
Md M. schrieb: > Eingangspost gelesen? Er will C/C++. Vielleicht kennt er nur nichts anders. Tellerrand. Md M. schrieb: > Er will auch Kommandozeile. Hab ich geschrieben: Kann Freepascal. Md M. schrieb: > Wie benutzt du deine > GUI-Programme automatisiert in Scripts? Wieso sollte ich eine grafische Messwertausgabe in Scripts automatisieren? Tellerrand. Ich programmiere halt und schreibe nicht nur so paar Scripts um mal bißchen rumzuscripten.
Bernd K. schrieb: > 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. Ich habe nach der Anleitung, die Zeno verlinkt hatte, mit wenig Problemen (Java..) die Cross-Compilig-IDE unter Windows 10 installiert, weil mir "sudo nano ..." mit seiner Bedienbarkeit wie zu Apple ][-Zeiten auf den Nerv ging. Die Anleitung war sehr hilfreich (etwas Basiswissen und Experimentierfreudigkeit sollte aber vorhanden sein). GEKU schrieb: > Ich mounte ein Verzeichnis am PC mit dem Raspberry, so kann ich am PC > das Programm editieren (Notepad++) und über SSH den Code kompilieren, > starten und testen. Nach etwas googlen habe ich dann auch den SSH-Tunnel eingerichtet bekommen, und kann so auf die Commandline des Raspberry's zugreifen. Die Programme kopiere ich momentan per "scp" aufs Raspberry. Das würde ich gerne noch luxuriöser gestalten, so dass die Kompilate gleich auf dem Raspberry im passenden Verzeichnis landen. Ansonsten bin ich begeistert.
STK500-Besitzer schrieb: > Das würde ich gerne noch luxuriöser gestalten, so dass die Kompilate > gleich auf dem Raspberry im passenden Verzeichnis landen. Filezilla. Witzig ist: Kopiere ich die Datei vom Raspi aus per SMB, muss ich jedesmal die "Ausführbar" Rechte neu setzen. Nervt. Kopiere ich die Datei von Windows aus per ftp, muss ich das nur beim ersten Mal machen. Bei erneuten Überschreiben bleiben die gesetzten Rechte erhalten.
Karl K. schrieb: > Witzig ist: Kopiere ich die Datei vom Raspi aus per SMB, muss ich > jedesmal die "Ausführbar" Rechte neu setzen. Nervt. > > Kopiere ich die Datei von Windows aus per ftp, muss ich das nur beim > ersten Mal machen. Bei erneuten Überschreiben bleiben die gesetzten > Rechte erhalten. Bei scp bleiben die Rechte erhalten. Die musste ich nur ein Mal setzen. Ich habe mit eine Batch-Datei gebastelt, die nur noch nach dem Passwort des Raspberry fragt.
Wh schrieb: > Alles zu finden unter windowsondevices.com Wenn man Windows auf dem Raspberry Pi laufen lassen will.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.