Eclipse: Debugeinstellungen der vorherigen session behalten

[Ja... (Gast)]

Hallo,
ich habe gerade mit MCUXpresso angefangen. Basiert ja auf Eclipse und 
gefällt mir gut. Was mich jetzt aber zunehmend anpestet: Ich starte eine 
Debugsession und stelle mir dort etwas ein, also z.B. zeige mir das 
GPIO-Peripheral, öffne ein Terminal zu localhost:19021 
(Segger_RTT-Terminal), zeige das TIMERC=-Peripheral. Nach Beenden der 
Debugsession, Code ändern und neu compilieren starte ich wieder eine 
neue Debugsession und alles ist weg und ich darf wieder neu das 
GPIO-Peripheral anwählen, ein Terminal öffnen usw...
Das gibt ja garantiert etwas ganz simples, da das ja ein Standardablauf 
ist. Aber ich kann es nicht finden und weiß auch gar nicht, mit was für 
Stichworten ich überhaupt suchen soll. Hat jemand einen kurzen Tip?

[pegel (Gast)]

Bin jetzt nicht ganz sicher, aber ist das nicht so bei:

"Terminate und Relaunch"?

Also Debug nicht komplett beenden, sondern Symbol mit grünem Dreieck und 
rotem Quadrat benutzen.

[Jim M. (turboj)]

Man kann den Segger GDB Server extern manuell starten:

Debug Configuration -> JLink Debugger -> Server startup and port 
selection: (x) manual, Haken bei "Start Server" raus nehmen.

Dann manuell über das Startmenü den JLinkGDBServer starten (und den 
korrekten µC auswählen).

Nun bleibt der GDB Server über Debug Sessions hinweg laufend, und man 
kann das RTT Terminal einfach offen lassen.

[Nein... (Gast)]

@TO: Schon das Richtige gefunden? Dann bitte mitteilen. Sowas suche ich 
eigentlich auch schon lange, aber bei meinen kurzen 
"Programmierabstechern" habe ich aus Zeitgründen immer die von dir 
beschriebene Kröte geschluckt.

@Pegel: Diese Schaltfläche konnte ich jetzt zumindest bei 
Standard-Eclipse nicht finden. Vielleicht ja eine Beigabe von NXP?

@Jim: Die Hauptfrage war ja eigentlich Eclipsespezifisch. Aber der 
RTT-Viewer bzw. das Terminalgefrickel in Eclipse haben mich auch schon 
genervt, weshalb ich bei "längeren" Sessions den RTT-Viewer in einer 
separaten Konsole unter Ubuntu laufen lasse. Der spuckt einfach nur 
Punkte (...) aus, wenn er nichts hat. Sobald was kommt, wird es wieder 
vernünftig angezeigt. Also sowaß wie automatischer reconnect.

[Johannes S. (Gast)]

Das dürften die Perspektiven sein die man ändern kann. Voreingestellt 
ist, das von Code auf Debug umgeschaltet wird, und Debug wird dann 
wieder auf den Default gesetzt. Man kann aber eigene Perspektiven, also 
Fensterlayouts, unter eigenem Namen speichern und rechts oben auswählen.

[Ja... (Gast)]

Danke für den Hinweis, aber das ist leider nicht das, was ich suche. Ich 
habe das Terminalfenster während Debug eingerichtet und das 
SPI0-Peripheral mit Register TXDATCTL konfiguriert und mit Window -> 
Perspective -> Save Perspective As gespeichert. Beim nächsten 
Debugvorgang dann auch diese diese Perspective gewählt: Terminal und 
Peripheral nicht da...

[Til S. (Firma: SEGGER) (til_s)]

Muss es denn Eclipse sein? Alternativ Embedded Studio:
https://www.segger.com/products/development-tools/embedded-studio/

Ist kostenlos für nicht kommerzielle Projekte.

[Ja... (Gast)]

Ja, Eclipse ist schon "gesetzt". Die meisten freien IDE basieren auf 
Eclipse, weshalb die Basis (Philosophie, Bedienung) dann immer gleich 
ist. Im Zweifelfall einen anderen Compiler und/oder Plugin laden und so 
ziemlich alles geht damit (C/C++, Python, C# usw.). Wobei die speziellen 
IDE meist schon besser sind, aber so bleibt man allgemein.

Außerdem basiert das Embedded Studio ja auf Crossworks, und diese 
Gesamtheit war für mich nie auch nur ansatzweise intuitiv. Schon vor 
vielen Jahren bei Rowley nicht.

[Johannes S. (Gast)]

Ja... schrieb:
> war für mich nie auch nur ansatzweise intuitiv.

Hüstel, und Eclipse ist intuitiv :) Also das ist doch eher eine 
Hassliebe die man da aufbaut...
Und so richtig wird das doch nicht mehr weitergepflegt, der Zug fährt in 
Richtung Theia, der Javascript Variante von Eclipse.
Aber MCUXpresso ist gut, wenn man Mbed benutzt kann man in die 
MCUXpresso IDE exportieren.

[Ja... (Gast)]

Ähem, nun ja, da habe ich mich tatsächlich extrem unglücklich 
ausgedrückt ;-)
Eclipse ist natürlich tatsächlich schon eine Ansammlung von, sagen wir 
es freundlich, Codekomponenten. Tatsächlich auch ein Beispiel dafür, daß 
ein modulares Konzept nach langer Zeit nicht mehr gut sein muß...
Wegen Abwärtskompatibilitäten und Java, nun ja.
Mein Grund ist tatsächlich eher "better the devil you know". Und weil es 
so ziemlich die erste IDE war, mit der ich mehr als 20 Zeilen Code 
geschrieben habe. Was mich seinerzeit (und immer noch!) sehr begeistert, 
ist das astyle-Plugin zur Codeformatierung. Gibt es wohl auch schon 
besseres, aber für meine Bedürfnisse absolut simpel und ausreichend 
genug.

Zu Mbed muß ich leider sagen, daß ich "es" (Versionen, Onlinevariante, 
Kommandozeilenvariante, Board vs. MCU-Unterstützung usw.) nach ca. 0,66 
zugegeben sehr lieblosen Anlaufversuchen auch noch nicht so verstanden 
habe. Derzeit (5 Wochen) hantiere ich mit dem LPC845-BRK, und die 
kleineren (M0+) werden leider nicht "direkt" unterstützt.

[Johannes S. (Gast)]

ja, ist etwas kompliziert. Die kleineren µC kann man mittlerweile wieder 
benutzen, leider bis auf den LPC845, der ist zu neu. Und die anderen 
kleinen sind gerade beim Aufräumen in Mbed6 rausgeflogen :( Bzw. kann 
man noch 5.15 nutzen oder die in custom targets übernehmen. Leider nicht 
so Einsteigerfreundlich, aber es geht. Für LPC812 und LPC824 habe ich 
das gemacht, wobei der 812 schon sehr voll wird.