Umstieg auf Linux
-
Du solltest dich erstmal eine Weile im Nichtschwimmerbecken von Linux aufhalten. Zwei Ziele mit einem Pfeil zu treffen ist nicht moeglich. Der Schritt zur embedded-Plattform war verfrueht.
-
SeppJ schrieb:
Wieso installierst du dir jetzt 10.10? Das ist die denkbar schlechteste Wahl, da es längst nicht mehr unterstützt wird. Nimm das aktuellste oder, falls dir die neue Unity Oberfläche nicht passt, die langzeitunterstützte Version 10.04.
Ich habe zunächst einfach (vielleicht aus Unwissenheit) eine vorhandene Installation als VM aus dem Internet geladen. Sollte aber kein Problem sein, auf die neuere Version oder die LTS-Version umzusteigen.
-
knivil schrieb:
Du solltest dich erstmal eine Weile im Nichtschwimmerbecken von Linux aufhalten. Zwei Ziele mit einem Pfeil zu treffen ist nicht moeglich. Der Schritt zur embedded-Plattform war verfrueht.
Danke, der war gut !
Welche IDE zur Programmierung auf dem PC selbst wäre denn im Hinblick auf das Ziel am geeignetsten, um sich erstmal im Nichtschwimmerbecken zu bewegen ? Es sollte ja eine IDE sein, mit der man später auch einen Cross-Compiler einsetzen kann, oder ?
Wo gibt es Dokumentation, um die Programmier-API von Linux (Threading, etc.) kennenzulernen ?
-
Eclipse soll gut sein. Benutze ich aber nicht. Es reichen makefiles. Fuer Threads gibt es pthread. Ansonsten ist deine Frage zu unkonkret, um hilfreich zu antworten.
-
IDEs gibt es diverse. KDevelop oder Eclipse wären zwei Beispiele, die recht ähnlich zu Visual Studio sind. Eclipse scheint den Vorteil zu haben, dass sehr viele embedded-Platformen mit entsprechenden plugins ausgeliefert werden. Viele Entwickler unter Linux nutzen aber eher andere Lösungen wie Emacs oder vi.
Die Dokumentation unter Linux findet man in den manpages. Einfach
man 2 open
in der Konsole eingeben (IDEs bieten dafür in der Regel eine Integration) und du bekommst eine sehr gute Dokumentation zum Systemaufruf open. Hier findest du die Manpages auch online: http://www.kernel.org/doc/man-pages/index.html. Ansonsten gibt es die glibc-Doku und für Kernel-APIs die Kernel-Doku.Wenn du Bücher suchst:
The Linux Programming Interface | ISBN: 9781593272203UNIX Network Programming | ISBN: 9780131411555
Advanced Programming in the UNIX Environment | ISBN: 9780321525949
btw. Manpages, Compiler etc. musst du bei Ubuntu erst einmal installieren. Dazu benutzt man den Paketmanager und macht keine manuelle Installation! (Anders als zB unter Windows) Siehe Software-Center oder apt-get.
-
knivil schrieb:
Eclipse soll gut sein. Benutze ich aber nicht. Es reichen makefiles. Fuer Threads gibt es pthread. Ansonsten ist deine Frage zu unkonkret, um hilfreich zu antworten.
Im Falle der Verwendung von makefiles: Welche Hilfsmittel gibt es dann für das Debugging ? Das Testen über den Debug-Output kann ja wohl nicht zufriedenstellend sein...
-
rüdiger schrieb:
IDEs gibt es diverse. KDevelop oder Eclipse wären zwei Beispiele, die recht ähnlich zu Visual Studio sind. Eclipse scheint den Vorteil zu haben, dass sehr viele embedded-Platformen mit entsprechenden plugins ausgeliefert werden. Viele Entwickler unter Linux nutzen aber eher andere Lösungen wie Emacs oder vi.
...Danke sehr !
-
osWurm schrieb:
Im Falle der Verwendung von makefiles: Welche Hilfsmittel gibt es dann für das Debugging ? Das Testen über den Debug-Output kann ja wohl nicht zufriedenstellend sein...
Debugging von Makefiles? Da hilft nur die dunkle Magie der Kommandozeilenoption von make. Du solltest dich aber fragen, wieso dein Makefile so komplex ist, dass man einen Debugger braucht...
-
SeppJ schrieb:
osWurm schrieb:
Im Falle der Verwendung von makefiles: Welche Hilfsmittel gibt es dann für das Debugging ? Das Testen über den Debug-Output kann ja wohl nicht zufriedenstellend sein...
Debugging von Makefiles? Da hilft nur die dunkle Magie der Kommandozeilenoption von make. Du solltest dich aber fragen, wieso dein Makefile so komplex ist, dass man einen Debugger braucht...
Nein, das ist wohl ein Missverständnis. Ich meine das Debuggen von den fertig übersetzten und gelinkten Applikationen...
-
Wie wärs mit dem gdb?
-
Cybertec schrieb:
Wie wärs mit dem gdb?
Ja, danke ! Das liest sich schon mal nicht schlecht...
-
gdb ist ein guter Anfang, aber im Embedded-Bereich ist es häufig ziemlich unpraktisch, den ganzen gdb auf der Zielmaschine laufen zu lassen. Üblich ist, soweit ich das überblicke, auf der Zielmaschine einen gdbserver laufen zu lassen, der sich an einen Prozess anhängt, um dann auf der Entwicklungsmaschine den eigentlichen gdb laufen und mit diesem Server sprechen zu lassen. Auf die Art kann man dann auch ohne Probleme nemiver, kdbg, ddd oder sonstige Frontends (da hat wohl jeder sein Lieblingsviech) vorschalten, um sich die Arbeit zu erleichtern.
-
seldon schrieb:
gdb ist ein guter Anfang, aber im Embedded-Bereich ist es häufig ziemlich unpraktisch, den ganzen gdb auf der Zielmaschine laufen zu lassen. Üblich ist, soweit ich das überblicke, auf der Zielmaschine einen gdbserver laufen zu lassen, der sich an einen Prozess anhängt, um dann auf der Entwicklungsmaschine den eigentlichen gdb laufen und mit diesem Server sprechen zu lassen. Auf die Art kann man dann auch ohne Probleme nemiver, kdbg, ddd oder sonstige Frontends (da hat wohl jeder sein Lieblingsviech) vorschalten, um sich die Arbeit zu erleichtern.
Ich denke, dass eine solche Umgebung durchaus für die ersten Applikationen genügen dürfte. Kernel-Debugging per JTAG soll ja hauptsächlich für die Erstellung von BSPs notwendig sein, oder ? Da bildet dann der entsprechende Daemon mit dem JTAG den GDB-Server nach und das Debuggen kann dann auch mit dem gleichen Client ablaufen, wie ich gelesen habe...