Hallo, ich bin auf der Suche nach einen ordentlichen Programmierer/Debugger für ARM (ARM7, ARM9, Cortex) Mikrocontroller. Im Moment besitze ich einen mit OpenOCD. 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? Danke.
Die aktuellste Version von OpenOCD wurde von Hyperaktiven Open Source Programmierern kaputtprogrammiert. Man kann sie m.E. nicht verwenden. Wenn Du eine (sehr alte) Version runterlädst, ist die Wahrscheinlichkeit höher, daß Du damit gut arbeiten kannst.
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.
> Man müsste noch klären, ob das SAM-ICE auch mit nicht-AT91 Controllern > unter uVision ohne größere Einschränkungen funktioniert. Die Keil EVA-Version verwende ich mit dem SAM-ICE für AT91SAM7S64-Projekte. Alle anderen ARM-Derivate sind in der Software vorhanden. Einfach einmal ausprobieren.
Bitte 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.