Hallo Zusammen,
ich hoffe, dass mir einer von euch bei meiner Frage weiterhelfen kann!
Ich möchte mit einem MSP430F2012 (Entwicklungsumgebung IAR V3.42A,
USB-Stick EZ430, spy-by-wire) eine Akkuladeschaltung realisieren.
Dabei werden Akkuspannung, Akkutemperatur und Ladestrom zu bestimmten
Zeiten gemessen (mit ADC10). Eine Zeitbasis ist auch vorhanden.
In der Entwicklungsphase möchte ich nun überprüfen, ob das alles auch so
funktioniert, wie ich mir das vorstelle und dazu will ich mir die
gemessenen Größen mit Timestamp protokollieren. D.h. also der MSP läuft
im Debug-Modus, lädt den Akku wie programmiert und z.B. jede Sekunde
werden die gemessenen Größen in ein File gespeichert, ohne den
Programmablauf zu unterbrechen.
Eine Möglichkeit wäre natürlich, die Daten seriell an den PC zu
übertragen und dort zu speichern. Bedeutet allerdings eine Software-UART
im MSP zu implementieren, die ich nachher nicht mehr brauche.
Jetzt die Frage:
Ist es mit den C-Spy Macros auch möglich, alle erfassten Daten in ein
File speichern zu lassen? Hat das schonmal jemand gemacht, ist das ein
erfolgversprechender Ansatz? Wenn ja, ist der Macro-Overhead erträglich,
d.h. kommt der MSP seiner eigentlichen Aufgabe noch nach oder bremst das
zu sehr ein?
Danke schonmal im Voraus,
Stefan
>Wo sind denn die C-Spy Macros dokumentiert?
Im IAR Embedded Workbench User-Guide... letztes Kapitel.
>Bist du sicher, daß die auch mit dem EZ430 funktionieren?
Nö, sicher bin ich nicht.
Aber ich denke schon, da die Macros eine Sache von C-Spy sind
und C-Spy wiederum mit'm EZ430 kann.
Ich habe gestern ein wenig rumprobiert
(allerdings mit dem Parallelport FET).
Wenn man einen Log-Breakpoint setzt, dann erfüllt dieser
meine Anforderungen... außer, daß sich die Daten nicht in ein
File speichern lassen, sondern im Debug-Window geloggt werden.
Zudem ist das ganze recht langsam.
Eine andere Möglichkeit ist eben ein Macro zu verwenden und es
mit einem 'normalen' Code-Breakpoint zu verbinden. Hat aber
den Nachteil, daß der Programmablauf am Breakpoint natürlich anhält
und nicht wie gewünscht weiterläuft! Außer es gibt ein Macro, welches
den Ablauf automatisch wieder aufnimmt?!
Hmm, da bislang anscheinend keiner sowas gemacht hat, muss ich wohl
selbst den schwere Weg gehen... :-)
@Michael
Danke für den Tip, aber IAR wäre als Gesprächspartner sicher besser
geeignet. Hab mir auch die App-Notes von denen angeschaut, aber so recht
schlau bin ich daraus auch noch nicht geworden.
Ne ne, es gibt von TI eine DLL zur Ansteuerung des Debuggers. Diese
bindet IAR auch nur ein.
Vor kurzem ist auch eine Application Note von TI veröffentlicht worden,
wo der Zugriff auf die DLL beschrieben ist. Du müsstest also von deinem
Programm auf diese DLL entsprechend zugreifen und hast dann alle
Funktionen, die du im Debug-Modus auch hast.
Aha... nee die App-Note kenne ich nicht.
Aber wenn da die DLL beschrieben ist, würde das ja bedeuten, dass ich
einen eigenen Debugger schreiben müsste, um die DLL zu benutzen.
Ich wollte aber eigentlich einfach C-SPY nutzen :-)
Vielleicht habe ich mich oben auch nur zu kompliziert ausgedrückt?
Was ich eigentlich möchte ist folgendes:
Im µC (MSP430F2012) werden z.B. jede Sekunde mehrere ADC10 Kanäle
gesampled. Diese Werte benutze ich, um die Akkuladung zu steuern.
Da die Werte ja aber schon im µC vorliegen, möchte ich diese auch gleich
auf den PC übertragen, um sie dort besser analysieren zu können!
Allerdings ist dies nur in der Entwicklungsphase notwendig. Später läuft
das Ding autark vor sich hin!
Ich dachte jetzt nur, es gäbe vielleicht eine 'einfache' Lösung, an
diese Werte zu kommen...
Okay. Mit dem C-SPY ist es glaube ich nicht möglich, dass zu
automatisieren.
Du müsstest dir ja keinen vollständigen Debugger schreiben. Im Prinzip
reicht es ja, wenn du zunächst dir an eine bestimmte Adresse einen
Breakpoint setzt, den Controller startest und wartest, bis er auf den
Breakpoint trifft. Dann list du das die Speicheradresse, wo dein Wert
gespeichert ist, aus und speicherst diesen Wert in einer Datei.
Anschließend kannst du den Controller wieder starten und warten.
Sollte eigentlich nicht so umfangreich werden.
> Oh Gott, ich möchte diesen Text korrigieren :-)
Wenn du dich registrierst und einloggst, ist das möglich. Da steht
nämlich für einige Zeit unter deinem Beitrag folgende Linkzeile:
Jaja, ich verstehe schon, was Du meinst :-)
>Im Prinzip reicht es ja, wenn du zunächst dir an eine bestimmte Adresse>einen Breakpoint setzt, den Controller startest und wartest, bis er auf>den Breakpoint trifft.
Genau das kann ich ja in C-Spy machen. Dem Breakpoint wird ein Macro
zugeordnet, welches dann ausgeführt wird (um z.B. Daten in ein File zu
speichern. Dieses Macro existiert auch schon, wie ich mittlerweile
herausgefunden habe: __writeFile oder __fmessage).
Mein Problem ist nur, dass der Breakpoint das µC-Programm unterbricht
und nicht mehr automatisch weiter ausführt.
Außerdem bekomme ich wohl ein Timingproblem, weil der Filezugriff doch
recht lange dauert und in der Zeit der µC gestoppt bleibt.
Ich befürchte, dass ich mir doch eine UART-Schnittstelle in den µC
programmieren muss. Dumm nur, dass der 2012 nun gerade eben 'nur' SPI
und I2C hardwaremäßig unterstützt :-(
Stefan wrote:
> Ich befürchte, dass ich mir doch eine UART-Schnittstelle in den µC> programmieren muss. Dumm nur, dass der 2012 nun gerade eben 'nur' SPI> und I2C hardwaremäßig unterstützt :-(
Wäre zumindest ne sinnvolle Möglichkeit. Und die Software-UART per Timer
gibts doch bei TI als Quellcode. Ist wirklich ziemlich einfach, vor
allem, wenn du nur Senden willst. Ich hab die Soft-UART mit 6MHz SMCLK
mit 57600 betreiben können, ohne Fehler.
Software-UART ist schon klar.
Problem ist nur, dass ich den Timer schon anderweitig in Beschlag
genommen habe und jetzt schauen muss, wie ich da die Ressourcen
vernünftig verteile, ohne Chaos anzurichten :-)
Deshalb wäre eine in HW gegossene UART besser gewesen...
Trotzdem mal Danke an alle!
Hmm... ja könnte ich :-)
Dann könnte ich mir aber auch eine SPI-zu-UART Bridge reinbasteln.
Das ist aber dafür, dass es nur zum Testen gedacht ist, etwas zu
übertrieben, finde ich. Ich probier's dann erst mal in Software.
Stefan wrote:
> Hmm... ja könnte ich :-)> Dann könnte ich mir aber auch eine SPI-zu-UART Bridge reinbasteln.> Das ist aber dafür, dass es nur zum Testen gedacht ist, etwas zu> übertrieben, finde ich. Ich probier's dann erst mal in Software.
Es reicht doch, wenn du den zweiten 2012 auf einem Steckbrett
zusammenstoppelst und zum Test mit deiner Schaltung verbindest.
Schon, aber die Soft-UART muss ich auch dort implementieren.
Falls ich bei 'nur' einem 2012 Ressourcenprobleme bekomme, dann werden
ich's wohl so machen müssen!
Schau'n mer mal, dann seh'n mer schon...
