Laufeinheitstests von Atmel Studio 6

Question

Ich entwickle gerade ein Embedded C++ Projekt in Atmel Studio 6. Dieses Projekt hat einen ziemlich wichtigen eingebetteten Teil und auch einen bedeutenden Geschäftslogikanteil. Idealerweise würde ich gern einen Komponententest für den Business-Logik-Code durchführen. In der Lage zu sein, diese Tests bequem durchzuführen, würde es wahrscheinlicher machen, dass die Komponententests verwendet werden.

Wenn ich versuche, mit den Boost-Unit-Tests mit dem Standard-Avr-GCC-Compiler zu kompilieren, bekomme ich Fehler, weil verschiedene Header-Dateien nicht gefunden werden können. Ich verstehe, dass diese Header für den verwendeten AVR-Chipsatz nicht implementiert sind, da sie in diesem Kontext zu teuer wären. Diese Header werden jedoch immer nur für Unit-Tests des nicht eingebetteten Teils verwendet und wurden daher in einem eigenen dedizierten Unit-Test-Projekt platziert.

Muss ich einen anderen Compiler einrichten, um die Komponententests zu kompilieren? Ist es möglich, die Komponententests mit einer anderen Compiler-Toolchain auf das standardmäßig installierte avr-gcc zu kompilieren oder muss ich die Komponententests anderswo kompilieren? Gibt es einen einfacheren Weg, dies zu tun?

Answer 1

Wenn ich eingebettete Software baue, schreibe ich manchmal Komponententests über die (hardwareunabhängige) Geschäftslogik und führe sie auf meiner Host-x86-Architektur aus.

ich normalerweise eine Eclipse-CDT (oder Qt Creator) Projekt über den gleichen Quellbaum bauen, den Ordner zugreifen, wo Sie Ihre C++ Logik haben, und es neben dem Unit-Test-Framework und die Testfälle der Compilierung mit gcc, Ausrichtung auf x86-Architektur. Eclipse oder Qt Creator wird die Makefiles für mich behandeln. Sie können Boost oder ein anderes Unit-Testing-Framework hier verwenden; Normalerweise benötige ich nur 50 Codezeilen, die ich selbst zur Verfügung stelle, mit einigen Assert-Funktionen (so können Sie zum Beispiel die gleichen Komponententests in der endgültigen AVR-Architektur verwenden).

Normalerweise stelle ich ant Aufgaben für den Aufbau der eingebetteten Software für AVR, und Bau und Weitergabe der Unit-Tests für x86, so dass ich es leicht mit einem Continuous Integration Panel integrieren kann.

Viel Glück !.

Answer 2

In plattformübergreifenden Projekten ist es üblich, mehrere Werkzeugketten zu verwenden. Probleme beim Aufbau auf einer der Plattformen bedeuten, dass der Code auf einer der Plattformen nicht korrekt portiert wurde (ich bin mir sicher, dass Sie diesen Teil bereits kannten).

Was Sie normalerweise tun, ist in Kompilierzeit Schalter hinzufügen und den problematischen Code neu schreiben. Zum Beispiel verursachen alle Verweise auf die Boost-Bibliothek (auf den Code für Win) Probleme auf dem eingebetteten Ziel. Sie müssen diese also mit kompilierzeitabhängigen, maschinenabhängigen Switches entfernen. Eventuell müssen Sie einige Module neu schreiben, aber aus diesem Grund verwenden Sie keine Bibliotheken von Drittanbietern von Bibliotheken, die nicht in die gewünschte Architektur (wie Boost) im plattformübergreifenden Code portiert wurden.

Da wir Komponententests hier sprechen, können Sie möglicherweise einfach mit dem Drucken einiger Ausgaben in Dateien auf der Plattform und dann ein Windows-basiertes Skript/Programm analysieren und interpretieren die Ergebnisse - diese Strategie gilt für 90% der Komponententests auf eingebetteten Plattformen (es behandelt auch das Problem der Echtzeit, das bei den meisten eingebetteten Projekten auftritt).