Hallo. Schreibe (eher selten) Programm´chen für Atmel-uC, über AtmelStudio. Meist Steuerungskram. Nun möchte ich immer mal wieder Prog-Teile, einzelne Macros, Funktionen kurz testen ohne direkt zu debuggen/compilieren. Hierzu würde ich gerne eine Software/Bildschirm-Lösung, z.B. CodeBlocks nutzen. Aber, wie können Eingänge wie Taster, Schalter, Schwellwerte, oder variabler Spannungseingang am Bildschirm simuliert werden? Aktuell beschäftige ich mit der Überwachung von Hi/Lo-Flanken an Tasteingang.
"Vorm Compilieren", wie du in der Überschrift geschrieben hast, geht es nicht. Du kannst aber "Build and Run" (Atmel Studio 4) drücken und dann Schritt für Schritt den Code durchgehen. Eingänge können vor Ausführung des Schritts auf HIGH oder LOW gesetzt werden, dazu gibt es unter View-Toolbars den IO-View. Auch kannst du dir den Inhalt deiner Variablen anzeigen lassen indem du sie mit Add Watch ins Watch-Fenster bringst. Hilfreich ist es ggf., die Übersetzung ohne Optimierung durchzuführen, sonst sind manche von dir definierte Variablen gar nicht vorhanden: wegoptimiert.
HildeK schrieb: > "Vorm Compilieren", wie du in der Überschrift geschrieben hast, > geht es > nicht. > Du kannst aber "Build and Run" (Atmel Studio 4) drücken und dann Schritt > für Schritt den Code durchgehen. Eingänge können vor Ausführung des > Schritts auf HIGH oder LOW gesetzt werden, dazu gibt es unter > View-Toolbars den IO-View. > Auch kannst du dir den Inhalt deiner Variablen anzeigen lassen indem du > sie mit Add Watch ins Watch-Fenster bringst. > > Hilfreich ist es ggf., die Übersetzung ohne Optimierung durchzuführen, > sonst sind manche von dir definierte Variablen gar nicht vorhanden: > wegoptimiert. Da habe ich mich missverständlich ausgedrückt - meinte; mitten im Programmschreiben, mal eben einige Programmcode-zeilen heraus nehmen, um diese separat zu überprüfen. Dein Vorschlag zielt darauf ab, das gesamte Programm einmal zu simulieren.
__Son´s B. schrieb: > Dein Vorschlag zielt darauf ab, das gesamte Programm einmal zu > simulieren. Richtig. Sollte es was anderes geben, so kenne ich es nicht.
__Son´s B. schrieb: > Nun möchte ich immer mal wieder Prog-Teile, einzelne Macros, Funktionen > kurz testen ohne direkt zu debuggen/compilieren. __Son´s B. schrieb: > Da habe ich mich missverständlich ausgedrückt - meinte; mitten im > Programmschreiben, mal eben einige Programmcode-zeilen heraus nehmen, um > diese separat zu überprüfen. Das ist etwas, was man unter Unit-Tests zusammenfassen kann. Bei Embedded-Projekten führt man dazu den Code auf dem Host-Rechner (also deinem PC wo das Programm geschrieben wird) aus. Die Durchführbarkeit solcher Unit-Tests setzt eine einigermaßen saubere SW-Architektur voraus. Es ist dabei wichtig HW-Zugriffe mit Treiber-Funktionen zu abstrahieren. Die Funktionale SW-Komponenten können auf dem Host-Rechner dann sogenannte Mocks/Stubs aufrufen statt der eigentlichen Treiberfunktionen (Registerzugriffe per #defines könnten im Notfall auch durch in der Testumgebung definierte Variablen mit dem gleichen Namen gemockt werden). Dabei ist es ebenfalls hilfreich, die Module in einzelne C-Dateien zu packen. Denn Mocks/Stubs können nicht innerhalb der gleichen C-Datei generiert werden. Eine Umgebung für Unittests wäre beispielsweise Ceedling. Muss man sich etwas reinfuchsen und dritte Tools installieren. Compiliert wird dein Testcode mit dem GCC. Es gibt natürlich noch andere Tools, such dir was aus. Ein empfehlenswertes Buch ist "Test Driven Development for Embedded C" von Grenning. Es beschreibt u.a. die Methodik der Unittest und wie man die Schichten trennt.
Unit schrieb: > Ein empfehlenswertes Buch ist "Test Driven Development for Embedded C" > von Grenning. Es beschreibt u.a. die Methodik der Unittest und wie man > die Schichten trennt. Danke @Unit, klingt super professionell, für mich liegt diese Umsetzungs-Latte aber viel zu hoch! Habe schon so viele Baustellen, bei zu wenig Zeit - brauche keine Weitere ;-) Hatte tatsächlich an ganz kleine Lösungen gedacht, in dem ich ein Programmteil, zB. kaskadierte Verschachtelungen bei dem ich mir wärend des Tippens unsicher bin, ob ich da jeh wieder sauber raus komme, kopiere und in eine anderes Editor packe, um am Bildschirm die Ausgänge zu prüfen - MAL EBEN... Ok wenn das nicht SOOOO LEICHT möglich ist, werde ich mir andere Strategieen ausdenken.
:
Bearbeitet durch User
Jetzt mal mit Kanonen auf Spatzen schießen ... Dass was du vor hast geht recht gut mit einer S-Function in Simulink. Mach ich in der Firma auch ab und zu mal. In der S-Funktion braucht man "nur" den betreffenden Code-Schnipsel einfügen und die EIn/Ausgänge gemäß der Datentypen definieren. An die S-FUnktion kann dann ein Simulinkmodel mit Schalter, Multiplxer, Signalbuilder, Scope etc. gehängt werden und es ist sogar möglich Daten zu loggen. Doch leider ist Simulink keine billige Lösung und für Privat ggf. too much. Habe aber gelesen das im kostenlosen Scilab sowas wohl auch möglich sein soll. Frag sich nur wie gut.
Kurz gesagt- Investier deine zeit besser ins lernen eines guten und effizienten Programmierstils, dann musst du dir zb keine gedanken über tiefe verschachtelungen machen. Du möchtest mit viel aufwand trial und error für einfache probleme machen. Besser den aufwand in lernen investieren, und trial und error bei echten Problemen.. ?
Ps- echte probleme kann man meist sowieso nicht im simulator lösen, da timing eine rolle spielt..
Bitte 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.