hallo miteinander! gerade eben habe ich meine ersten ARM-Chips (Freescale MKE02Z64VQH2) bestellt. Jetzt wollte ich langsam mit der ersten Leiterplatte anfangen und weiß überhaupt nicht, wie man ein Programm ins Flash bringt. So ein Evaluation Board nützt mir nichts, der Chip soll ja meine spezielle Hardware steuern. Außerdem liegt hier ein KwikStick rum, den man angeblich als Programmiergerät nutzen kann, aber ich hab' nicht rausgefunden wie. Wie schätzt ihr die Chancen, dass ich einem 8-Bitter das SWD-Protokoll beibringe und den "großen" darüber flashe? Weil, das flashen selbst, also Register und so, ist im Datenblatt beschrieben, nur zu SWD finde ich nicht viel konkretes. Oder gibt's für Linux etwas fertiges, das mit ganz wenig Hardware auskommt? Für die HCS12 braucht man auf der Leiterplatte ja nur den 6-poligen BDM-Stecker aber ein externes Programmiergerät. Für ARM mit JTAG gibt's entsprechend einen 20-poligen oder einen 9-poligen Stecker. Aber der MKE02 kennt nur noch SWD - gibt's dafür schon einen Standard-Stecker? Allerdings wäre es schon schöner, wenn's ohne Programmiergerät ginge. Ein paar Gatter/Pegelwandler würde ich noch spendieren.
Ich kann nur empfehlen: Kauf dir ein j-link edu. Das kostet einmal Geld, spart aber eine Menge Frust an anderer Stelle. Fertige Bastellösungen die das SWD-Protokoll können kenne ich nicht. Und selbst wenn hast du immer noch das Henne-Ei-Problem. Beim ersten Versuch auf einem ARM sollte man sich wenigstens auf irgendwas verlassen können. Wenn deine komplette Entwicklungskette neu ist hast du ohnehin das Problem, dass du nicht weißt wenn's nicht geht wer denn nun Schuld ist. Dann auch noch ein selbst gebastelter SWD-Adapter dessen Funktions man nicht mal evaluieren kann? Ich hatte mit STM32/Atolic sowie LPC1xxx/LPCXpresso angefangen. Da kriegt man erst mal ein Gefühl für das Ganze. Aktuell verwende ich Crossworks mit jlink. Mit Eclips in jeder Form stehe ich auf Kriegsfuß. Keil ist für den Anfang auch zu empfehlen. Solange die 32k reichen. Der Debugger (auch der von Crossworks) ist Lichtjahre besser als das Eclips-Geraffel. Trotzdem schreibe ich für meine Projekte immer noch makefiles für die gnu-arm-Tools und gebe nicht auf bis das auch damit läuft. Damit lernt man sehr schnell und manchmal schmerzhaft was die IDE's teilweise verstecken.
avr3 schrieb: > Der > Debugger (auch der von Crossworks) ist Lichtjahre besser als das > Eclips-Geraffel. Das verstehe ich nicht ganz; Crossworks verwendet einfach nur den GDB (zB mit dem J-Link GDB Server). D.h. erstmal gibt es gar keinen Debugger von Crossworks. Den GDB bindet man typischerweise auch in eclipse ein (wie es bei Atollic schon voreingestellt ist), d.h. man verwendet genau den selben Debugger, nur eben mit anderer GUI. Ist die eclipse-GUI so unfassbar schlecht?
Kindergärtner schrieb: > Das verstehe ich nicht ganz; Crossworks verwendet einfach nur den GDB > (zB mit dem J-Link GDB Server). D.h. erstmal gibt es gar keinen Debugger > von Crossworks. Den GDB bindet man typischerweise auch in eclipse ein > (wie es bei Atollic schon voreingestellt ist), d.h. man verwendet genau > den selben Debugger, nur eben mit anderer GUI. Ist die eclipse-GUI so > unfassbar schlecht? Crossworks verwendet nicht den GDB-Server sondern wie Keil auch die dll bzw. so. Die GUI des Debuggers und der Funktionsumfang ist Sache der IDE. Wenn man nur mal mit LPCXpresso rum spielt merkt man nicht, dass einiges an Peripherie in der SFR-Ansicht disabled ist. Das geht dann erst bei den Kaufversionen. Atollic für STM32 und LPCXPresso für LPC1xxx und dann noch 5 andere Eclips-varianten für andere Cortexe? Das ist zu viel. Ich finde Eclips unfassbar schlecht, ja. Kann anderen durchaus anders gehen. Mir reicht von der Sache aber auch ein einfacher Editor. Es gibt Leute die brauchen keinen Debugger oder nur die rudimentären Sachen davon. Ist bei mir nicht der Fall. Und der Workflow vom Übersetzten bis zum ersten Breakpoint ist gefühlt mit Keil bzw. Crossworks 5mal schneller als mit den Eclips-Lösungen. Coocox ist in dieser Beziehung das aller letzte. Aber wie gesagt, dass ist meine, wenn auch subjektive Meinung. ich habe das alles mal probiert und die Entscheidung so für mich getroffen. In Fragen Lizenzpolitik ist Crossworks durch keinen andere kommerzielle IDE zu schlagen. Lizenziert wird pro User und nicht pro Rechner. Und ich kann prima meine externen Projekte debuggen die mit den gnu-arm-tools übersetzt sind und keine einzige Zeile Quellcode von Crossworks oder irgendeine Lib der IDE verwenden.
kaufe dir das Board hier: FRDM-KE02Z http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FRDM-KE02Z da ist ein Programmer schon drauf und du kannst damit auch den schon vorhandenen Stecker zum externen Programmieren verwenden.
>gerade eben habe ich meine ersten ARM-Chips (Freescale MKE02Z64VQH2) >bestellt. Jetzt wollte ich langsam mit der ersten Leiterplatte anfangen >und weiß überhaupt nicht, wie man ein Programm ins Flash bringt. Warum kaufst du die dann? >Wie schätzt ihr die Chancen, dass ich einem 8-Bitter das SWD-Protokoll >beibringe und den "großen" darüber flashe? Geht gegen Null.
avr3 schrieb: > Crossworks verwendet nicht den GDB-Server sondern wie Keil auch die dll > bzw. so. Ah tatsächlich. hat scheinbar den nachteil dass Crossworks (laut Doku) dafür aber nicht alle vom J-Link unterstützden Prozessoren kann (wie ARM11 und Cortex-A,R). Der Vorteil am GDB ist halt dass man auf Frontendseite ein einheitliches Interface hat und man so mit einer einzigen GUI (wie ddd oder eclipse etc) quasi alle erdenklichen Targets erreicht, ohne dass man dort explizit für jeden Programmer/Debugger etwas programmieren müsste. avr3 schrieb: > Atollic für STM32 und LPCXPresso für LPC1xxx und dann > noch 5 andere Eclips-varianten für andere Cortexe? Das ist zu viel. Das ist halt Atollic "schuld", dass die eclipse derart verunstaltet haben. Man kann auch ein "jungfräuliches" Eclipse nehmen und dort alles derart installieren/konfigurieren dass es alles Prozessoren und auch noch ganz andere Sprachen wir ruby oder java kann, alles in einem Programm. avr3 schrieb: > Ich finde Eclips unfassbar schlecht, ja. Es ist halt sehr mächtig & flexibel, daher kann man nicht mit 3 Clicks eine spezifische Funktionalität erreichen. Wenn (falls) man es aber konfiguriert kriegt funktionierts ganz gut. avr3 schrieb: > Und der Workflow vom > Übersetzten bis zum ersten Breakpoint ist gefühlt mit Keil bzw. > Crossworks 5mal schneller als mit den Eclips-Lösungen. Jo. Dafür kann man in eclipse auch zB Java-Breakpoints setzen (zur Entwicklung der PC-Gegenstelle eines Programms) ohne für jede Sprache eine eigene IDE zu benötigen... avr3 schrieb: > Aber wie gesagt, dass ist meine, wenn auch subjektive Meinung. Tjo... avr3 schrieb: > In Fragen Lizenzpolitik ist Crossworks durch keinen andere kommerzielle > IDE zu schlagen. Dafür ist eclipse, GDB, GCC komplett opensource :o)
gnd3 schrieb: > Für ARM mit > JTAG gibt's entsprechend einen 20-poligen oder einen 9-poligen Stecker. > Aber der MKE02 kennt nur noch SWD - gibt's dafür schon einen > Standard-Stecker? SWD ist neben JTAG die HW-Schnittstelle die üblicherweise bei den ARMs verwendet wird. Die Schnittstelle ist im Prozessor integriert (siehe Datenblatt). Üblicherweise ist die Schnittstelle vom Prozessoer auf den 10(9)-poligen Mini-JTAG oder den 20-poligen großen JTAG Stecker aufgelegt. Welchen Du verwendest ist ziemlich egal, Du kannst sogar einen eigenen "erfinden" - die Stecker sind jedoch empfohlen. Üblicherweise liegt die SWD-Schnittstelle auf dem 20-poligen großen Stecker auf. So und jetzt zur Seite des PCs. Dort brauchst Du ein Programmiergerät das die SWD-Schnittstelle der ARMs unterstützt. SW Diskussion siehe oben. Dami9t kannst Du schon üblicherweise flashen. Musst Du nur noch die beiden verheiraten, heißt also eletromechanisch komaptibel machen (20 polige Buchse auf 20-poligen Stecker oder Adapter). Fertig. rgds
erstmal herzlichen Dank für alle Antworten! avr3 schrieb: > Kauf dir ein j-link edu. user schrieb: > kaufe dir das Board hier: FRDM-KE02Z Eigentlich habe ich schon so etwas wie ein j-link, das meldet sich so: # idVendor 0x1366 SEGGER idProduct 0x0101 J-Link ARM bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol # nur, was kann ich damit anfangen? Von den beiden gewinnt also ganz klar das FRDM weil es (laut Werbung) keine Software auf dem PC braucht: # FRDM-KE02Z comes with the mass-storage device (MSD) Flash Programmer OpenSDA Application preinstalled. The MSD Flash Programmer is a composite USB application that provides a (...) an easy and convenient way to program applications into the KE02Z MCU. It emulates a FAT16 file system, appearing as a removable drive in the host file system with a volume label of FRDM-KE02Z. Raw binary and Motorola S-record files that are copied to the drive are programmed directly into the flash of the KE02Z and executed automatically. # Genial, genau so muss das sein. Und das für gute 10 Euro, ich bestelle gleich 2 oder 3 ;) Dass das FRDM nur den KE02 versteht ist natürlich ganz schlecht. Eigentlich sollten ja alle ARM gleich sein, und besonders per SWD. ABER: der Flash-Speicher ist ja von Chip zu Chip unterschiedlich, also muss das Programmiergerät jeden einzelnen Chip kennen. Insofern wäre ich mit dem j-link auch nicht besser dran, wenn es um neue Chips geht. holger schrieb: > Warum kaufst du die dann? Weil der S9S12G..LC nicht lieferbar ist. Der und der KE02 kommen im QFP mit 0.8mm Pitch, ansonsten gibt es nur 0.5mm oder QFN oder BGA. Außerdem sollte ich dankbar sein, dass ich mich jetzt mit ARM beschäftigen darf, das wurde doch endlich mal Zeit ;) holger schrieb: > >Wie schätzt ihr die Chancen, dass ich einem 8-Bitter das SWD-Protokoll > >beibringe und den "großen" darüber flashe? > Geht gegen Null. Meinst du wegen fehlender/schlechter Doku? Früher wäre eine (vom Prinzip her) so einfache Schnittstelle im Datenblatt so genau beschrieben gewesen, dass ich gekaufte Lösungen garnicht in Betracht gezogen hätte. Aber nachdem Freescale sich da auf ARM verlässt, bin ich wohl auch verlassen. 6A66 schrieb: > Üblicherweise ist die Schnittstelle vom Prozessoer auf den > 10(9)-poligen Mini-JTAG oder den 20-poligen großen JTAG Stecker > aufgelegt. Welchen Du verwendest ist ziemlich egal, Du kannst sogar > einen eigenen "erfinden" einen eigenen wollte ich ja vermeiden; ich dachte nur, evt. gibt's inzwischen einen ohne JTAG-Pins. Dann bleibe ich beim 9-poligen, es gibt eh' schon genug Standards. 6A66 schrieb: > So und jetzt zur Seite des PCs. > Dort brauchst Du ein Programmiergerät das die SWD-Schnittstelle > der ARMs unterstützt. witzigerweise hat mich die Suche nach segger j-link zu openOCD mit FT2232 geführt. Das wäre die Lösung ohne Programmiergerät. Den FT2232 bringe ich schon noch unter, notfalls auf der Lötseite ;) Nochmal vielen Dank, jetzt sehe ich schon klarer...
gnd3 schrieb: > Eigentlich habe ich schon so etwas wie ein j-link, das meldet sich so: > nur, was kann ich damit anfangen? Wie schafft man es sich einen J-Link zu kaufen ohne in der Lage zu sein auf die Website (segger.com) zu gehen und sich die Anleitung anzusehen? Da steht alles haarklein erklärt... gnd3 schrieb: > Genial, genau so muss das sein. Und das für gute 10 Euro, ich bestelle > gleich 2 oder 3 ;) Toll, dafür kann man damit nicht debuggen... gnd3 schrieb: > Meinst du wegen fehlender/schlechter Doku? Früher wäre eine (vom Prinzip > her) so einfache Schnittstelle im Datenblatt so genau beschrieben > gewesen, Da das SWD eine Menge kann ist das eben nicht mehr so einfach (wie zB beim AVR).
gnd3 schrieb: > Früher wäre eine (vom Prinzip > her) so einfache Schnittstelle im Datenblatt so genau beschrieben > gewesen, dass ich gekaufte Lösungen garnicht in Betracht gezogen hätte. Ich habe gute Nachrichten für dich. Du brauchst nichts zu kaufen, sondern lade dir einfach die "ARM® Debug Interface Architecture Specification" runter. Goggle einfach nach: ARM Debug Interface Architecture Specification Dort steht alles drin was du brauchst :-)
Kindergärtner schrieb: > gnd3 schrieb: > > Eigentlich habe ich schon so etwas wie ein j-link, das meldet sich so: > > nur, was kann ich damit anfangen? > Wie schafft man es sich einen J-Link zu kaufen ohne in der Lage zu sein > auf die Website (segger.com) zu gehen und sich die Anleitung anzusehen? > Da steht alles haarklein erklärt... Naja, der Weg zu segger.com war nicht so offensichtlich. Es ist ein Freescale KwikStik bei dem etwas j-link ähnliches integriert ist. Auf den Tipp von avr3 hin hab' ich heute viel über j-link gelesen, aber ich glaube immer noch, dass man PC-Software von segger braucht (mindestens eine DLL). Das FRDM-KE02Z läuft zwar auch nur mit geheimer Firmware, aber wenigstens brauche ich auf dem PC nichts weiter. Kindergärtner schrieb dazu: > Toll, dafür kann man damit nicht debuggen... Aber es kann flashen -- ohne das Teil kann man nicht einmal eine LED blinken lassen. Also ist es eine echte Alternative zum Selbstbau. Dirk schrieb: > Goggle einfach nach: ARM Debug Interface > Architecture Specification # This document is only available in a PDF version to registered ARM customers. Non-Confidential Restricted Access # na immerhin nicht top secret :) trotzdem danke!
gnd3 schrieb: > aber ich > glaube immer noch, dass man PC-Software von segger braucht (mindestens > eine DLL). Ja und??? Wo ist das Problem die Software zu installieren? Keil µVision hat zB schon alles mitgeliefert was man braucht, da musste nur noch auf "Flashen" drücken. Segger liefert sogar GDB-Server für Linux, und dank Anleitung ist es auch kein Problem den zu installieren. gnd3 schrieb: > bei dem etwas j-link ähnliches integriert Kann gut sein, Segger liefert die "J-Link-Chips" auch "nackt" zum Verbauen durch Weiterverarbeiter. gnd3 schrieb: > Aber es kann flashen -- ohne das Teil kann man nicht einmal eine LED > blinken lassen. Ach, mit dem J-Link ist mir das aber auch schon gelungen. > Also ist es eine echte Alternative zum Selbstbau. Der J-Link ist noch eine viel bessere Alternative. Wenn du schon einen der besten JTAG-Flasher&Debugger hast (J-Link), warum bestehst du dann noch darauf so eine Frickellösung zu verwenden?!
> Keil µVision hat zB schon alles mitgeliefert was man braucht, > da musste nur noch auf "Flashen" drücken. Beitrag "Keil µVision preis" > 1700,- nur IDE und Debugger, d.h. ohne Compiler 1700,- und wieviel Gigabyte nur zum flashen? Mit dem ganzen IDE-Kram kann ich nichts anfangen, sowas muss auf der Kommandozeile funktionieren. Außerdem ich bin allergisch gegen "Projekte". Und vor allem ist noch garnicht sicher, ob der KE02 überhaupt schon unterstützt wird. Warum soll ich die IDE-Bedienung lernen? Ich muss sowieso verstehen, was innen drin wirklich passiert, also kann ich das Makefile auch gleich selbst schreiben. > Wenn du schon einen der besten JTAG-Flasher&Debugger hast (J-Link), > warum bestehst du dann noch darauf so eine Frickellösung zu verwenden?! Moment, von der Frickellösung "SWD selbst bauen" bin ich doch schon weg. Ich bin überzeugt, dass ich mit dem FRDM-Board schneller zum Ziel komme als mit dem J-Link. Wenn das nicht wie in der Werbung funktioniert, können wir nochmal verhandeln ;)
Der j-link Unterstützt deine die: Freescale MKE02Z16xxx2 Freescale MKE02Z32xxx2 Freescale MKE02Z64xxx2 seit Version 4.72 aktuell ist 4.78 http://www.segger.com/j-link-release-notes.html gnd3 schrieb: > 1700,- und wieviel Gigabyte nur zum flashen? Mit dem ganzen IDE-Kram > kann ich nichts anfangen, sowas muss auf der Kommandozeile > funktionieren. Außerdem ich bin allergisch gegen "Projekte". Und vor > allem ist noch garnicht sicher, ob der KE02 überhaupt schon unterstützt > wird. > > Warum soll ich die IDE-Bedienung lernen? Ich muss sowieso verstehen, was > innen drin wirklich passiert, also kann ich das Makefile auch gleich > selbst schreiben. Ich habe auch meinen Editor und makefiles. Trotzdem benötige ich einen guten Debugger. D.h. einen der mir auch die Peripherie vernünftig anzeigt, Watch-Variablen automatisch während des "Runs" aktualisiert u.s.w. Breakpoints und stepin, stepout können alle. Das reicht mir persönlich aber bei weitem nicht. Und da steckt auch die Arbeit drin. Und das für alle erdenklichen ARM-Derivate ist schon eine Leistung die man nicht für lau erbringen kann. Für Eclipse in Rohform gibts nur das "Eclipse Embedded Systems Register View". Mit gefühlten 20 unterstützen Chips... Wer damit klar kommt ok. Manche brauchen auch gar keinen Debugger. Ich könnte aber nicht ohne. Viele die STM32 benutzen werden sowas auch nicht in der Form benutzen. Die arbeiten auf die STM32-Libs und haben mit den Registern nichts am Hut. Leider lernt man so aber den µC nicht kennen. Auch nicht mein Ding.
jetzt macht ihr mich langsam nachdenklich, von wegen "guter Debugger". Bisher hab' ich für meinen "Haupt-Chip" einen selbst geschriebenen Simulator benutzt. Der hat mir natürlich alles angezeigt, was ich sehen wollte. Ich bin ja gespannt, wie ich dann ohne den auskomme... und ob man für C eher einen Debugger braucht als für Assembler.
gnd3 schrieb: > Ich bin ja gespannt, wie ich dann ohne den auskomme... und ob > man für C eher einen Debugger braucht als für Assembler. Es ist nicht die Frage ob "man" das braucht. Ich habe nur gesagt ich brauche das. Und ja, ich kenne es zur genüge auch anders. Z80 handcodiert ohne Assembler, denn der gerade gebaute "Computer" war der einzige den ich hatte. Z8 und 8051 mit Monitorprogrammen, avr ausschließlich mit LED an/aus oder printf und UART. Klar geht das auch so. Wehe aber man gewöhnt sich mal an einen ordentlichen Debugger, dann ist alles andere Krampf.
gnd3 schrieb: > 1700,- und wieviel Gigabyte nur zum flashen? Es gibt eine free Version die aber auf 32kB begrenzt ist. > Mit dem ganzen IDE-Kram > kann ich nichts anfangen, sowas muss auf der Kommandozeile > funktionieren. Tut es glücklicherweise auch, es gibt auch Kommandozeilen-Tools von Segger genau dafür. Da musst du nur tatsächlich ein paar Seiten PDF lesen um die Bedienung zu erlernen. Hättest du mal auf der Segger Seite nachgeschaut wüsstest du das auch. gnd3 schrieb: > Warum soll ich die IDE-Bedienung lernen? Ich muss sowieso verstehen, was > innen drin wirklich passiert, also kann ich das Makefile auch gleich > selbst schreiben. Darfst du auch gerne, makefiles haben doch nichts mit flashen & debuggen zu tun... gnd3 schrieb: > Ich bin überzeugt, dass ich mit dem FRDM-Board schneller zum Ziel komme > als mit dem J-Link. Wenn dein Ziel ist "Ein image drauf flashen" dann möglicherweise. Und dein Image natürlich schon funktioniert. Wenn dein Ziel aber ist dass du auchmal nachschauen willst was da tatsächlich auf der Hardware passiert, das flashen auch schnell gehen soll, mit einer Reihe von Prozessoren funktionieren soll, wird der J-Link da besser sein. Wenn man schon die ganze Debug-Hardware da hat, sich damit unendlich viel Arbeit beim Fehlersuchen ersparen kann, warum um die paar Minuten geizen die Anleitung vom J-Link zu lesen? Es gibt so viele Fehler da kannst dir ohne Watchpoints einen Wolf suchen. gnd3 schrieb: > Bisher hab' ich für meinen "Haupt-Chip" einen selbst geschriebenen > Simulator benutzt. Wenn du einen Simulator für die STM32 geschrieben kriegst und den billiger als Keil anbietest dürftest du damit einiges an Geld verdienen können. Aber das wird definitiv länger dauern als das Lesen der Anleitung vom J-Link. Die ganzen lustigen Hardwarebugs vom STM32 musst du natürlich mitsimulieren. gnd3 schrieb: > und ob > man für C eher einen Debugger braucht als für Assembler. An sich nicht. Da man aber mit High-Level-Sprachen wie C, C++ tendentiell viel mächtigere, komplexere Programme schreiben kann steigt die Nützlichkeit eines Debuggers dort drastisch an.
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.