4. Umstieg auf Linux

Umstieg auf Linux

  • K

    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.

    0
  • R

    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: 9781593272203

    UNIX 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.

    0
  • O

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

    0
  • O

    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 ! 🙂

    0
  • Mod

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

    0
  • O

    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... 🙄

    0
  • C

    Wie wärs mit dem gdb?

    http://www.gnu.org/software/gdb/

    0
  • O

    Cybertec schrieb:

    Wie wärs mit dem gdb?

    http://www.gnu.org/software/gdb/

    Ja, danke ! Das liest sich schon mal nicht schlecht... 😉

    0
  • ?

    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.

    0
  • O

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

    0
Anmelden zum Antworten