Im Bereich Embedded Software setzen wir so gut wie ausschließlich auf eclipse-basierte Tools. Lange hat es in diesem Bereich deutliche Einschränkungen beim Debugging von Programmen gegeben, aber das ist inzwischen kein Argument mehr, die Überlegenheit von Eclipse als Entwicklungsumgebung gegenüber anderen (proprietären) Umgebungen nicht auszunutzen. Hinzu kommt, dass Eclipse, das maßgeblich von IBM gefördert wurde, einen Standard darstellt, mit dem eine Vielfalt von Projektarten bewältigt werden kann. Zu denken ist auch an eine gute Realisierbarkeit von Embedded Anwendungen einschließlich PC-basierter Simulation der gleichen Anwendung.
Des Weiteren ist git ein wesentliches Werkzeug zur Versionskontrolle bei Software-Projekten, aber auch bei z.B. Dokumentation (Word-Diffs). Git ist ursprünglich aus Unzufriedenheit mit den damaligen Versionskontrollsystemen von Linux Torvalds für die Linux Kernel-Entwicklung entwickelt worden. Inzwischen hat git die Welt der Versionskontrollsysteme wie im Sturm erobert. Besonderes Merkmal ist, dass git verteilt aufgebaut ist. Es gibt nicht den einen Server, und sog. Clients, sondern jeder Teilnehmer in einem git-supported Projekt hat eine vollständige Kopie auf dem Rechner. Dadurch ist die Projekthistorie sofort zugreifbar und vereinfacht das Aktivieren eines bestimmten Standes für z.B. Hotfix-Arbeiten. Weiterhin ist es so, dass jeder Programmierer eine eigene Reihe von commits erstellen, und diesen nachträglich säubern kann, bevor diese commit-Reihe versendet oder zu einem Server hochgeladen wird.
Eine sehr gute Beschreibung eines Workflow für git findet sich hier. Je nach Präferenzen setzen wir auch Mercurial ein, ebenfalls ein verteiltes System, das etwas einfacher in der Handhabung und traditionell etwas Windows-freundlicher ist, und fortlaufende Commit-Nummerierung (für die, die Wert darauf legen) unterstützt.
Ein Wort zur Programmiersprache: Weil der Schwerpunkt Embedded Systeme ist, setzen wir überwiegend C ein. Häufig bildet gcc die Grundlage, wenn auch oft mit optimierten Laufzeitbibliotheken. Auch hier gilt: früher nicht ernst genommen, heute ernstzunehmen. Der Grund: dessen Verwendung in der Linux-Kernelentwicklung. Es sind Erweiterungen in der Sprache eingeführt worden, die die Lesbarkeit des Code verbessern, insbesondere bei sog. board files, die überwiegend aus sog. struct-Initialisierungen bestehen. Bemerkenswert ist, dass solche Erweiterungen inzwischen auch in der C-Normierung Eingang finden.
Ansonsten wird für Rapid Application Development von z.B. Simulationsumgebungen auf dem PC auf die Skriptsprache Tcl/Tk gesetzt. Aus heutiger Sicht nicht wirklich überzeugend, aber Alternativen sind nicht unbedingt besser.