Hallo liebe Gemeinde, gestern habe ich zum allerersten Mal einen µC programmiert (für das, was ich einprogrammiert habe, braucht man eigentlich keinen µC ;) ), bin also recht frisch auf dem Gebiet. Ist es in der IDE möglich im Debuggerbetrieb den Status eines normalen Inputpins "live" abzufragen? Ausprobiert habe ich folgendes: Debugger starten, "Run to Cursor" -> Pin ist 0. Jetzt Schalter betätigen, "Run to Cursor" -> Pin ist auf 1. Gibt es die Möglichkeit diesen Ablauf zu automatisieren? Der Pin wird in einer Schleife abgefragt. Ich möchte lediglich am PC erfahren, ob der Schalter betätigt ist oder nicht, ohne dabei jedes Mal auf "Run to Cursor" zu klicken. Danke für eure Hilfe! Grüße Reggie Achso, die Hard- und Software: - STM32F4 Discovery MB997 C-01 - Rowley CrossStudio for ARM 3.5 (Cross Workbench)
Nicht, daß ich Dich hier mit meinen 'eigenartigen' Vorschlägen zutexten möchte, aber diese Eigenschaft bieten Keil und IAR, soweit mir bekannt ist. Bei IAR heißt die Funktion 'live watch' und ist eine sehr feine Sache. Gerade um einen neuen µC kennenzulernen, kann ich es nur empfehlen. Mit dem IAR-Kickstart sind 32 kB Code kostenlos möglich. Das reicht für Deine Belange voll aus. Darüber hinaus ist IAR aber 'böse', da sehr hochpreisig. Darum findest Du hier nur spärliche Hilfestellung.
m.n. schrieb: > 'eigenartigen' Vorschlägen Ohne Worte^^ m.n. schrieb: > Bei IAR heißt die Funktion 'live watch' und ist eine sehr feine > Sache. Ah OK, vielleicht weiß ja jemand anders noch ob es das bei CrossStudio auch gibt. Ich google auf jeden Fall mal weiter. m.n. schrieb: > Darüber hinaus ist IAR aber 'böse', da sehr hochpreisig. Darum findest > Du hier nur spärliche Hilfestellung. Joar, ich hab ein nettes "Studenten"-Angebot von denen bekommen. Allerdings frage ich mich, wieviele Studenten Millionäre sind -.- Danke trotzdem.
Geht auch mit segger jlink edu, nennt sich dort JScope. Der edu kostet 50 EUR und ist jeden Pfennig davon wert, und noch viel mehr. Wenn Deine IDE mit dem Jlink umgehen kann (sehr wahrscheinlich) dann kauf ihn Dir.
Bernd K. schrieb: > Wenn Deine IDE mit dem Jlink umgehen kann (sehr wahrscheinlich) dann > kauf ihn Dir. Klar, kann CrossWorks mit dem J-Link umgehen. Oder einfach direkt SES nehmen ;-), https://segger.com/embedded-studio.html
Wird bestimmt auch mit dem ST-Link des Discoveryboards gehen. Schau mal im Watchfenster nach. Zum einen müßtest Du hier eintragen, was du sehen willst. Beim normalen debuggen solltest du definitiv die Veränderung sehen. Dann gibt es im Watchfenster eine "Zeit" Einstellung. Statt 'Never' mal 'each second' ausprobieren. Ich nutze es selbst nicht. Aber vielleicht klappts.
Steffen R. schrieb: > Wird bestimmt auch mit dem ST-Link des Discoveryboards gehen. > > Schau mal im Watchfenster nach. > Zum einen müßtest Du hier eintragen, was du sehen willst. Beim normalen > debuggen solltest du definitiv die Veränderung sehen. > > Dann gibt es im Watchfenster eine "Zeit" Einstellung. Statt 'Never' mal > 'each second' ausprobieren. > > Ich nutze es selbst nicht. Aber vielleicht klappts. Klar wird das gehen, die Frage ist nur ob und wie bei CrossWorks :) Sprichst du jetzt von CrossWorks? Ich sehe da kein "Watch Fenster" (vllt bin ich auch einfach nur blind).
Reginald L. schrieb: > Klar wird das gehen, die Frage ist nur ob und wie bei CrossWorks :) Meine Idee habe ich beschrieben. > Sprichst du jetzt von CrossWorks? ja konkret: Crossworks for ARM 3.3 für Windows Die Fenster sollten aber in anderen Versionen/OS gleich sein. > Ich sehe da kein "Watch Fenster" (vllt > bin ich auch einfach nur blind). Die Menüstruktur könnte von der Version abhängen. Debug->Other Windows->Watch->Watch1 Möglicherweise ist es schon offen. Dann such nach einem Symbol (Viereck mit Brille). Unter Windows haben sie statt der üblichen Tabs Symbole zum umschalten der Fenster.
Aaaaah ja jetzt, habs, danke. Wenn ich ihm hier aber beispielsweise "GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0)" reinschmeiße, geht nix mehr. Was hab ich jetzt wieder verbockt :)
Das Watchfenster ist zum Beobachten von Variablen. Funktionen kann man da nicht ausführen. D.h. Du must im Programm den Wert des Pins einer Variablen zuweisen und diese dann beobachten. Wie hast Du in deinem Eingangspost gesehen, dass dein Pin 0 oder 1 ist?
In meinem Code ist der, oben genannten, Funktion die Variable "PA0"
zugewiesen. Wenn ich auf "Build and Debug" gehe, ist der Code ja
pausiert. Die Variable "PA0" habe ich dann in das "Memory" Fenster
übergeben ("Locate Memory"). Dort sehe ich dann ob der Pin 1 oder 0 ist.
Aber eben nur, wenn ich "Run to Cursor" klicke. Wenn ich stattdessen den
Code laufen lasse (mit "Continue", großer grüner Button), aktualisiert
er das Fenster "Memory" nicht mehr und im Watch Fenster steht "PA0
symbol not found".
Und wieder hab ich was verbockt :)
Reginald L. schrieb: > Wenn ich stattdessen den > Code laufen lasse (mit "Continue", großer grüner Button), aktualisiert > er das Fenster "Memory" nicht mehr Das "normale" Debuggen geht alles über den GDB (oder vergleichbare Debugger), der macht das während der µC angehalten ist. Das Auslesen von Speicher ohne den µC anzuhalten erfordert einerseits das Vorhandensein gewisser Hardware im µC die das überhaupt erst möglich macht (z.B. Core Sight®™, ist zum Glück in jedem ARM-Cortex enthalten) und andererseits die Unterstützung selbigens auf Seiten des Debuggers (GDB kann das AFAIK (noch) nicht) und womöglich (weiss nicht genau) muss das auch noch bei der Konstruktion des JTAG-Adapters oder dessen Firmware berücksichtigt werden. In Deinem Fall hast Du einen STM32 (der kann das) und auf dem Demo-Board einen On-Board JTAG-Adapter (STLinkv2.1, kann der das auch? Vielleicht.) und auf dem PC ist GDB als Debugger (der kann das nicht). DU musst also mindestens auf PC-Softwareseite (IDE, Debugger) was haben das das unterstützt. Die IMHO momentan mit Abstand kostengünstigste und universellst verwendbare Lösung (die mit jedem Cortex unter dieser Sonne und mit jeder IDE und sogar unter Linux reibungslos funktioniert) wäre also: * Klemm den integrierten ST-Link am Discovery-Board ab (Jumper?) * Schliesse einen J-Link an die JTAG- (oder SWD-) Schnittstelle an * Konfiguriere Deine IDE entsprechend * Verwende Deine IDE für die üblichen Dinge wie gewohnt * Verwende die Segger-Software für die Spezialfunktionen (J-Scope live trace) Wenn Du Glück hast findest Du manchmal Demo-Boards von (anderen) Herstellern die ohne zusätzliche Hardware mit der Segger Software kompatibel sind, dann musst Du Dir nichtmal einen J-Link kaufen. Ein Beispiel sind zum Beispiel die FRDM-Boards von Freescale (Kinetis MKLxx µC), da kann man auf den dortigen on-board Adapter eine alternative Firmware (offiziell von Segger) draufladen und dann verhält sich das Ding exakt so wie ein vollwertiger J-Link und die ganze Segger-Software (kostenlos) inklusive J-Scope funktioniert damit. Dann hast Du für 15$ ein komplettes System und kannst sofort loslegen.
Puh, ganz schön starker Tobak. Das muss ich mir erst einmal zu Gemüte führen. Vielen lieben Dank für die ausführliche Erklärung!
Bernd K. schrieb: > * Klemm den integrierten ST-Link am Discovery-Board ab (Jumper?) Wozu das denn? IAR liefert die 'live watch' Funktion über ST-Link, sodaß an der Grundbeschaltung garnichts geändert werden muß. Man muß es einfach nur machen ...
Reginald L. schrieb: > Puh, ganz schön starker Tobak. Das muss ich mir erst einmal zu > Gemüte > führen. > > Vielen lieben Dank für die ausführliche Erklärung! Es gibt noch ne einfachere Variante die ich gerne verwende: Parallel zu der Firmware für das Device das ich entwickle schreib ich mir auch gleich eine kleine ganz spezielle simpel(!) gestrickte PC-Software die zum Beispiel Daten von der Seriellen entgegen nimmt und in geeigneter Weise anzeigt und manchmal auch in der Lage ist etwas zurückzuschicken so daß Du sogar damit interagieren kannst. Zum Beispiel hab ich momentan was in der Mache das alle 0.25 Sekunden 3 Messwerte und einen binären Zustand von meiner Schaltung über die serielle Schnittstelle entgegen nimmt und hübsch plottet und anzeigt (und als csv speichert) und gleichzeitig erlaubt mit 2 Schiebereglern mit der Maus 2 Werte zu ändern und über die UART zurückschickt um das ganze Ding in Echtzeit interaktiv zu parametrieren. Im einfachsten Fall fängst Du damit an einfach nur die fraglichen Daten an der UART auszugeben und die am PC mit einem fertigen Terminalprogramm oder dergleichen anzuzeigen oder mitzuschreiben, das hilft schon sehr viel und das geht sogar meist schon dann wenn aus irgenwelchen Gründen überhaupt kein Debugger vorhanden ist oder angeschlossen werden kann.
Bernd K. schrieb: > Parallel zu der Firmware für das Device das ich entwickle schreib ich > mir auch gleich eine kleine ganz spezielle simpel(!) gestrickte > PC-Software die zum Beispiel Daten von der Seriellen entgegen nimmt und > in geeigneter Weise anzeigt und manchmal auch in der Lage ist etwas > zurückzuschicken so daß Du sogar damit interagieren kannst. Das habe ich mir auch schon überlegt. Ich hab schon Probleme damit, den richtigen Zeichensatz mit USB VCP zu verschicken ;) Wie gesagt, C und µC ist ganz neu für mich. Habe bisher nur mit MatLab programmiert.
Reginald L. schrieb: > Die Variable "PA0" habe ich dann in das "Memory" Fenster > übergeben ("Locate Memory"). Das ist der umständlichste Weg, den du nehmen konntest. Zum Ansehen von Variablen sind - Watch View - Autos - Globals - Locals usw. gedacht. Je nachdem, welcher Art die variablen sind die du sehen willst. Thema J-Link: Ja, die Teile sind gut. Doch bevor du nun anfängst dir Dinge zu kaufen, solltest Du schauen, was dir das vorhandene Equipment bietet. Damit meine ich noch nicht einmal so sehr das ST-Link. Sondern eher die IDE. Ohne dieses Wissen wirst du auch mit dem J-Link nicht glücklich. JScope habe ich bisher nicht genutzt. Den meisten mir bekannten Zusatztools ist jedoch gemeinsam, dass man diese nicht gleichzeitig mit dem Debugger nutzen kann. Ist normalerweise auch nicht Sinn der Sachen. Mann will ja entweder Debuggen oder frei Laufen lassen. Reginald L. schrieb: > gestern habe ich zum allerersten Mal einen µC programmiert Arbeite Dich erstmal in die "einfachen" Dinge ein. Bernd K. schrieb: > Das Auslesen von > Speicher ohne den µC anzuhalten erfordert einerseits das Vorhandensein > gewisser Hardware im µC die das überhaupt erst möglich macht > [...] Ich hatte auch schon Systeme, das wird das System für einen kurzen Augenblick angehalten, während die Variablen ausgelesen werden. Dumm, wenn dabei auch der Takt der Peripherie mit anhält. Wenn man es weiß, kann man häufig auch was dagegen tun. Aber hierfür muß kan wissen, wie das jeweilige System diese Funktionalität umsetzt. Daher auch meine obige Aussage, dass es nicht zu den einfachen Dingen gehört. Aber um dir die "Angst" zu nehmen. Die Cortex-M sind mit ihrer SWD Schnittstelle super zum Live-View geeignet.
Steffen R. schrieb: > Aber um dir die "Angst" zu nehmen. Die Cortex-M sind mit ihrer SWD > Schnittstelle super zum Live-View geeignet. So ist es! Damit kann man die Software bestens im Zielsystem entwickeln.
Steffen R. schrieb: > JScope habe ich bisher nicht genutzt. Den meisten mir bekannten > Zusatztools ist jedoch gemeinsam, dass man diese nicht gleichzeitig mit > dem Debugger nutzen kann Stört sich nicht gegenseitig. Als Debugger nutze ich den JLink GDB-server unter Eclipse-GNU-ARM und JScope läuft als separate Anwendung. Ich kann während J-Scope noch läuft nach herzenslust debuggen oder auch laufenlassen, die Debug-Session abbrechen und eine neue Session mit einem neuen Binary beginnen und sofern sich das Layout der globalen Variablen nicht geändert hat läuft JScope nehebher einfach so weiter. Über den selben Adapter. Gleichzeitig. Nur die Benutzeroberfläche von JScope selbst ist noch etwas lieblos und gedankenlos zusammengestoppelt, unvollständig und bei intensivem Gebrauch etwas nervtötend (vielleicht gibt sich ja noch irgendwann) aber es erfüllt den Zweck aus technischer Hinsicht 1a. Und übrigens der Clou daran ist ja gerade dass eben entgegen Deiner Vermutung (kurz anhalten) tatsächlich nichts angehalten wird, kein einziger Taktzyklus geht verloren, es wird wirklich dank entsprechender Hardwareunterstützung im ARM-Cortex parallel zur Ausführung auf den Speicher zugegriffen (beim EDU 50 mal pro Sekunde und bei den teuren über 1000 mal) vollkommen ohne irgendwelche Wechselwirkungen und Seiteneffekte. Aber wie gesagt, auch die uralte Kulturtechnik des printf-debugging (entsprechend bei controllern dann eben UART-Debugging) sollte man sich aneignen und pflegen, damit kommt man oft schon sehr weit wenn mal aus irgendwelchen Gründen gar kein Debugger zur Verfügung steht (z.B. Zu debuggendes Gerät ist irgendwo eingebaut, nur noch die Bootloader-Schnittstelle ist zugänglich, etc).
So, nachdem ich heute den ganzen Tag damit verbrauchte habe, mein PC-System komplett neu aufzusetzen (neuen Mainboard), bin ich jetzt wieder im Reich der Bits und Bytes :) Leider habe ich die eMail mit dem Code für den "Probiermonat" von Crossworks gelöscht, bin gerade also dabei in CooCox einzusteigen. Mal schauen wie sich das in ein paar Tagen macht. Kaufen möchte ich mir Crossworks noch nicht, erst muss ich schauen was mir am besten zusagt. Zum Debuggen: Blicke da nicht so ganz durch, mit JScope, Autos und und und. Die Möglichkeit mit printf funktioniert in CooCox? Wird mir das in einem extra Fenster ausgegeben?
> Leider habe ich die eMail mit dem Code für den "Probiermonat" von > Crossworks gelöscht, bin gerade also dabei in CooCox einzusteigen. Mal > schauen wie sich das in ein paar Tagen macht. Kaufen möchte ich mir > Crossworks noch nicht, erst muss ich schauen was mir am besten zusagt. Zwischen CooCox und Crossworks liegen Welten. CooCox ist vermutlich besser für Einsteiger geeignet. Bietet aber auch viel weniger Einstellmöglichkeiten. > Zum Debuggen: Blicke da nicht so ganz durch, mit JScope, Autos und und > und. Autos -> lokale Variable
Und weiter gehts: Mit Coocox kam ich gar nicht klar, habs nicht mal hinbekommen, den "Test Build" zu starten. Habe die BetaV2 benutzt. Glücklicherweise, habe ich nochmal einen Evaluationscode von Crossworks bekommen :> so bin ich erstmal wieder hier. Mit der Terminalausgabe komme ich absolut nicht klar, der Guide von CrossWorks funktioniert bei mir nicht (was wohl eher an mir liegt :) ). Habe auch schon wieder ein neues (Verständnis-) Problem, habe dazu einen neuen Thread eröffnet.
Bin jetzt wieder erstmal zur EMBlocks IDE gesprungen, da ich Probleme mit IRQs habe und dort schon eine dementsprechende Startup-File vorhanden ist. Ich habe es auch endlich geschafft, mit printf zu debuggen, aller Anfang ist schwer :P
Thread beobachten
Seitenaufteilung abschaltenBitte 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.