Hallo, ich möchte mich privat in die Welt der ARMs einarbeiten. Dazu habe ich einen schönen Starterkit von MSC entdeckt, der mir sehr gut gefällt. Schaust du da : http://www.msc.de/frame/d/newsletter/newsletter_8.html Nur die Beschränkung auf ATMEL Prozessoren ist nicht so toll, da ich mich nicht schon vorher auf einen Hersteller festlegen will. Und auch die Codegrößenbeschränkung lässt Wünsche übrig, ich denke aber dass ich das mit dem ARM GCC löse. Was haltet Ihr von dem Angebot, oder kennt ihr bessere, die evtl. auch nicht auf ATMEL Controller beschränkt sind ?
Preistechnisch hört sich das ganz gut an. Board + JTAG ist immer ne gute Sache. Die Frage ist halt inwiefern du JTAG-Debugging mit dieser eingeschränkten Entwicklungsumgebung machen kannst. Wenn du dich generell mit ARMs befassen möchtest kann ich dir noch den folgenden Wiki Eintrag empfehlen: http://www.mikrocontroller.net/articles/LPC2000_Philips_ARM7TDMI-Familie Da geht´s um den LPC von Philips der vielleicht eine Alternative für dich ist. Schau doch mal rein. Grüße, Patrick
> Die Frage ist halt inwiefern du JTAG-Debugging mit dieser > eingeschränkten Entwicklungsumgebung machen kannst. Der Debugger des Angebotes ist nicht beschränkt. Nur der Compiler ist auf 32kB C-Code eingeschränkt. Assembler ist davon (wie ich wo anders gelesen habe) nicht betroffen. Würde ich aber vor dem Kauf nochmal abklären. > Wenn du dich generell mit ARMs befassen möchtest kann ich dir noch > den folgenden Wiki Eintrag empfehlen: > http://www.mikrocontroller.net/articles/LPC2000_Philips_... THX. Habe daraus folgende für mich interessante JTAG Interfaces entnommen: J-LINK von Segger U-LINK von Keil Weiß jemand, ob es zur Zeit bei irgendeinem Anbieter Starterkits mit einem dieser JATG-Interfaces gibt ?
Das SAM-ICE aus der Anzeige ist ein J-Link "OEM". Nach Informationen von at91.com funktioniert das SAM-ICE nur mit Atmel-Controllern jedoch kann das RDI-Interface und die Flash-Software von Segger lizenzkostenfrei genutzt werden. RDI wird von einigen Softwareanbietern unterstuetzt, es existiert auch eine GDB-RDI-Schnittstelle (z.B. im codesourcery-Paket). Fuer das J-Link wird von Segger einiges an Zusatzsoftware angeboten. Das ULINK ist sehr aehnlich aufgebaut, kann aber meines Wissens ausschliesslich von der Keil Software (uVision) genutzt werden, funktioniert damit auch gut (noch nicht viel getestet, nutze es im Moment nur als Flash-Hardware). uVision kann ueber die RDI-Schnittstelle ebenfalls mit einem J-Link Kontakt aufnehmen, man benoetigt aber scheinbar bei einem original J-Link zusaetzlich eine RDI-Lizenz von Segger, zumindest erscheint "hier" eine Aufforderung, den Lizenzcode einzutippen. GDB-RDI-Schnittstelle funktioniert beim J-Link ohne diese Lizenz wohl auch nicht, kann aber auch einen anderen Grund haben, nur kurz getestet. Beim SAM-ICE muss die RDI-Lizenz wohl nicht erworben werden. ULINK kann man bei Starterkits von Keil (Google-Futter: MCB2100, MCB2130, MCB2140) mitbestellen. Es gibt von Rowley noch ein vergleichbares gnuenstiges Geraet, scheint aber ausschliesslich mit Rowley-Softare nutzbar. Martin Thomas
Wenn denn Rowley Crossworks nicht so teuer wäre (500 UK/750 EUR), dann
könnte man das ja zusammen mit 'nem einfachen
Parallelport-JTAG-Adapter ("Wiggler") verwenden - das ist, soweit ich
weiß, die einzige Software, die auch unter den ernstgemeinten*
Windows-Versionen anständig mit 'nem "Wiggler" klarkommt.
Warum "OCD Remote" resp. "OCD Commander" von Macraigor praktisch
vollkommen unbrauchbar ist, wird nur Macraigor selbst wissen; den
Gebrauch des "OCD Remote" zusammen mit GDB/Insight schränkt es
jedenfalls ziemlich ein.
Gibt es da eigentlich weitergehende Erfahrungen, welche (andere)
Software unter den ernstgemeinten Windows-Versionen mit einem
"Wiggler" klarkommt?
*) Windows NT 4.0 - 5.1, jedoch kein Windows 95 und ähnlicher Quark
die Info brauche ich auch. Wie kann man ohne "ocd remote" leben. Ich hatte mal was von den Jtag-tools gelesen, doch bis zur brauchbaren Verwendung wurde es nie getrieben. Eine andere mögliche Veriante könnte http://sources.redhat.com/ecos/multi-ice.html Sein. Ich habe es nie ausprobiert.
THX @ all, besonders an mthomas für den äußerst kompetenten Beitrag. Ich habe mich umgesehen, und werde mir das MSC Startup-Paket holen. Das auf ATMEL geloggte J-Link was da dabei ist, kann mit diversen Toolchains bzw. Debuggern zusammenarbeiten. Aber leider nur mit ATMEL AT91. Zum Glück sind ATMEL Prozessoren aber günstig, gut verfügbar, und in vielen Leistungsklassen erhältlich. Damit kann (werde) ich also leben. Dabei kostet JTAG-Interface, Eval-Board und (auf 32k beschränkte) Soft weniger als nur das J-Link von Segger alleine. Andere J-Link Bundles in vernünfigen Preisregionen habe ich leider nicht finden können. Das Upgrade von 32k auf 511K kostet übrigens schon 2990,- Netto :O Ich werde mich da mal nach ner preiswerteren Toolchain umsehen. Hat jemand ne Idee ? @ Sanic : Du hattest recht, die 32 k betreffen den Debugger. Ausgenommen von der Beschränkung ist Assembler (Aber wer will schon einen ARM in Assembler programmieren ....)
Preiswerter als der von Dir genannte Preis für IAR ist dann doch Rowley
Crossworks, das kostet "nur" 750 EUR. Und arbeitet, wie ich schon
gelegentlich anmerkte, sogar anständig mit Parallelport-JTAG-Adaptern
("Wiggler") zusammen.
@ Rufus Ein ordendlicher Wiggler kostet auch schon ein bisschen was ... Und ein schlabbriger Nachbau kommt für mich nicht in Frage, da es meiner Ansicht nach nicht schlimmeres gibt, als ein unzuverlässiges Entwicklungswerkzeug. Übrigens gibts die Entwicklungsumgebung winIDEA von iSYSTEM auch "schon" für ca.1000 Euronen. Ich suche aber noch was preiswerteres. Gerne auch mit (vernünftiger) Beschränkung. Wie siehts denn mit dem GCC-Zeug aus ? Läßt sich damit vernünftig arbeiten ?
Ich habe mir mal einen Original-Wiggler angesehen und mit dem hier im Shop verkauften Olimex-Nachbau verglichen. Die "Schlabberigkeit" ist bei beiden annähernd vergleichbar. Einziger Nachteil des Olimex-Wigglers ist das angelötete Kabel, davon abgesehen ist der eher noch besser verarbeitet als das Original. Das Layout des Originals sieht aus wie ein Erstlingswerk von jemandem, der noch nie eine Digitalschaltung aufgebaut hat, in der Frequenzen jenseits von 1 kHz auftreten. Wüst geführte dünne Leiterbahnen für alles, sehr "luftiges" Layout, keine Masseflächen, keine vernünftigen Versorgungsleiterbahnen ... Der bislang am saubersten aufgebaute Adapter war ein Wiggler-Nachbau der Firma Phytec (große Masseflächen, vernünftiges Layout etc.) Man kann, wenn man einen Lötkolben am richtigen Ende anfassen kann und etwas über das Grundschulniveau im Aufbau von digitalen Logikschaltungen herausgekommen ist, sich einen Wiggler auch selbstbauen. Wen das überfordert, der bekommt auch keine Schaltung mit einem Microcontroller zum Laufen. Das "GCC-Zeug" leidet unter der Debugger-Unterstützung, hier ist nämlich GDB und "OCD Remote" zu verwenden ... und das ist unter den ernstgemeinten Windows-Versionen praktisch vollkommen nutzlos.
Hi, ich denke hier duerfte meine Frage richtig sein. Ich habe noch vom LPC Contest die ID zum Bestellen des JTAG Programmer/Debugger. Funktioniert dieser nur mit Keil Umgebung? bzw. ist der nur LPC tauglich? In wie weit ist das Winarm Packet zum arbeiten geeignet? Ist es schon so ausgereift wie WinAVR? Hoffe auf ein bischen Feedback. Gruß, Dirk
Hmmm. Das hört sich auch vernünftig an. Evtl. täts dann auch ein brauchbarer Wiggler mit einem Linux-Rechner zum Entwickeln. Muss ich mir mal durch den Kopf gehen lassen... Danke für den Tip.
@dose Hab ich mir auch schon angeschaut. Der kost aber "naggisch" (ohne Soft und Eval) auch schon 159 Euronen. Dafür ist er wesentlich universeller was das Target angeht. Gefällt mir eigendlich so vom ersten Eidruck recht gut. Hat damit schon mal jemand gearbeitet ? "Taucht" der was ?
Ich habe noch nicht damit gearbeitet. Er läuft auch mit dem OCD Remote. Das wird Rufus nicht freuen. Ich hab ein Angebot von Digi für ein WLAN Entwicklungsumgebung mit einem RAVEN. Da hätte der Debugger über 850Euro gekostet. Andere Fragen hat jemand die 30Tage Version von Rowley schon geteset? Ist der Debugtreiber auch von den 30Tagen betroffen? Dose
Warum sollte mich das nicht freuen?
Ich finde nur den "Raven" bzw. dessen Nachbauten zu hochpreisig.
Soweit ich weiß, ist der Debugger in Crossworks integriert, da gibt es
keinen externen Debuggertreiber, den man losgelöst mit anderen
Debuggern verwenden könnte.
Schön wär's, da die Kommunikation von Crossworks mit einem Wiggler
extrem deutlich viel besser funktioniert als die Kommunikation des
"OCD Commander" bzw. "OCD Remote".
("Extrem deutlich viel besser" bedeutet eine Übertragungsrate von
mehreren kByte pro Sekunde im Gegensatz zu vielleicht 300 Byte pro
Sekunde und zig Fehlermeldungen. Liegt nicht am "Wiggler"-Nachbau, da
es sich mit einem Original(TM)-Wiggler von Macraigor genauso verhält)
Schaut Euch doch mal den sehr schnellen USB -> JTAG von PLS an. Hab kuerzlich mit denen gesprochen und der Preis, der mir genannt wurde war unter 500 Euro mit einem vollwertigen (sehr guten) Debugger und einem vorgetesteten GCC ohne Einschraenkungen. Sieht so aus als ob der Fokus etwas auf dem STR7 ist aber auch AT91 und LPC2000 werden unterstuetzt. Hab mit dem Debugger auf C167 gearbeitet, war sehr gut und der Support ist auch erstklassig. Sollte ein Bedarf an Trace da sein, dann bietet PLS eine Hardware fuer 1500 Euro. Natuerlich muss dazu der Micro auch Trace unterstuetzen, dann wuerde nur noch LPC2000 uebrig bleiben.
Da Manko ist, dass die Opensourcegemeinde noch nicht ein Äquvalent für den Wiggler-Treiber geschrieben hat. Rowley hat bewiesen, dass die Hardware Wiggler ausreichend ist. Da ganz doofe bei der Benutzung von Macraigor ist auch die Cygwin Umgebung. Das wäre mal eine Diplomarbeit wert. Gibt es denn keinen Prof., der sein Rechenkabinett mit einem ARM ausstatten will und kein Geld für den Debugger hat?
Naja, wenn man mehr Ahnung von JTAG hätte als beispielsweise ich (der ich nicht viel drüber weiß), dann ließe sich sicherlich auch eine kostengünstige Alternative zum Parallelport-Gefrickel finden. Wenn ich das richtig einschätze, sollte das sogar mit bedeutend weniger Programmieraufwand möglich sein, als für eine "richtige" Ansteuerung des "Wiggler" erforderlich wäre. Der FT2232C von FTDI enthält eine sogenannte "Multi-Protocol synchronous serial engine" (MPSSE), mit der sich synchrone serielle Schnittstellen wie I²C und SPI implementieren lassen. Das bedeutet, daß ein großer Teil des "Bitwackelns", das für Parallelportadapter erforderlich ist, hier von Hardware erledigt wird und so einem das Leben deutlich vereinfachen dürfte. Obendrein gibt es von FTDI bereits eine für JTAG-Funktionen geschriebene DLL, die weitere grundlegende Funktionen zur Verfügung stellt (http://www.ftdichip.com/Projects/MPSSE/FTCJTAG.htm). Alles, was jetzt "noch" erforderlich ist, ist eine Software zu schreiben, die einerseits das Debuggerinterface zur Verfügung stellt, das GDB und Konsorten gerne sehen möchten und die andererseits mit der JTAG-DLL kommuniziert. Na? Jemand Lust (und Ahnung) dazu?
Wenn das JTAG Protokoll mal so offen/verständlich wäre dass man es "mal" eben implementieren kann. Dann würde es sicherlich viele JTAG Debug-Programme geben. Grüße, Patrick
Hallo Rufus, die MPSSE des FT2232C dafür zu nutzen finde ich genial. 10Euro kostet der IC. >Der FT2232C von FTDI enthält eine sogenannte "Multi-Protocol >synchronous serial engine" (MPSSE), Jezt müsste man wissen was auf dem Jtag Interface ab geht. Doss
Da fällt mir ein, ich hatte ca. vor einem halben Jahr einen Email-Kontakt zu einem Prof. aus Spanien oder Portugal. Der hatte den ARM9 als VHDL Code. Aus Geheimhaltungsgrüden durfte er den VHDL-Code nicht herausrücken. Leider weiß ich nicht, ob das Jtag Interface Bestandteil des VHDL-Cores war.
Betr. JTAG und JTAG an ARM-Controllern gibt es eigentlich schon relativ viel Code, an dem man sich orientieren kann, um die verschiedenen Zustaende der "state-machine" zu aktiviern und anzusprechen. Z.B. auf sourceforge (Projectsuche JTAG, auch fuer "Wiggler"-Hardware) und eine Application-Note von Atmel (ein AT91 steuert einen anderen AT91 ueber JTAG an). Aber das reine Interface ist nicht alles: zusaetzlich muss auch ein Treiber zu einer Debugsoftware (z.B. gdb) erstellt oder aus Vorlagen (gdb-Quellcode/CVS, avrice, msp-gcc-Projekt) angepasst werden. Zur Flash-Programmierung sind auch noch controllerspezifische Routinen zu erstellen (Routine via JTAG ins RAM, Daten paeckenweise via JTAG ins RAM, fuer jedes Paeckchen Aufruf der Routine "RAM->Flash", vgl. flash-Tool aus ucLinux). Scheint alles kein Hexenwerk, da man nicht von Null anfangen muss, aber kostet sicher einiges an Zeit. Fuer das Hardware-Interface wuerde ich nicht "nur" auf den FT-Chip und deren JTAG-dll setzen, da die DLL scheinbar nur fuer MS Betriebessysteme verfuegbar ist (nicht so genau geschaut). Mitstreiter fuer eine eigene Entwicklung findet man wahrscheinlich eher bei Nutzern von Nicht-MS-Systemen, denn fuer Windows gibt es einige nicht allzu teuere fertige Loesungen. Software selbst kann portabel programmiert werden, damit alle "froh" werden (ist bei einigen der sourceforge-Projekte so gemacht).
Wegen dem gdb-Debugger: Es gibt auch grafische Frontends, z.B. DDD.
Also die Botschaft von mthomas ist die Hardware beim wiggler belassen und nur die Software aufpolieren.
@Rufus: Apropos OCD Remote und "ernst gemeinte Windows Versionen": Deine Ausdrucksweise suggeriert, dass OCD Remote auf Win9x und Co besser läuft. Was dank dessen Netzwerktauglichkeit dann eigentlich kein grossen Problem darstellen sollte.
Das soll meine Ausdrucksweise nicht suggerieren; da hab' ich mich
vielleicht etwas ungeschickt ausgedrückt. Ich verwende diese
Windows-Versionen nicht und kann daher keine Aussagen über die
Funktionsweise von OCD {Remote|Commander} darunter treffen.
Das will ich auch nicht näher untersuchen, weil ich mir dieses Zeugs
nicht antun will.
Hallo, ich habe mich nun schon einige Wochen intensiv mit den SAM7S-ARM's von Atmel beschäftigt (AT91SAM7S64 um genau zu sein). Per JTAG kann weder mein Code, noch der Code aus dem ucLinux (armtool) noch der von Sourceforge (gdb-jtag-arm) was aus ihm herausquetschen ausser der Default ARM-IDCODE. Ich habe den Eindruck, dass das, was im Datenblatt des SAMs steht, stimmt: "IEEE 1149.1 JTAG Boundary Scan is enabled when JTAGSEL is high. The SAMPLE, EXTEST and BYPASS functions are implemented. In ICE debug mode, the ARM processor responds with a non-JTAG chip ID that identifies the processor to the ICE system. This is not IEEE 1149.1 JTAG-compliant." Das finde ich sehr ärgerlich. Nun ist man darauf angewiesen den Debug-Port oder USB zu verwenden - beides unter Windows. Im ICE-Mode ist das Instruction Register z.B. nicht 4 Bit sondern 3 Bit breit (siehe .bsd-File). Wer noch weitere Informationen hat, bitte hier Posten! Ich bin gerne dabei, eine Software für JTAG-Adapter (Serielle oder Parallele Schnittstelle, vll auch USB) zu schreiben. Clemens
Ich entwickle zur Zeit in einem größeren Projekt eine günstige Möglichkeit ARM7TDMI Controller wie den AT921SAM7 über JTAG anzusprechen. Ist noch in der Anfangsphase, es existieren aber schon konkretere Pläne. Vorerst für Windows, bei Interesse auch für Linux. Betatester werden dann sicher gebraucht werden. Ich hoffe spätestens Ende des Jahres etwas konkreteres vorweisen zu können.
Hallo XKSascha, das finde ich gut. Was hälst du davon, Kontakt miteinander aufzunehmen? Geteiltes Leid ist halbes Leid ;-) Hat bei dir schon etwas funktioniert? Register lesen, Status lesen, o.Ä? Würde mich wirklich interessieren. schöne Grüße, Clemens
Hallo XKSascha, das klingt gut, das ist ein Meilenstein. Dose
Rufus, Du magst das nicht so gemeint haben, aber ausprobieren kann ich es ja trotzdem. Ich habe deshalb mal ein Exponat aus meinem AMD-Museum reaktiviert, und siehe da: OCDremote WinXP: max s=5 (80KHz) OCDremote Win98: max s=1 (380KHz) Da OCDremote, wie der Name schon suggeriert, netzwerkfähig ist... Irgendeine Pentium-Kiste wird sich wohl noch finden lassen. Und die biegt man ggf. so zurecht, dass OCDremote automatisch hochkommt. Sicher, es ist nicht der Brüller. Aber spürbar besser.
Hallo, ich habe ein nicht zu Ende geführtes Projekt gefunden. http://jtager.sourceforge.net/ Ansonsten schon der richtige Weg.
@Robert Was beinhaltet das Angebot von PLS genau? Ist das die Hardware (UAD2 compact?) oder die Software oder ist das ein Bundle?
Hallo Rene, soweit ich weiss ein Bundle, software in diesem Falle ohne Support, Du bezahlst fuer die Hardware und bekommst auch die SW. Bin mir aber nicht absolut sicher, hab das Paket auf einem ARM Forum gesehen und ware beeindruckt. Ach ja, hatte dein Link vergessen: http://www.pls-mc.de/ Robert
Hallo! Na, dann muß ich Herrn Bauch von PLS am Montag nochmals interviewen. Ich habe nämlich heute ein Angebot von ihm bekommen: 1790.- Euro, allerdings mit Support für ein Jahr. Einen guten Eindruck macht das Paket aber, ganz im Gegensatz zu Seggers JLink-Zeugs. Gruß, René
Rene, moeglich, dass ich da was falsch verstanden hab, aber ich dachte das Paket fuer 1790 beinhaltet Trace und waere damit das gunestigste mir bekannt Paket mit Trace Untersteutzung. Die Sache mit Trace ist allerdings so, dass von dem ARM7 eigentlich nur Philips eine Trace Unterstuetzung auf dem Chip anbietet, die anderen bieten nur reines JTAG Debugging an. Robert
Ich habe gerade den Elektor Newsletter gelesen. Dort ist von 400Euro die Rende. http://www.elektor.de/Default.aspx?tabid=1&mid=386&ctl=Details&newsletter=1&ItemID=365
Wie ich soeben erfahren habe, fehlt der günstigen Version nicht nur der Support. Diese ist auch in Downloadbaren Code-Größe auf 32 KB begrenzt und damit wieder eher uninteressant. Und wenn ich dem Ganzen richtig folgen konnte, liegt die 'richtige' Version mit Trace (und Support) bei um die 3000,- Euro.
@MicroMann Hast Du Dir das MSC-Starterkit besorgt und kannst etwas dazu sagen ?
Ich bin zwar nicht MicroMann, habe das Kit hier aber trotzdem seit einiger Zeit liegen. Meiner Meinung nach ist das rausgeworfenes Geld, ich habe das als Lehrgeld verbucht: - Die wollten doch tatsächlich satte 14,50 EUR Versand haben - IARs EWB überzeugt nicht. Im Vergleich mit anderen mir bekannten Umgebungen wirkt das auf mich einigermaßen unübersichtlich. Außerdem ist die Code-Beschränkung nicht alles, denn zusätzlich kannst Du auch keine Listings erzeugen und alle Libraries kommen ohne Quell. Dafür wollen die aber alles über Dich wissen, sonst kommst Du nicht einmal über die Installation hinweg. Beseonders nett fand ich in diesem Zusammenhang die Ansage, daß das Produkt komplett ohne Support verkauft wird (für AFAIK ~3000 EUR). Du kannst aber natürlich einen extra Support-Vertrag abschliessen. ;-) - Seggers SAM-ICE ist das Allerletzte, da fährst Du mit jedem Parallel-Port Adapter besser. Daß sich das Gerät mit der Seriennummer 123456 am PC anmeldet, obwohl auch eine echte Seriennummer vorhanden ist', ist dabei nur die erste unangenehme Auffälligkeit... Besorg Dir lieber irgendein günstiges Olimex-Board und dazu das Buch 'Embedded System Design on a Shoestring: Achieving High Performance with a Limited Budget' von Lewin Edwards, da hast Du sicherlich mehr von. Der Beitrag spiegelt meine Meinung wieder. Es steht natürlich jedem frei, das Ganze anders zu beurteilen.
@René Vielen Dank für Deinen Beitrag ! Die Kosten sind bei mir kein Problem; ich suche eine Möglichkeit, ohne viel Zeitaufwand die Hardware zu testen. Letztlich würde ich dann wohl sowieso GCC einsetzen. Aber bei IAR persönliche Daten abzuliefern, kommt nicht in die Tüte; vermutlich haben die dann auch noch irgendwelche Art von Dongle, abgelehnt. Und keine Listings: wie soll ich denn dann die Compilerfehler finden ??? Andererseits lese ich hier die Beiträge, daß einige Anbieter Bastelware für gutes Geld anbieten, auch kein Bedarf. Mir würde es reichen, ein Board mit µC zu haben, in das ich effizient Programme laden kann - und wenn es mit einer .bat unter DOS läuft; das ist mir lieber, als mich per Maus durchzuklicken. Debugger brauche ich auch nicht - habe ich noch nie gebraucht :-) So muß ich wohl doch noch weitersuchen. Danke noch einmal !
Ah ... Kosten sind kein Problem. Wenn das so ist, kannst du dich ja auch mal bei Lauterbach Datentechnik nach einem Trace32 umsehen ;-) Ciao, Fabian
Hallo, hier wurde vom selbstbau eines JTAG ("Wiggler") gesprochen. Hat jemand ein Schaltbild für einen JTAG. Ich möchte meinen LCP2292 mit WinArm oder crossworks proggen und habe keine Lust noch mehr Euros für einen Wiggler in die Hand zu nenehmen. Ist eh schon alles teuer genug, Thomas
Thomas, schau mal in der "Files" section nach http://groups.yahoo.com/group/lpc2000/files/ Unter JTAG gibts das was. Keine Ahnung ob das mit Crossworks zusammenarbeitet aber mindestens gibt as dort schematics. Robert
Hallo Robert, vielen Dank. Ich werde das gleich mal abchecken. Gruss Thomas
Hallo Thomas, die meisten günstigen Entwicklungsumgebungen, die ich bisher gesehen habe, sind in ihrer Codegrösse auf 32, oder weniger, beschränkt. Wenn diese Begrenzung aufgehoben werden soll, dann wird es richtig teuer. Hast Du schon mal unter www.armkits.com die Entwicklungssysteme angeschaut? Sind in der Codegröße ohne Beschränkung, JTAG-Adapter ist dabei und auch das Flashen ist inbegriffen. Falls Du interesse hast, dann kannst Du das auch über mich, bei www.bsm-technik.de beziehen. Wollte das nur erwähnen weil ich selbst vor einem Jahr bei der Suche nach einem günstigen System beinahe verzweifelt bin. Ralf
Hallo Ralf, vielen Dank für die Info. Ja, die Embest IDE hab ich mir mal angeschaut und sie gefiel mir auch ganz gut. Da ich aber z.Z. in der Prototypen Phase bin, möchte ich noch nicht soviel investieren, da der "Schuß auch nach hinten losgehen kann". Ich habe mir aus dem www ersteinmal Crossworks besorgt und einen JTAG von Olimex. Ich werde damit mein µC Prototypen fertigstellen und falls es zur Serie kommt in die Vollen gehen mit NI LabView Embedded. Nochmals vielen Dank. Thomas
Hallo, wie so zum Te..el reden eigentlich immer alle Leute von IDE's und so einem Zeug? Besonders für ARM-Prozessoren? Es gibt ein GNU Toolchain für ARM-Prozessoren, make, 100000 freie Quelltexteditoren, darunter auch richtige IDE-Monster wie Eclipse - alles freie Software ... wozu (als Hobby-Mikrocontroller-Bastler) eine kommerzielle IDE??? Wenn es ums debuggen/flashen geht - prinzipiell sollte da doch der JTAG von Olimex und der GDB ausreichen, was braucht es mehr? Und wer kein JTAG "mag", der kann sich ja mal Redboot anschauen (ist in eCos enthalten, das für viele LPC-Derivate verfügbar ist), das ist ein ROM-Monitor, der auch einen GDB-Stub implementiert. Klar - wenn man kommerzielle Softwareentwicklung betreibt und die Entwicklungszeit eben ein ernstzunehmender Kostenfaktor ist, dann helfen schicke Debugger wie der Trace32 evtl. diese Entwicklungszeit immens zu verkürzen, aber auch in den muss man sich einarbeiten und außerdem sollte dann auch der Preis keine Rolle spielen. Aber selbst dann ist die GNU Toolchain zum Übersetzen immer noch eine gute Wahl, die dürfte inzwischen auch recht reif sein, schließlich wird sie ja auch in kommerziellen Projekten eingesetzt (Linux/uC-Linux wird ja mit der GNU Toolchain übersetzt - ich glaube nämlich nicht, dass irgendjemand Linux auf den ADS-Compiler portieren will). Also Ende vom Lied: nehmt die GNU Toolchain + make + z.B. xemacs + gdb + JTAG, das sollte reichen. Ciao, Fabian
Hallo Fabian, die freien Compilersachen funktionieren ja auch bestens, es ist eben nur das JTAG Programm was murrt. Der Adapter ansich ist nicht langsam, nur OCDRemote ist etwas lahm auf XP (laut dieser Erfahrungsberichte hier). Ich habe mir schon nen Wiggler gebaut und werde demnächst mal anfangen damit rumzuprobieren. Grüße, Patrick
>an Fabian Scheler im Pirinzip hast du recht doch leider ist dem nicht so. An einer IDE mangelt es nicht es fehlt die Debug Möglichkeit. Deshalb ist auch das Thema dieses Beitrages mit der Zusatzfrage Welcher JTAG angehangen. Ich bin auch auf der Suche nach einer Debug Variante. Von der Hardware ist der Wiggler funktionsfähig, Rowley hat es bewiesen, nur an einer freien Software harpert es. Das OCDRemote hat etliche Macken. Man kann z.B. nicht in den Flash schreiben, was ein Programmieren über das JTAG unmöglich macht. Man kann nur in den RAM schreiben. Von der Zuverlässigkeit der Verbindung ganz zuschweigen. Also das OCDRemote gehört auf den Müll. Weitere günstige Varianten sind nicht auf getaucht. Dann gibt es die Variante eines Softwaredebuggers als GDB-Stub in einem Betriebssystem wie ECOS. Leider habe ich festgestellt, dass die ECOS Portierung auf die LPC-Chips nicht vollsändig ist und gerade der von dir erwähnte Gdb-stub fehlt. Ansonsten hättes du recht. Falls jemand so eine vollständige Portierung hat bitte melden.
Hallo zusammen, zum Debuggen von Controllern mit einem ARM Kern kann ich "OpenOCD" (Open On-Chip Debugger) empfehlen: http://openocd.berlios.de Die Software arbeitet als Server, der Debug-Kommandos entweder ueber den GNU Debugger GDB oder ueber eine Telnet-Verbindung entgegennimmt und in JTAG Bitstroeme umsetzt. Ich habe OpenOCD schon mit Philips LPC2, Analog Devices ADuC7020, Oki 67Q4002 und Atmel AT91SAM7 ausprobiert. Sicher gehen auch andere ARM7TMDI und ARM7TDMI-S. Auch ein paar ARM9 gehen, z.B. der Atmel AT91RM9200. Man kann zur Zeit folgende JTAG Interfaces anschliessen: - den Wiggler (auch im Eigenbau) - den Amontec Chameleon Pod in einer von zwei Konfigurationen: Wiggler oder JTAG Accelerator (siehe www.amontec.com) - den FT2232C USB Controller (eine moegliche Ausfuehrung ist hier: http://www.fh-augsburg.de/~hhoegl/proj/volksmikro/usb-jtag/050910/ Da die Software offen ist (GPL-lizenziert wie Linux) kann man eigene JTAG-Interfaces dazufuegen. OpenOCD laeuft unter Linux und Windows (unter Windows braucht man Cygwin, siehe www.cygwin.com). Gruesse, Hubert
Hallo, ich habe jetzt den Raven als Jtager. Die Zuverlässigkeitsproblem sind die gleichen wie beim Wiggler. Er läuft nur etwas schneller, wenn er läuft. Es hängt von der Tagesform etwas ab. Die UNI aus Dresden hat auch schon ein Aktivität für den ARM7 gelestet und will es für den ARM9 erweitern.
Hallo, ich habe mir jetzt einen USB-Jtag Adapter gebaut. Dazu einfach einen FTDI2232C nehmen, anschließen und fertig. Als Software kommt dann OpenOCD zum Einsatz. Flashen funktioniert wohl bei LPC und SAM7S, bei letzteren kann ich es sogar bestätigen. Debuggen per Insight auch möglich. Ich bin derzeit dabei, ein paar Scripte für Linux zu bauen, die den Compilier-Flash-Debug-Prozess etwas vereinfachen. Schöne grüße, Clemens
Funktioniert eigentlich der Parallelport-Wiggler mit Linux zusammen einwandfrei ? Oder gibt es da auch Fehler ohne Ende und Performance-Probleme wie unter WinXP ? Bin am Überlegen das Debug-Problem mit Linux zu umschiffen. Denn wo ich die Firmware entwickele ist ja zunächst mal Wurscht. @ Clemens Wie sieht es mit der Zuverlässigkeit und Geschwindigkeit der FT2232C USB Lösung unter Windows XP aus ? Mit dem Teil kann man doch alles proggen, was man mit dem Wiggler auch bedienen kann. Oder braucht man da spezielle Zieldevice-Firmware / Treiber ? Gibts da auch fertige Lösungen zum Kaufen ?
Die Anleitrung ist cool :) Taugt der Amontec JTAGkey unter XP ? Hat das jemand in Betrieb ?
Hallo Was haltet ihr von Tantino von Hitex. Hat jemand schon Erfahrung damit gesammelt. Gruß Flo
Hi, arbeite mit der Entwicklungsumgebung von Hitex. Die Boards von Hitex sind die gleichen wie die Keilboards. Habe dazu die Boards mit dem LPC2138 und dem LPC2148. Boards sind sehr gut!!! Mit dem Tantino (JTAG Schnittstelle) kann man entweder mit dem Keil oder mit Hitop,der IDE von Hitex arbeiten. Hatte jetzt bei größeren Projekten schon des öfteren Probleme mit der IDE Hitop. z.B. mit Libary einbinden oder mit dem Aufteilen des Programms in mehrere Module. IDE stürtzt des öfteren auch manchmal ab. Wenn man von den Fehlern absieht aber ganz angenehm damit zu arbeiten. Ähnelt dem Keil. Sehr hilfreich ist der Start Easy von Hitex. Ein Programm zur erzeugung des Startup codes (ähnlich dem Dave von Infineon) Gibts vom Keil einen Startcode Generator zu den LPCs??? Bzw. würde mich auch interessieren ob andere mit Hitop arbeiten und ob auch hier des öfteren Probleme auftreten??? MfG
Keine Ahnung über die Funktionalität, wollte nur in die Runde schmeißen. http://www.devlf.com/armdbg.html
Hallo, ich habe auf der Seite von Macraigor einen USB2Wiggler gesehen. Die freie Software von Macraigor unterstützt ihn auch schon. Hat jemand eine Ahnung ob dieser Debugger zu dem USBJtager kompatibel zu den Olimex debuggern ist?
Keine Ahnung, aber ist das Teil denn so günstig, daß es sich lohnt, darüber nachzudenken? Das FT2232-basierende OpenOCD-Design besticht ja gerade durch seinen günstigen Preis ... und wird mittlerweile auch von kommerziellen IDE-Herstellern direkt unterstützt, wie beispielsweise von Rowley mit Crossworks for ARM 1.7
Nein die Frage ist andersherum. Kann die Macraigor Software OCD Commander den Olimex JATG ansprechen? Ich habe einen ARM, der noch nicht von openOCD unterstützt wird, jedoch von Macraigor.
Hmm. Zwei Möglichkeiten:
1 - Ausprobieren
2 - Analysieren, was für Devicetreiber in hwsupport-2.22-windows.exe
enthalten sind. Wenn tatsächlich der "Olimex-JTAG-Adapter" auf
Basis des FT2232 unterstützt würde, wären FTDI-Devicetreiber
enthalten.
Das halte ich jedoch für nicht sehr wahrscheinlich.
Macraigor hat wohl keinerlei Interesse daran, andere Hardware mit ihrer Software zu unterstützen - ein Großteil des Aufwands liegt in der Software, die Hardware selbst ist in den meisten Fällen sehr einfach. Der OpenOCD sollte den NS9360 sehr wohl unterstützen - ARM926EJ-S wird seit Anfang diesen Jahres unterstützt. Ein Problem könnte allenfalls ein Big-Endian Target sein - der CFI Flash Code hat hier scheinbar noch ein paar kleinere Bugs, allerdings sind das keine gravierenden Probleme, die nur gründlich getestet werden müssten. Gruß, Dominic
Ich habe vor kurzem einen Praktikanten angesetzt. Er hatte es nicht zum Laufen bekommen.
Heh, das ist was anderes - die Konfiguration des OpenOCD ist defintiv aufwendiger als die eines proprietären Debuggers. Das liegt allein schon an der Vielzahl unterstützter JTAG Interfaces, aber auch daran, dass mir bei der Entwicklung maximale Flexibilität über einfach Handhabung ging. Den ARM926 Support konnte ich bisher selbst auf NXP LPC3180 und Atmel AT91SAM9260 testen, mit einem Freescale i.MX21 wurde er wohl auch schon erfolgreich getestet.
Kleiner Nachtrag: Macraigor schreibt, dass es sich bei dem USBWIGGLER um ein USB 2.0 Hi-Speed (480mbit) Interface handelt - damit laesst sich ein FT2232 sicher ausschliessen, da dieser nur USB2.0 Full-Speed (12mbit) unterstützt.
Hallo Dominic R. ich habe mich mal selbst hingesetzt. Ich habe es geschafft Addressen auszulesen. Es scheint so als würde openocd nicht alle GDB Anfragen richtig abarbeiten. Die Initialisierung des GDB´s erfolgt über ein script. Bei der Abarbeitung des Scriptes erhalte ich: Warning:jtag.c:1068 jtag_read_buffer(): value captured during scan didn`t pass the requested check: captured:0x00 check_calue:0x01 check_mask:0x0f
Hi, das Problem wurde in Revision 144 gefixed, die aktuelle Version von Yagarto (ich vermute mal, dass du die benutzt) basiert aber noch auf 141. Du kannst entweder die aktuellen SVN Sourcen selbst übersetzen (setzt MinGW oder Cygwin voraus), auf einen neuen Yagarto Release warten (dürfte in einigen Tagen, max. 1-2 Wochen so weit sein), oder die Version von Jörn Kaipf ausprobieren, die er in Beitrag "at91sam7s512 und openocd" geposted hatte. Wenn du Probleme damit hast kann ich dir auch eine Version ohne Cygwin übersetzen, muss dazu aber mein w2k Image mal wieder anwerfen... Gruß, Dominic
/me mag autotools & GNU Toolchain: vmaster@magrathea:~/openocd/mingw/trunk$ uname -a Linux magrathea 2.6.22-ck1 #2 PREEMPT Sat Jul 28 16:14:50 CEST 2007 i686 GNU/Linux ./bootstrap ./configure --host=i586-mingw32msvc --enable-parport --enable-ft2232_ftd2xx --enable-amtjtagaccel --enable-gw16012 --enable-presto --enable-parport_giveio --with-ftd2xx=/home/vmaster/jtag/cdm_2_02_04/i386/ make Produziert: http://mmd.ath.cx/openocd/openocd_mingw_r188.exe Ohne Garantie - vmware laesst sich für meinen 2.6.22er Kernel gerade nicht übersetzen, da ist wohl wieder ein UPdate nötig - aber prinzipiell sollte die Binary ohne externe Abhängigkeiten funktionieren. Gruß, Dominic P.S.: Der OpenOCD unterstützt in R188 auch ETM+ETB des LPC3180 ;)
Hallo Dominic, es sieht schon besser aus. Es läuft noch nicht korrekt. Ich bleibe dran. Muss erst einmal heute was schaffen. Ich habe hier den Raven und kann mit dem Raven vergleichen. Mit dem Raven habe ich 147664 bits/sec und mit dem OLIMEX schaffe ich bei JTAG Speed=0 106134bits/sec
Der OpenOCD unterstützt in R188 auch ETM+ETB des LPC3180 ;) Keine Ahnung was ETM und ETB ist. Klingt zu mindest interessant.
ETM: Embedded Trace Macrocell - ein Trace Port, mit dem Daten- und Befehls-Trace möglich ist, das heisst man sieht sowohl ausgeführte Befehle als auch die Daten, die bei Load/Store Anweisungen verarbeitet wurden. ETB: Embedded Trace Buffer - On-Chip Puffer, der die Daten der ETM via JTAG zur Verfügung stellt, so dass kein teures Trace Equipment nötig ist. Die Ausgabe sieht dann z.B. so aus:
1 | --- tracing enabled at 0x800007fc --- |
2 | 0x800007fc 0xe12fff1e BX r14 |
3 | 0x800008b0 0xe2833121 ADD r3, r3, #0x40000008 |
4 | 0x800008b4 0xe3a02080 MOV r2, #0x80 |
5 | 0x800008b8 0xe5832000 STR r2, [r3] |
6 | 0x800008bc 0xe3a03902 MOV r3, #0x8000 |
7 | 0x800008c0 0xe2833004 ADD r3, r3, #0x4 |
8 | 0x800008c4 0xe1833783 ORR r3, r3, r3, LSL #0xf |
9 | 0x800008c8 0xe3a02040 MOV r2, #0x40 |
10 | 0x800008cc 0xe5832000 STR r2, [r3] |
11 | 0x800008d0 0xebffffb7 BL 0x800007b4 |
12 | 0x800007b4 0xe1a0c00d MOV r12, r13 |
13 | 0x800007b8 0xe92dd800 STMDB r13!, {r11, r12, r14, r15}
|
Gruß, Dominic
Hallo Domenic R. ich habe gerade weiter getested. Das GDB init script wird noch nicht richtig abgearbeitet. Folgende Befehle weigert sich openOCD: monitor reg ctrl monitor reg ctrl =0x50058 Fehlermeldung: register ctrl not found in current target monitor long 0x90600104 = 0x33313333 Fehlermeldung: command long not found
"monitor" leitet Befehle direkt an das Remote Target weiter (Remote mit Bezug auf GDB, in diesem Fall OpenOCD). Das Target muss dann einen Interpreter mitbringen, der diese Befehle versteht - in deinem Fall weiss der OpenOCD leider nicht, was diese Befehle bedeuten sollen. Da du den Raven einsetzt vermute ich, dass du ocdremote verwendest. Das Equivalent zu "monitor long" wäre "monitor mww <address> <value>". Zum Speicherzugriff existieren: md[bhw] <address> [count]: lesen von byte, halfword (16 bit) oder word (32 bit), optionales Argument [count] gibt die Anzahl an. mw[bhw] <address> <value>: schreiben von byte, halfword (16 bit) oder word (32 bit) Welches Register mit "reg ctrl" gemeint ist weiss ich leider nicht. Gruß, Dominic
Hallo Domenic, genau, momentan benutze ich Raven mit ocdremote. Dieser ist auch für den NS9360 beschnitten. Ich kann diesen Debugger für keinen anderen Controller verwenden. Da ich auch auf andere ARMs abziehle, und nicht für jeden ARM einen eigenen Debugger mir anschaffen will, will ich openOCD einsetzen. Mit einem Raven ist es sehr knapp. Wenn man ein Praktikanten mit im Projekt hat, dann gibt man den Debugger ungern aus der Hand. Mit dem Register ctrl habe ich auch noch nie gearbeitet. Ich vermute: System control processor (CP15) registers The system control processor (CP15) registers configure and control most of the options in the ARM926EJ-S processor. Access the CP15 registers using only the MRC and MCR instructions in a privileged mode; the instructions are provided in the explanation of each applicable register. Using other instructions, or MRC and MCR in unprivileged mode, results in an UNDEFINED instruction exception. CP15 uses 16 registers. R1: Control register Register R1 is the control register for the ARM926EJ-S processor. This register specifies the configuration used to enable and disable the caches and MMU (memory management unit). It is recommended that you access this register using a read modify-write sequence.
Hi, an das CP15 control register dachte ich auch erst, aber der Wert 0x50058 ist nicht ganz richtig, Bits 6-3 sind Reserved, und sollten mit 1 geschrieben werden. Mein LPC3180 hat 0x50078 nach dem Reset im CP15 Control Register. Der OpenOCD bietet zum Zugriff auf CP15 Register den Befehl: arm926 cp15 <opcode_1> <opcode_2> <CRn> <CRm> [value] so kann z.B. das ID Register ausgelesen werden > arm926 cp15 0 0 0 0 0 0 0 0: 41069264 oder das Configuration Register geschrieben werden > arm926 cp15 0 0 1 0 0x00050078 0 0 1 0: 00050078 Gruß, Dominic
Hallo Dominic, Entschuldigung der Wert ist monitor reg ctrl = 0x500F8 Das kommt gut. Wenn dein LPC3180 den Wert 0x50078 hat, dann wurde das Bit 7 auf High gesetzt. Als Erklärung für bit 7 habe ich gefunden: [7] B bit Endianness 0 Little endian operation 1 Big endian operation Set to the value of BIGENDINIT on reset.
Hallo Dominic, ich habe es geschafft!! Es gibt noch einen Error, jedoch habe es geschafft das Programm in den RAM zu laden und zu starten.
die Transfer rate ist auf 53067 bits/s Eine Idee warum nur noch die Hälfte?
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.