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?
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.
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.
@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.
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.
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...
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.
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.
Ä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.
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.