Besonders interessiert bin ich am Betrieb eines "Wiggler"-kompatiblen JTAG-Dongles (Olimex ARM-JTAG) an einem Rechner mit Windows XP - liegen da schon irgendwelche Erfahrungswerte vor? Welcher Debugger eignet sich am besten? Gibt es empfehlenswerte (Selbstbau-?) Alternativen?
Topic mal ueberdacht? Betr. Topic haet' ich etwas weiterhelfen koennen. Aber eigentlich ist die Frage ja "Erfahrungen mit Wiggler/ICE". gnuarm-insight und Macraigor-Interface "are known to work" unter Win32. (..was hat das mit gcc zu tun?...)
OK, zerknirscht nehme ich die Kritik zur Kenntnis. Du hast mehr als Recht. Topictitelformulierlernkursteilnahme gebucht. Für mich gehört gdb/insight irgendwie zur GCC-Toolchain, daher mein Posting in diesem Forum. Bedeutet "are known to work" daß Du die genannte Kombination selbst im Betrieb gesehen hast? Oder wird nur irgendwo behauptet, daß es gehen möge?
Jops, ich behaupte das! :-) Die OCDLibRemote legt bei mir allerdings ein sehr merkwüdiges Verhalten an den Tag: 1. Start mit device "RAVEN" 2. Connect mit Insight (schlägt fehl!) 3. Start mit device "WIGGLER" 4. Connect mit insight (Funktioniert!) Wenn ich einen der Schritte auslasse, kann ich das WIGGLER bzw Target nicht erreichen!
Danke für den Tip - das werd' ich mir wohl mal näher ansehen. Mit exakt welcher Distribution arbeitest Du?
Zwei Sachen: - WinARM (achtung: BETA) - OCDLibRemote http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index.html#winarm http://macraigor.com/gnu/hwsupport-2.07.exe
Vielen Dank für die Links, OldBug. Nur: Bin ich blöd oder fehlen beim WinArm-Download von M. Thomas so banale Informationen, welches* der bin-Verzeichnisse in den Pfad aufzunehmen ist und wie etwaige andere Environmentvariablen zu setzen sind? Vielleicht bin ich ja etwas zu verwöhnt, aber bereits Turbo C 2.0 (Borland, Ende der 80er oder frühe 90er) hatte ein Installationsprogramm, das einem diese Dinge abnahm ... Gebe zu, daß das meine ersten Berührungen mit gcc sind, vielleicht muss das ja so sein? *) Im Angebot \bin \arm-elf\bin \preliminary\insight-5.2.1\bin \utils\bin \utils\bin\moved_old_TBD
Also :-) Da fehlt natürlich noch so einiges, was das ganze einfacher zu handhaben macht, deswegen ja auch mein Hinweis auf BETA! Allerdings handelt es sich bei diesem Paket um eine "Windows-Native"-Toolchain, d.h. es wird KEIN CygWin/MinGW benötigt! Du solltest das Packet nach C:\WinARM entpackt haben, und den Pfad C:\WinARM\bin in die PATH-Variable aufnehmen.
Viel Dokumentation gibts nicht, ich geb's ja zu, nur ein paar Zeilen readme.txt aber hmm, da steht sogar was drin: Extend System %PATH% by C:\WinARM\bin;C:\WinARM\utils\bin; Installationsprogramm kommt irgendwann noch, hat aber keine besondere Dringlichkeit fuer mich. Fuer meine LPC2106-Spielereien reicht es bisher so vollauf. Ich wollte auch nur so etwas die gewohnte WinAVR Umgebung für den ARM-Einstieg zur Verfügung haben. Aber ich "debugge" die LPC-Programme bisher auch nur per "scharf draufgucken" und "uart-ausgaben" ohne diese "neumodischen" Debug-Programme/Wiggler/Raven - dafuer ist OldBug "zustaendig". Die Keil Evaluierungsversion ist auch einen Blick wert, die IDE ist schick und das lpcisp-Tool von M.Maurer laesst sich problemlos einbinden. Mir war allerdings etwas zu undurchsichtig was bei Keil "hinter den Kulissen" passiert. Debugging/Simulation bei Keil bisher auch nicht ausprobiert.
mthomas & Oldbug - wieder vielen Dank. Offensichtlich ist dieser Thread "nicht so mein Thread", da ich effizient unter Beweis gestellt habe, mit partieller Blindheit geschlagen zu sein. Das ist mir irgendwie ziemlich peinlich. Der Hinweis auf die bislang angewandte "konservative" Debugmethode und der also nicht vorhandenen Erfahrungen mit Wiggler & Co. ist allerdings auch viel Wert - somit ist klar: hic sunt draconis. In einem englischsprachigen Forum fand ich den Hinweis, daß der Wiggler-kompatible Olimex-Nachbau wohl nur mit dem Debugger von Rowley Associates vernünftig funktionieren solle - der ist immerhin schön in eine IDE integriert, kostet aber (mitsamt IDE, Compiler etc.) immerhin knapp 500 UKP - in EUR umgerechnet wird die Zahl noch unschöner (750). Da der mitgelieferte Compiler auch ein gcc ist, kommt mir das etwas seltsam vor. Daß kein Cygwin benötigt wird, ist mir übrigens sympathisch - ich finde dieses Konzept der Linux-Emulation fragwürdig (aus je mehr unabhängig gewarteten Komponenten ein System besteht, desto interessante Nebeneffekte können auftreten. Unter Windows nennt man das "DLL-Hölle", aber es gibt auch andere effektive Ansätze ...).
Hast Du es denn mittlerweile lauffähig? Falls nicht, mach ich mich heute oder morgen abend mal ran, endlich mal den Wiki-Artikel dazu fertig zu stellen...
Danke der Nachfrage, weiteres wird frühestens heute Abend geschehen. Dies soll Deine mehr als löblichen Intentionen (das Wiki betreffend) in keiner Weise beeinflussen ...
Mittlerweile habe ich mir mal die GCC-Variante von Rowley angesehen - das Teil lässt einem schon das Wasser im Munde zusammenlaufen. Im Gegensatz zum "OCD Commander" von Macraigor funktioniert hier der "Wiggler" problemlos und schnell. Debuggen in der Hardware via JTAG ist damit tatsächlich möglich - wer das mal erlebt hat, wird nur noch schwer davon zu überzeugen sein, ohne Debugger auf einem µC zu entwickeln. Da der OCD Commander (der ja Grundlage für die GDB/Insight-Interaktion mit dem "Wiggler" ist) fast überhaupt nicht funktioniert, ist meine Motivation, mich mit anderen GCC/GDB/Insight-Varianten zu beschäftigen, höchstens finanzieller Natur. Übrigens ist auch die Interaktion der Embedded Workbench von IAR mit dem "Wiggler" ähnlich indiskutabel; auch diese setzt auf Unterstützung durch Teile des OCD Commander auf. Das mag sich anders verhalten, wenn man das Entwicklungssystem nicht unter ernstgemeinten Windows-Versionen einsetzt (Kommunikation mit der Parallelschnittstelle ist unter NT/W2K/XP was anderes als unter DOS/95 etc,) - aber sowas tue ich mir nicht an. Und daß es funktionieren kann, beweist Rowley. Auf der gleichen PC-Hardware, auf der OCD Commander scheitert, läuft CrossWorks.
Das Problem wird OCDRemote sein. Hoffentlich wird da mal jemand eingreifen, und einen ordentlichen "Proxy" zwischen GDB und Hardware (Wiggler)Programmieren... Oder McRaigor kümmert sich selber darum, wäre ja auch noch möglich. :) JTAG zum Debuggen is schon was feines!
Hat jemand schon mal versucht unter dem Keil µVision3 zu debuggen ? Compilieren und Simulieren geht ja da sehr komfortabel. Gibts da nen JTAG-Dingens zum Selbstbau oder nur zu kaufen ? Müßte ja ähnlich gut gehen, wie für die Silabs Mords-Speed 8051-er. Peter
Wiggler kann man nachbauen, von der "Elektronik" her nicht viel anders als ein STK200-Dongle also ParPort->"Buffer-IC"->JTAG Anschluss. Schaltplan im I-Net. Wenn recht erinnert, hatte ich den Link dahin in die Wikki-Linksammlung geschrieben. Erste Tests mit meinem Olimex Wiggler sind komplett fehlgeschlagen, sowohl mit dem µVision3 (da noch nichtmal den Anfang gefunden, die Online-Hilfe scheint bei mir defekt) als auch mit Macraigor-Software (Kabel nicht erkannt o.ae.). Nun ja, bisher meine Fehler auch so gefunden, DCF77, Drehimpulsgeber, DS18B20 und KS0108 "wollen" schonmal.
Ja, leider scheint die einzige Software, die mit einem Wigller klarkommt, das doch etwas arg hochpreisige CrossWorks von Rowley zu sein - jedenfalls, wenn man ernsthaftere Windows-Versionen einsetzt. Warum die Macraigor-Software nicht funktioniert, ist schon rätselhaft und ärgerlich zugleich. Der LC210x scheint mir auch nicht so der hundertprozentig optimale Kandidat fürs JTAG-Debuggen zu sein, verliert der doch prompt die Hälfte seiner eh' recht knapp bemessenen I/O-Leitungen ...
Hm, also nochmal: Wiggler und McRaigor's OCDLibRemote funktionieren bei mir, wenn auch mit Krücken! Betriebssystem: Windows XP Home Edition.
@Oldbug: Krücken? Wie schnell ist der von Dir verwendete Rechner? Ich verwende ein Notebook mit 500/600* MHz pIII und 512 MByte RAM unter XP Professional. An der Hardware kann es zumindest prinzipiell nicht liegen - sonst liefe ja CrossWorks nicht. Das bisschen "Funktion", das ich dem OCD Commander entlocken konnte, war nur bei Timingeinstellung '8' hinzubekommen. Alle kleineren Werte führen zur Funktionsverweigerung. *) je nach Stromquelle. Akku = 500 MHz, Netz = 600 MHz. Beides geht mit CrossWorks.
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.