Keine Lust mehr auf OpenOCD, alternativen?

MisterX schrieb:

> ich bin auf der Suche nach einen ordentlichen Programmierer/Debugger für
> ARM (ARM7, ARM9, Cortex) Mikrocontroller. Im Moment besitze ich einen
> mit OpenOCD.

Es geht um die Hardware? Einen "Debugger...mit OpenOCD" gibt es nicht. 
Es gibt Adapter/Probes, die von OpenOCD unterstützt werden.

> Allerdings verbringe ich mehr Zeit mit der Konfiguration
> als mit dem Programmieren an sich.
> Am liebsten wäre mir etwas was ich nur einstecken brauche und es
> funktioniert.
> Was die Bindung an eine IDE angeht bin ich flexibel, am liebsten wäre
> mir aber Eclipse.
> Was könnt ihr empfehlen?

Für "Eclipse" - gemeint ist wohl die Debug-Perspective - benötigt man 
einen gdb-Server oder ein gerätespezifisches Plugin vom Hersteller. 
OpenOCD ist ein gdb-Server, der das Hardware-Interface ansprechen kann. 
Es gibt auch andere Software mit ähnlichen Funktionen z.B. von 
Codesourcery, Segger nicht mit ähnliche breitem Hardware-Support. 
Weiteres u.a Abatron BDI2000, Segger JLINK (oder OEM wie SAM-ICE) mit 
dem gdb-Server von Segger, Ronetix Peedi und wahrscheinlich noch viele 
viele mehr.

Wenn man eine andere Debug-"IDE" will, schaut man am besten einfach 
nach, welche Hardware vom Hersteller unterstützt werden. Übliche 
Verdächtige: ARM/Keil, IAR, Rowley, Codered, Hitex u.v.a.m. MDKARM ist 
bei vorhandenem Etat sicher keine schlechte Wahl. Dazu ein von uVision 
unterstütztes Hardware-Interface. Über Rowley Crossworks wird Gutes 
berichtet aber dazu muss jemand anderes etwas schreiben. Ist ja nicht 
so, als wäre diese Frage hier nicht schon einige Mal aufgekommen, man 
könnte auch die Forensuche bemühen.


Karlheinz schrieb:

> Für den Hobbybereich (bis 16 KByte) EVA-Version von ARM/Keil + SAM-ICE.

Es sind wohl inzwischen wie bei IAR EWARM-KS 32kByte. Die Eval-Version 
darf nur für Nicht-kommerzielles genutzt werden. Man müsste noch klären, 
ob das SAM-ICE auch mit nicht-AT91 Controllern unter uVision ohne 
größere Einschränkungen funktioniert.


Gast schrieb:

> Die aktuellste Version von OpenOCD wurde von Hyperaktiven Open Source
> Programmierern kaputtprogrammiert.

Was ist mit "aktuellste Version" gemeint? 0.2.0? Was ist denn "kaputt"? 
Man kann den "Hyperaktiven" vorwerfen, dass sie im Laufe der Entwicklung 
einige Befehle rausgeworfen haben aber was sonst noch? Die 
Funktionalität ist geblieben und wurde stellenweise ordentlich 
erweitert, man muss nur  in der Dokumentation und den OpenOCD und den 
Konfigurationsdateien der target-library lesen. Bisher selbst noch 
nichts gefunden, was ersatzlos entfernt wurde.

> Man kann sie m.E. nicht verwenden.

Wofür? Oder wofür jetzt nicht mehr?

In diesem und anderen Foren/Mailinglisten liest man im Zusammenhang mit 
OpenOCD oft "nothing works/geht alles nicht", "viel zu kompliziert", 
"use the old version" u.s.w. ohne dass irgendwelche Informationen dazu 
gegeben werden, anhand derer man das eigentliche Problem woanders suchen 
könnte als vor dem Bildschirm.

> Wenn Du eine (sehr alte) Version runterlädst, ist die Wahrscheinlichkeit
> höher, daß Du damit gut arbeiten kannst.

Ich arbeite derzeit ohne größere Schwierigkeiten mit einer (aktuellen?) 
aus dem SVN-Code von irgendwann Anfang September selbst kompilierten 
OpenOCD-Version mit AT91SAM7-Controllern, STM32-Controllern und einem 
FT2232H-basierten Adapter(JTAGkey2/FTDI-Treiber) unter 
XP+Eclispe+CDT+CDT-HW-Debug. Die Konfiguration und Nutzung wurde z.B. 
durch die Vorlagen in der Target-Library, dem TCL-Scripting-Support und 
dem erweiterten gdb-Interface "m.E." deutlich einfacher, immer noch 
nicht simpel aber auch nicht komplizierter als bei alten Versionen (SVN 
<700irgendwas).

Statt Pauschalitäten und Niedermachen von Entwicklern, die einiges an 
Know-How in ein für jedermann kostenloses Produkt stecken, wären 
konkrete Fehlerbeschreibungen und Wünsche an die 
OpenOCD-Developer-Mailingliste (Adresse in der Dokumentation) sicher der 
bessere Weg, um Einfluss auf die Entwicklung zu nehmen.

MisterX schrieb:

> Am liebsten wäre mir etwas was ich nur einstecken brauche und es
> funktioniert.

Behalte das Interface und verwende es mit Rowley. Es gibt davon eine 
Demo, und in nichtkommerziellem Einsatz ist es zudem recht günstig.

Da Rowley auf GCC basiert kann man resultierende Programme auch ohne 
Portierungsaufwand mit Codesourcery übersetzen, nur das Makefile muss 
man dann nachreichen.