Hallo, bisher habe ich 'nur' Mikrocontroller wie Attiny, Atmega usw. programmiert. Nun möchte ich in die Programmierung von ARM Cortex-M0 einsteigen und die Welt der IoT (Internet of Things) erkunden. Kann mir jeman dafür einen Programmer empfehlen? Da ich bisher mit Atmel Studio gearbeitet habe würde ich gerne dabei bleiben. Von Atmel habe ich die Programmer 'Atmel ICE' und 'Atmel SAM-ICE' gesehen. Ich blicke da aber nicht so recht durch, worin besteht bei beiden genau der Unterschied? Danke für Eure Hilfe...
Cortex M0 ist der Core von ARM. Programmiert wird aber nicht der Core, sondern der Flash-Speicher, und der ist vom Hersteller des Mikrocontrollers. Üblicherweise kann man auf zweierlei Art programmieren: Per vorinstalliertem Bootloader und per Debugger. Die Schnittstelle zum Debugger ist von ARM, der Bootloader (z.B. über UART) aber vom Hersteller des Controllers. Beim Debugger sollte man drauf achten, dass die angedachte Entwicklungsumgebung den Controller und den Debugger auch unterstützt.
Hallo A. K., danke das wusste ich noch nicht, das hilft mir schonmal weiter. Aber da ich ja in der Atmel-Familie bleibe, was die Prozessoren und die Entwicklungsumgebung und auch den Programmer angeht müsste es ja passen - oder? Aber was nehme ich denn nun den 'Atmel ICE' und 'Atmel SAM-ICE'? Mir sind die Unterschiede nicht klar...
Kann nur den Segger JLink empfehlen. Feht für fast alle ARMe.
http://www.atmel.com/products/microcontrollers/arm/sam-d.aspx?tab=tools Der Sam-ice geht auch für die dickeren ARMs, der jtagice3 nur für die kleinen Cortex-M0(+), würde ich sagen.
T. Baumbach schrieb: > Aber da ich ja in der Atmel-Familie bleibe, was die Prozessoren und die > Entwicklungsumgebung und auch den Programmer angeht müsste es ja passen Wenn du in der Familie bleiben willst, dann würde ich dir zu einem der Xplained Evalboards [1] raten. Da ist der Programmer/Debugger schon drauf. Wenn du dann weißt daß du bei den Atmel SAM bleiben willst, kannst du immer noch das Geld für ein Atmel-ICE o.ä. in die Hand nehmen. Aber vielleicht möchtest du ja auch mal über den Tellerrand schauen. ST macht auch schöne Cortex-M. Und die gibts in sehr vielen Varianten als Discovery Evalboard. Ebenfalls mit Programmer/Debugger (STLINK) onboard, wobei man bei den meisten Boards von ST den STLINK auch standalone betreiben kann. Von NXP gibt es ähnliches (LPCXpresso). [1] z.B. das hier: http://www.atmel.com/tools/ATSAMD10-XMINI.aspx
Segger J-Link gibt nichts besseres. Die ermäßigte EDU Version (50€) hat außer der Tatsache daß man Dir blind(!) vertraut daß Du sie nur zur persönlichen Weiterbildung oder zu Hobbyzwecken einsetzen wirst keinerlei Beschränkungen im Funktionsumfang. Die Vorteile des J-Link gegenüber eines Atmel-only-Gerätes sind erstens daß Du es wirklich für nahezu jeden ARM-Controller unter diesem Himmel verwenden kannst und nicht nur für Atmel und zweitens daß für die jenseits von Atmel sehr beliebe Eclipse IDE ein Plugin existiert das speziell auf den J-Link zugeschnitten ist (und natürlich unterstützen auch fast alle anderen IDEs den J-Link weil er sowas wie der de-facto Industriestandard ist).
Ich kann dir diesen https://www.segger.com/jlink-debug-probes.html empfehlen. Falls du es nicht für kommerzielle Entwicklungen verwendest, kostet das Gerät knapp 60 €. Das Ding ist echt sehr leistungsfähig.
Hm, wer erfährt denn, ob ich den Programmer kommerziell benutze oder nicht? Oder hat das ehe was mit Gewissen zu tun?=)
:
Bearbeitet durch User
Hallo, danke, aber ich denke ich bleibe erstmal in der Atmel Familie. Sich in die Programmierung von ARM Cortex einzuarbeiten und eine andere Entwicklungsumgebung ist zu viel auf einmal für mich. Da ich meine Produkte auch verkaufe wäre die EDU-Version des Segger J-Link wohl nichts für mich. Der J-Link Base kostet aber gleich ca. 400 EUR. Der Atmel ICE kostet ca. 110 EUR, der Atmel SAM ICE kostet ca. 140 EUR. Aber ich weiß hat immer noch nicht den Unterschied zwischen den beiden!?! Die Info von Axel Schwenke finde ich auch sehr interssant, ich wollte mir das BTLC1000 Xplained Pro Starter Kit bestellen weil ich Bluetooth Funktionalität brauche. (http://www.atmel.com/tools/atbtlc1000-xstk.aspx). Axel Schwenke sagte da ist der Programmer/Debugger mit drin. Ok, kann ich damit denn auch eigene SAM L21 programmieren, die also nicht fest auf dem Evaluierungsboard aufgelötet sind? Irgendwann möchte ich ja eigene Schaltungen mit dem SAM L21 aufbauen. Da habe ich dann den SAM L21 auf meiner Platine. Kann ich den dann dann auch mit Hilfe des Evaluierungsboards programmieren oer brauche ich da dann einen Programmer?
Böser K. schrieb: > Oder hat das ehe was mit Gewissen zu tun?=) Nein, aber im Kleingedruckten steht, dass dir im Falle des Missbrauchs ein gewisses Körperteil abfällt. :-P Im Ernst, Segger J-Link ist auch meine erste Wahl. Der kleine Preis für die EDU-Version schützt Segger ganz einfach vor China-Klonen. Die Chinesen kriegen dass für die Qualität auch nicht billiger hin.
IBei: Einen ST-Link-Clone gibt es fuer wenige (ca. 3) Euronen. Einen J-Link-Clone fuer einige Euro mehr. Die passenden M0 von ST (STM32F030F4P6) im Zehnerpack ebenfalls wenige Eu. Bei der letzten Lieferung warens noch 7. Ein passendes Nucleoboard (NUCLEO-F030R8) von ST, das einen ST-Link fuer STM-32 enthaelt fuer etwas mehr als 10 Euro. Ich wuesste im Moment nicht warum ich an Ateml mein Geld in den Rachen werfen sollte. Zumal ich die Debugadapter fuer schlecht designt halte. Und ihr Visual-Studio-Anhaengsel aka Studio koennen sie im Mondschein wo hin stecken.
T. Baumbach schrieb: > bisher habe ich 'nur' Mikrocontroller wie Attiny, Atmega usw. > programmiert. > Nun möchte ich in die Programmierung von ARM Cortex-M0 einsteigen und > die Welt der IoT (Internet of Things) erkunden. > Kann mir jeman dafür einen Programmer empfehlen? > Da ich bisher mit Atmel Studio gearbeitet habe würde ich gerne dabei > bleiben. Da sind erstmal eine Menge an Fragen offen. 1. kannst du NUR mittels irgend einer IDE zu Potte kommen oder ist dir der direkte Umgang mit den eigentlichen Tools (Compiler, Assembler, Linker, Fromelf) geläufig? 2. kannst du fehlerfreie Programme schreiben oder bist du auf das Durchsteppen per Debugger angewiesen? 3. wie hast du bisher deine Programme aufgebaut, eher modular und mit sowas wie einem eingebauten ansatzweisen Mini-Monitor per UART oder einfach nur genau das, was grad gebraucht wird? 4. hast du schon mal Manuals zu Cortexen verschiedener Hersteller angeschaut oder bist du eher strikt auf Atmel orientiert? 5. ist all dein Bemühen rein privater bastlerischer Natur oder gibt es berufliche Aspekte? Also, du fragst nach einem Programmer. Gut. Da gibt es prinzipiell 2 Wege: a) den Weg über SWD und b) den Weg über eingebauten Bootlader. JTAG ist bei Cortexen weitestgehend außen vor, da durch SWD abgelöst. Für alles nach a) brauchst du einen SWD fähigen JTAG-Adapter und da ist der J-Link von Segger quasi der Klassenprimus. Wenn überhaupt, dann orientiere dich an diesem. Falls Berufliches hier dabei ist, dann plane den tiefen Griff in die Firmenkasse, denn der originale J-Link ist TEUER. Bei rein privatem Vergnügen solltest du dir einen J-Link-Edu leisten. Der ist bezahlbar, hat dafür aber ein paar Lizenzen weniger eingebaut als die Vollversion. jaja, Lizenzen sind bei Segger im Adapter eingetragen. Natürlich bekommt man per Ebay etc. auch J-Link Nachbauten aus China für billiges Geld. Ich gebe da keinen Rat, außer daß es für bastlerische Zwecke sinnlos ist, einen Voll-J-Link-Nachbau zu kaufen, denn der ganze JTAG-Teil wird für Cortexe eigentlich nicht gebraucht. Da wäre es aus meiner Sicht eher verständlich, sich als ganz armer Schüler einen "Onboard"-Spezial-J-Link-Nachbau für 7..8 € dort zu ordern. Die können kein JTAG sondern nur SWD, sie haben auch keine Pegelwandler, können also nur 3.3V, sind aber ansonsten mit allen Programmen benutzbar, die den J-Link benutzen können. Alles andere hat nämlich so seine Haken: - der ULink und ULink-2 von Keil ist erstmal NUR!! mittels der IDE von Keil benutzbar. Es gibt von Keil keinerlei Standalone Programmier-Software. Für den ULink-2 gibt es zwar mittlerweile eine alternative Firmware, so daß er damit auch vom Brenn-Programm von Coocox benutzbar zu sein scheint (hab's nicht selber ausprobiert), aber das ist eine recht dünne Decke, denn Coocox ist typmäßig immer noch recht eingeschränkt. - alle Spezial-Programmer ST-Link, Nu-Link, und so weiter sind von hause aus eingeschränkt auf die Produktpalette ihrer jeweiligen Hersteller. Damit schränkt man sich künstlich ein. - das obige gilt allgemein auch für fast alle Programmier-Zusätze, die sich auf Eval-Boards befinden. In einigen selteneren Fällen hat man dort eine Spezialversion des Segger'schen J-Link drauf. Das ist erstmal gut, denn damit kann man die zugehörige Software von Segger benutzen - und die ist zehnmal besser als alles andere... und: mit dem Eval-Board kann man das auch ganz offiziell. Tja. Mit der anderen Herangehensweise per Bootlader sieht das alles ganz anders aus. Die Chips von NXP und ST haben eigentlich alle einen fest eingebauten Bootlader. (kennt jemand Ausnahmen?) Diese Bootlader sind z.T. sehr unterschiedlich, manche arbeiten nur per UART, brauchen also am PC eine serielle Schnittstelle oder einen billigen USB/Seriell-Adapter, andere sind da besser bis hin zu Bootladern vial USB. Dort meldet sich der Bootlader als Speicherstick an, wo man seine Firmware nur noch draufzukopieren braucht, eben genau so, als wenn man sie auf einen Speicherstick kopiert. Außer einem USB-Anschluß auf der eigenen Leiterplatte braucht es da garnichts an Equipment! Für die Chips von NXP gibt es die "FlashMagic" Software - und die ist frei benutzbar, ohne Lizenzgehampel. Bei ST gab es früher den "Erfos", wie das derzeit aussieht mußt du mal sehen. Kurzum, zum Loslegen ist die Wahl des geeigneten Chips das erste, was man tun sollte, dann sehe ich als nächstes das Benutzen des Bootladers und dann erst den Gedanken an SWD-Adapter nebst ggf. Lizenzbedenken. W.S.
Also auch ich kann nur Segger empfehlen. Das Geld ist es definitiv wert. Wenn du es verkaufst, dann sollten die paar Euros auch kein Problem sein. Was ich empfehlen kann, ist ein Nucleo von STM. Da hast du den debugger + Cortex drauf. Ich habe mit Freescale, Atmel, STM und NXP Controllern gearbeitet und STM mit Cube ist zwar nicht Perfekt (sind noch Bugs in z.B. USB-Stack) aber es erleichtert das Arbeiten sehr. Die Cortex con Atmel hat auch nicht wirklich was mit den AtMegas zu tun.
T. Baumbach schrieb: > danke, aber ich denke ich bleibe erstmal in der Atmel Familie. Du magst dafür Gründe haben. Es gibt aber auch gute Gründe, sich mal woanders umzuschauen. Andere Mütter haben auch schöne Töchter. > Sich in die Programmierung von ARM Cortex einzuarbeiten und eine andere > Entwicklungsumgebung ist zu viel auf einmal für mich. Ach geh. Die Entwicklungsumgebungen sind doch eh alle gleich. Und IMHO auch vollkommen überbewertet. Gute Kommandozeilen-Werkzeuge wie es sie für Segger und STLINK gibt (und zwar auch für die Welt jenseits von Windows) sind mir wesentlich wichtiger als eine Windows-only IDE. > Da ich meine Produkte auch verkaufe wäre die EDU-Version des Segger > Die Info von Axel Schwenke finde ich auch sehr interssant, ich wollte > mir das BTLC1000 Xplained Pro Starter Kit bestellen weil ich Bluetooth > Funktionalität brauche. > (http://www.atmel.com/tools/atbtlc1000-xstk.aspx). Nun, dieses Board ist erstmal nur ein Add-On für ein Xplained Basis- board. Ganz grob vergleichbar mit einem Arduino-Shield. > Axel Schwenke sagte da ist der Programmer/Debugger mit drin. > Ok, kann ich damit denn auch eigene SAM L21 programmieren, die also > nicht fest auf dem Evaluierungsboard aufgelötet sind? Da auf diesem Board kein Programmer ist, offensichtlich nicht. Und auf dem SAM D10 Xplained Mini ist es anscheinend nicht vorgesehen, die Verbindung zwischen dem Programmer und dem Target zu unterbrechen und ein externes Target dranzustecken. Bei anderen Xplained-Boards mag das anders aussehen. Lies halt mal die Doku.
Böser K. schrieb: > Oder hat das ehe was mit Gewissen zu tun?=) Ja. Es wird nicht geprüft und Du musst auch keine Erklärung abgeben. Du bist nur Deinem Gewissen gegenüber verantwortlich und nachdem Du nach einiger Zeit das Gerät und die zugehörige Software zu schätzen gelernt hast wirst Du in den Spiegel schauen und sagen: "Ja. Die 50€ hab ich denen gegeben die es verdient haben, ich habe keinen billigen Klon aus China gekauft und wenn ich irgendwann so weit bin das kommerziell einzusetzen dann werde ohne zu zögern die Pro-Version bestellen denn das Gerät und die Software und das Know-How das die da reingesteckt haben sind jeden Cent ihres Preises wert und noch viel mehr."
Hallo, danke an alle, auch an W.S. mit seiner ausführlichen Antwort. Ich möchte nicht unhöflich sein, bin für jede Antwort hier dankbar. Aber dieser Thread zeigt mal wieder, dass hier eher um Dinge geht wie 'diese IDE ist besser als jene' oder 'dieser Programmer ist besser als jener' als um meine eigentliche Frage. Ich programmiere bereits sehr lange im Bereich der Mikroprozessoren. Nicht nur Atmel's Attiny, Atmega usw. sondern auch andere. Habe früher auch die 6502, 68000er, 8086er usw. programmiert vorwiegend in Assembler ohne komfortable IDEs. Und ich programmiere modular, so dass ich Code wiederverwenden kann wenn irgend möglich. Ausgaben über LCD oder auch die modernen SHARP Memory Displays über SPI sind kein Problem. Was ist denn so falsch, wenn man eine IDE und einen MCU Hersteller gut kennt dabei zu bleiben? Sicher kann man sich viele IDEs, Tools vier Hersteller von ARM Prozessoren anschauen, aber warum? Will man alle IDEs und alle MCUs verschiedener Hersteller testen und vergleichen, dann ist man ewig dran - wofür? Meine Aufgabe ist es Hardware und Software zu entwicklen (auch kommerziell) und nicht alle IDEs und alle MCUs miteinander zu vergleichen. Bisher habe ich mit den MCUs von Atmel gute Erfahrungen gemacht, auch das Atmel Studio ist OK. Es ist kostenlos und hat keinerlei Beschränkungen hinsichtlich Code Größe. Atmel Produkte und die IDE mögen auch ihre Schwächen haben, aber das haben andere doch auch. Wichtig ist doch, dass man die Idee, die man im Kopf hat umzusetzen. Dabei ist es egal ob man ein Kommandozeilen-Tool oder ein Windows-basiertes Tool nimmt. Das Ergebnis zählt - nicht die IDE oder die Tools. Bisher hat mir leider keiner helfen können in meiner ursprücngliche Frage: Worin besteht denn bitte genau der Unterschied zwischen 'Atmel ICE' und 'Atmel SAM-ICE' Vielleicht kann mir jemand helfen? Danke...
T. Baumbach schrieb: > Worin besteht denn bitte genau der Unterschied zwischen 'Atmel ICE' und > 'Atmel SAM-ICE' Planlos schrieb: > Der Sam-ice geht auch für die dickeren ARMs, der jtagice3 nur für die > kleinen Cortex-M0(+), würde ich sagen. T. Baumbach schrieb: > Bisher hat mir leider keiner helfen können in meiner ursprücngliche > Frage: Du musst die Antworten schon lesen.
T. Baumbach schrieb: > Was ist denn so falsch, wenn man eine IDE und einen MCU Hersteller gut > kennt dabei zu bleiben? Du hast den tieferen Grund meiner Fragen nicht verstanden. Also, im Klartext: Manches Programmier-Geschirre ist so richtig NUR mit der dazu passenden IDE benutzbar, der ULink zum Beispiel. Ob es einem paßt oder nicht, man muß bei sowas eben die IDE nehmen, "friß Vogel oder stirb". Mir ist sowas unangenehm, dir vermutlich irgendwann auch. Manches Programmier-Geschirre ist auf ganz bestimmte Produkte eingeschränkt. Dafür ist es aber auch kommerziell guten Gewissens einsetzbar. Wenn man damit leben kann und will, geht's ja irgendwie, aber fast immer wird man dabei wiederum auf irgendeine IDE gedrängelt. Manches Programmier-Geschirre hat all diese Einschränkungen nicht, ist dafür aber TEUER. Wenn du dich unwohl fühlst, gleich am Anfang teuer Geld auszugeben, dann wäre die Bootlader-Version die bessere für dich, weil grundsätzlich deutlich billiger und ohne Lizenzprobleme. Aber dafür mußt du ein eher erfahrener Entwickler sein, kein Programmier-Baby der ohne Debugger keinen Fuß auf den Teppich bekommt. Ebenso solltest du dich zuvor mal in die Produkte unterschiedlichster Hersteller eingelesen haben UND auch bei den üblichen Distries mal nachgesehen haben, was die so anbieten und zu welchen Konditionen, um einen Überblick zubekommen, was denn für deine Vorhaben in Frage kommt. T. Baumbach schrieb: > Nun möchte ich in die Programmierung von ARM Cortex-M0 einsteigen und > die Welt der IoT (Internet of Things) erkunden. Ja, eben. Es gibt nicht nur den M0 auf der Welt, es gibt auch andere und die Wahl, welcher wofür am ehesten sinnvoll erscheint, müßtest DU für dich treffen. Aber dazu braucht es zuvorige Kenntnisnahme. So gibt es ne Menge unterschedlichster Randbedingungen und Fragen, die du dir in einer stillen Stunde mal selbst stellen solltest um daraus deine Zielrichtung zu präzisieren. Hier will dir keiner etwas aufdrängeln, aber die Ratschläge, dich lieber umzusehen, bevor du "Atmel über alles" rufst, solltest du ernst nehmen. W.S.
T. Baumbach schrieb: > Worin besteht denn bitte genau der Unterschied zwischen 'Atmel ICE' und > 'Atmel SAM-ICE' Der Atmel-ICE ist das aktuellste Tool und kann AVR und ARM. Der Atmel SAM-ICE ist einige Jahre älter. Ich bevorzuge auch, beim Atmel-Studio zu bleiben, einfach weil ich kein Problem damit habe, es nicht eingeschränkt ist und kostenlos. Früher habe ich auch mal Makefiles geschrieben und den GCC von der Kommandozeile aus aufgerufen, in den 90er Jahren des letzten Jahrhunderts war das halt noch so... Mich stört auch dabei nicht, dass ich die Hype-Controller STM32 nicht damit programmieren kann, da ich diese beruflich eh nicht gebrauchen kann, weil es die nicht als Automotive-Version gibt. Ein aktuelles XPlained hat auch den Debugger drauf der im Atmel-ICE steckt, ich bin aber auch gerade nicht sicher, ob das überhaupt vorgesehen ist, den für andere Target-Boards zu benutzen. Macht aber auch nicht wirklich was, die kleinen XPlained kosten doch nicht viel, anfangen kann man damit allemal. Wenn Atmel ICE, dann kann ich die Basic Version empfehlen. 2407172 bei Farnell.
> Die ermäßigte EDU Version (50€) hat außer der Tatsache daß man Dir > blind(!) vertraut daß Du sie nur zur persönlichen Weiterbildung oder zu > Hobbyzwecken einsetzen wirst keinerlei Beschränkungen im > Funktionsumfang. Das stimmt nicht ganz. Mit der EDU-Version geht das flashen von Hex-Files nicht. Deshalb kann man ihn professionel nicht verwenden. (keine j-flash Unterstuetzung) Davon mal abgesehen ist es aber ein professionelles Tool. Soll heissen funktioniert sehr zuverlaessig, schnell und stabil. Das kann nicht jeder Debugger von sich behaupten. Etwas nervig ist vielleicht das man sich als erstes einen Adapter basteln muss da wohl kaum einer die 20polige-Arm-Buchse auf sein Board packen will weil die alleine schon fast so gross ist wie die meisten Boards. :-) Olaf
Hallo Rudolf R., danke das hilft mir sehr weiter! Ich denke dann bestell ich mir mal den Atmel-ICE. @W.S: Wo bitte habe ich "Atmel über alles" gerufen? Ich habe nur gesagt, dass ich Atmel-Produkte über Jahre kenne und gut damit zurecht komme. D.h. aber (uns so habe ich es auch geschrieben), dass es durchaus andere Hersteller gibt, deren IDE und/oder Entwicklungsboards in Teilen besser aber auch schlechter sein können. Danke nochmal an alle...
T. Baumbach schrieb: > Was ist denn so falsch, wenn man eine IDE und einen MCU Hersteller gut > kennt dabei zu bleiben? Weil man so oft nicht die optimale Lösung hinbekommt. Auch andere Mütter haben schöne Töchter. Wenn ich sehe, wie viele Leute hier CAN-Knoten mit Mega8 plus MCP2515 zusammenschrauben, wo ein PIC18F25K80 die platzmäßig kleinere und bauteilemäßig günstigere Lösung gewesen wäre... Oder Stichpunkt USB und dieses unsägliche VUSB: Es gibt Berichte von Leuten, die das bereut haben und auf einen PIC16F1454 (die günstigste Möglichkeit, ein Hardware USB Device zu realisieren) gegangen sind, und zwar ohne Mehrkosten... Zu den größeren AVRs: sie sind für das, was Du an Rechenleistung bekommst, einfach zu teuer. Für den Preis eines Mega 128 bekommst Du auch schon einen Cortex M3 von NXP, STM und anderen. Auch DAS gehört zu den Aufgaben eines Entwicklers. fchk
Frank K. schrieb: > Weil man so oft nicht die optimale Lösung hinbekommt. Naja, von einem Mega8 auf einen PIC zu wechseln ist dann eher nicht die optimale Lösung an sich, weil man dann eher keine PICs kennt. Von einem PIC auf einen AVR zu wechseln weil der AVR für eine Anwendung besser geeignet erscheint, wäre ebenso unsinnig. Frank K. schrieb: > Zu den größeren AVRs: sie sind für das, was Du an Rechenleistung > bekommst, einfach zu teuer. Für den Preis eines Mega 128 bekommst Du > auch schon einen Cortex M3 von NXP, STM und anderen. An Material-Wert stimmt das. Wenn man aber nur kleinste Stückzahlen hat, dann kostet einen die Einarbeitung in eine völlig neue Familie so viel, dass man sich locker zurück lehnen kann und darauf warten kann, dass man die Rechenpower wirklich mal für ein Projekt benötigt. Das juckt mich überhaupt nicht ob meine Controller sechs Euro das Stück kosten und was die Teile drum herum so kosten wenn ich zwei Geräte ausliefern soll mit vielleicht 30 Euro BOM. Der Kunde zahlt die 120 Stunden dazu und freut sich über das Ergebnis, 200+ Stunden um sich zusätzlich noch in eine neue Architektur einzuarbeiten sind dann eher nicht drin. Falls das mal reicht wenn man sich zusätzlich noch mit einer neuen Toolkette rumärgern muss. Und mit Rechenpower hatte ich bei den AVR noch gar keine Probleme. Im Gegenteil habe ich Bedenken wenn ich mir ansehe, was beim Pin-wackeln mit einem 48 MHz Cortex M0 so raus kommt. Alles eine Frage der Anwendung. Bei 100k Geräten im Monat hat man sicher ganz andere Probleme - aber als erstes bekommt man dann auch schon ganz andere Preise für seine Bauteile.
Rudolph R. schrieb: > Im Gegenteil habe ich Bedenken wenn ich mir ansehe, was beim Pin-wackeln > mit einem 48 MHz Cortex M0 so raus kommt. Das hängt nicht vom Core ab, sondern vom Chip drum herum. Mancher Hersteller bindet die GPIO über langsame Sekundärbusse an, andere direkt am Primärbus. Letzteres geht dann recht flott.
Olaf schrieb: > Mit der EDU-Version geht das flashen von > Hex-Files nicht. Deshalb kann man ihn professionel nicht verwenden. Das ist nicht wahr. Du kannst im J-Link commander den Befehl loadbin verwenden um ein beliebiges Speicherabbild an eine beliebige Adresse zu flashen (und anschließend verifizieren), auch mit gleichzeitigem Setzen der Security-bits. Das kann man auch schön in ein Batchfile einbauen. Du kannst auch die mitgelieferte dll verwenden und die in Dein eigenes Produktions-Automations-Steuerungsprogramm einbinden und von dort die Funktion zum Flashen direkt aufrufen wenn Dein Produktions-Roboter die Platine kontaktiert hat. Geht auch. Allerdings wenn Du sowas gebaut hast dann hast Du auch die Kohle für eine j-Flash Lizenz. Zum mal eben 5 Platinen von Hand Flashen hab ich ne 3-zeilige Batch-Datei mit Endlosschleife: Tag-Connect draufhalten, Leertaste drücken, 1 Sekunde warten, nächster. Geht mit dem EDU.
:
Bearbeitet durch User
Rudolph R. schrieb: > 200+ Stunden um sich zusätzlich noch in eine neue Architektur > einzuarbeiten sind dann eher nicht drin. Das macht man nebenher, zuhause im Hobbykeller, aus persönlicher Begeisterung und Interesse für die Technik. Die hast Du doch, oder?
Bernd K. schrieb: >> 200+ Stunden um sich zusätzlich noch in eine neue Architektur >> einzuarbeiten sind dann eher nicht drin. > > Das macht man nebenher, zuhause im Hobbykeller, aus persönlicher > Begeisterung und Interesse für die Technik. Die hast Du doch, oder? Ja, na klar, ich würde sonst nicht machen was ich mache. :-) Nur, ohne Grund ist das witzlos und bisher fehlt mir auch die Controller-Familie auf die ich umsteigen könnte und wollen würde. Ein SAMC21 XPlained habe ich mir schon besorgt, die sind zwar nicht Automotive, dafür mit CAN-FD (1.0) und die könnten einen Übergang zu den SAMV70 einleiten. Nur, muss ich das unbedingt haben? Nein. Meine aktuellen Projekte laufen mit ATMega324PA und ATMega16M1. Dazu mal 90CAN32, Mega88PA und Mega164PA. So richtig ausgelastet sind die aber nicht. Nice-to-have wäre da mal sowas wie ein MPC5602 oder ein RH850 im 64 Pin Gehäuse mit 0,5 mm Pitch und zwei CANs. Oder in nicht mehr allzu ferner Zukunft eben ein SAMV70. AVR32 wäre auch nett gewesen, aber sieht einfach zu tot aus. Also umsehen ja, aber nicht um jeden Preis.
Bernd K. schrieb: > Olaf schrieb: >> Mit der EDU-Version geht das flashen von >> Hex-Files nicht. Deshalb kann man ihn professionel nicht verwenden. > > Das ist nicht wahr. Du kannst im J-Link commander den Befehl loadbin > verwenden um ein beliebiges Speicherabbild an eine beliebige Adresse zu > flashen (und anschließend verifizieren), auch mit gleichzeitigem Setzen > der Security-bits. Das kann man auch schön in ein Batchfile einbauen. Warum widersprichst du eigentlich? Ich habe selber einen EDU und ich weiß definitiv, daß damit das Standalone-Flashen NICHT geht mangels Lizenz. Natürlich kann ich aus ner IDE das Debuggen starten und zu diesem Zweck geht auch das Flashen, aber das ist ne andere Kiste - solltest du verstehen. Allerdings ist es bei Leuten, die ohnehin die Vollversion haben, egal, was für Lizenzen im Adapter gespeichert sind, denn diese Leute haben die Lizenzen auch auf ihrem PC und ab da geht natürlich alles. Kostet bloß mehr, als man als privater Bastler auszugeben geneigt ist. Genau deshalb erwähne ich ja immer wieder die Bootlader, wo man als Bastler frei von Problemen dieser Art ist. W.S.
T. Baumbach schrieb: > Aber ich weiß hat immer noch nicht den Unterschied zwischen den > beiden!?! Der SAM-ICE ist weiter nichts als eine auf Atmel-ARMs limitierte Version des Segger J-Link. Das Atmel-ICE dagegen ist der Nachfolger des JTAGICE3. Für dich als Atmel-Anwender wäre dabei ggf. ein Vorteil, dass du es für ARMs (von Atmel) und AVRs gleichermaßen benutzen kannst. Ansonsten, siehe Axel Schwenkes Rat: um nur mal den Einstieg zu bekommen, kannst du eins der Xplained-Pro-Boards benutzen, die den Debugger gleich on-board haben. Der nennt sich bei Atmel EDBG und ist eine eingebaute Miniversion des Atmel-ICE (benutzen beide den gleichen AVR32 UC3). Weil oben die Eclipse-Einbindung des Segger J-Link (bzw. SAM-ICE) genannt worden ist: es würde mich wundern, wenn diese über irgendetwas anderes als OpenOCD erfolgt. Wenn dem aber so ist, dann sollten auch EDBG oder Atmel-ICE genauso einbindbar sein, denn auch sie werden von OpenOCD unterstützt.
:
Bearbeitet durch Moderator
W.S. schrieb: > Warum widersprichst du eigentlich? Weils nicht wahr ist was Du sagst. > Ich habe selber einen EDU und ich > weiß definitiv, daß damit das Standalone-Flashen NICHT geht Ich habe auch zwei (ein V8 und ein V9) und es geht mit beiden. Und zwar indem ich dazu den J-Link-Commander verwende (jlink.exe) mit den Befehl loadbin <speicharabbild.bin> <startadresse> Das kann man auch schön ins Makefile packen (make install), oder in ne separate Batchdatei.
:
Bearbeitet durch User
Jörg W. schrieb: > Weil oben die Eclipse-Einbindung des Segger J-Link (bzw. SAM-ICE) > genannt worden ist: es würde mich wundern, wenn diese über irgendetwas > anderes als OpenOCD erfolgt. Wenn dem aber so ist, dann sollten auch > EDBG oder Atmel-ICE genauso einbindbar sein, denn auch sie werden von > OpenOCD unterstützt. Ich nutze immer den Segger GDB Server mit dem J-Link, kein OpenOCD und das klappt sehr gut (Eclipse).
Angehängte Dateien:
-
Debug_Configurations__097.png
140 KB -
Debug_Configurations__098.png
140 KB
Jörg W. schrieb: > Weil oben die Eclipse-Einbindung des Segger J-Link (bzw. SAM-ICE) > genannt worden ist: es würde mich wundern, wenn diese über irgendetwas > anderes als OpenOCD erfolgt. Falsch geraten (siehe Bild) Dieses Plugin (Teil von GNUARM Eclipse) ist speziell für den J-Link.
Olaf schrieb: > Das stimmt nicht ganz. Mit der EDU-Version geht das flashen von > Hex-Files nicht. Deshalb kann man ihn professionel nicht verwenden. > (keine j-flash Unterstuetzung) Das wiederum stimmt auch nicht ganz. Flashen geht, brauchts Du nur hex2bin und schon kannst Du Bin Flashen. Und das geht mit jlink problemlos. rgds
Bernd K. schrieb: > W.S. schrieb: >> Warum widersprichst du eigentlich? > > Weils nicht wahr ist was Du sagst. > >> Ich habe selber einen EDU und ich >> weiß definitiv, daß damit das Standalone-Flashen NICHT geht > > Ich habe auch zwei (ein V8 und ein V9) und es geht mit beiden. Und zwar > indem ich dazu den J-Link-Commander verwende (jlink.exe) mit den Befehl > > loadbin <speicharabbild.bin> <startadresse> > > Das kann man auch schön ins Makefile packen (make install), oder in ne > separate Batchdatei. Soviel ich mitbekommen habe, kann die EDU eine .bin (1:1 Speicherabbild) auf den internen Speicher via Jtag/SWD flashen. z.B. arm-objcopy macht aus einer .hex eine .bin. Mit JFlash kann man zusätzlich noch externe Flash-Bausteine programmieren. Kann gut sein, dass ich falsch liege, bzw. dass es noch mehr Unterschiede gibt. Letztendlich reicht mir der loadbin-Befehl. Die IDEs greifen da z.T. per gdb drauf zu.
6a66 schrieb: > brauchts Du nur hex2bin Kannst auch direkt beim Build mit objcopy gleich ein .bin aus dem .elf erzeugen lassen, und das wiederum ist wahrscheinlich eh in den meisten Beispiel-Makefiles die man so findet schon eingebaut. Oder falls man mit Makefiles auf Kriegsfuß steht einfach in der IDE in den Toolchain-Settings .bin als Ausgabeformat wählen.
Bernd K. schrieb: > Dieses Plugin (Teil von GNUARM Eclipse) ist speziell für den J-Link. OK, aber über den GDB-Server von Segger. Damit sollte man das auch auf ein OpenOCD anpassen können – würde mich andererseits wundern, wenn es das nicht auch schon gäbe. Vorteil von OpenOCD ist, dass man mit der gleichen Software eine riesige Palette von JTAG- (und SWD-)Adaptern auf einen Schlag bedienen kann, statt jedem Tierchen sein Plässierchen geben zu müssen. Das reicht von „dummen“ Bitbangern (bspw. auf Basis eines FT2232) bis hin zu Atmel-ICE oder Segger J-Link. (Allerdings, wenn mich nicht alles täuscht, können die FT2232-basierten Teile bislang nur JTAG, kein SWD.)
Jörg W. schrieb: > OK, aber über den GDB-Server von Segger. Damit sollte man das auch > auf ein OpenOCD anpassen können – würde mich andererseits wundern, > wenn es das nicht auch schon gäbe. oocd hat glaub ich die Möglichkeit einen J-Link zu bedienen aber ich hab das als ichs mal probieren wollte partout nicht hinbekommen (war allerdings damals kein echter J-Link sondern ein J-Link-lite auf nem Demo-Board). Jedoch da zum Glück der JLinkGDBServer (und auch alle anderen J-Link tools) auch für Linux-x86 verfügbar sind und Eclipse das so vorbildlich und vollständig integriert daß man echt nur noch auf "neu" und "OK" klicken muss und die Konfiguration steht und funktioniert ist das ne feine Sache und ich bin glücklich damit. Obwohl ich normalerweise Open-Source immer vor gleichwertigem Closed-Source den Vorzug gebe muss ich in diesem Falle uneingeschränkt zugestehen daß das Zeugs von Segger eine wirklich feine runde Sache ist und Spaß macht. oocd verwende ich um damit mit meinem STM32-Nucleo Board zu sprechen. Geht auch einwandfrei, ebenfalls unter Linux und ebenfalls ohne Verrenkungen out-of-the-box.
Bernd K. schrieb: > oocd hat glaub ich die Möglichkeit einen J-Link zu bedienen Ja, funktioniert genauso klaglos wie mit dem Atmel-ICE (oder dem EDBG der Xplained Pro). FT2232-Adapter habe ich auch schon mal damit getestet, da muss man ein wenig mehr konfigurieren, ging aber auch. Als ich das letzte Mal die Segger-Tools in der Hand hatte (in Verbindung einem SAM-ICE), funktionierte der ganze Salat überhaupt nicht. OK, nicht auf Windows sondern Linux, aber ich wollte den Herstellertools damals schon den Vorrang geben (war auf einem Lehrgang), hab dann entnervt aufgegeben und mich lieber in die Konfiguration von OpenOCD reingefummelt. Das klappte dann wenigstens. Ist ein paar Jahre her, aber seither habe ich die Segger-Software selbst nie wieder angeguckt. ;-)
Bei den Discovery Board ist schon ein Programme drauf, mit dem kann man auch andere STM32 programmieren. Die Bord gibt es ab 10 EUR. Dann gibt es auch noch den ST-Link Programmer für etwa 22 EUR. Ein ARM von einem Herstellers genau zu kennen/anzuwenden ist nicht leicht so dass man nicht immer wechseln will, damit bleibt man dann meist bei einem Hersteller. Welchen Vorteil bringt denn der Seger JLink gegenüber einen STLink wenn man beim STM32 bleiben will?
>Welchen Vorteil bringt denn der Seger JLink gegenüber einen STLink wenn >man beim STM32 bleiben will? der Segger ist beim Flashen und SWO deutlich schneller. Laut Tests ist der ST-Link der langsamste von allen ARM Cortex-M Programmern, aber als Nucleo Board auch der günstigste ohne gleich zum Frickel zu werden. Gruß, dasrotemopped.
Bernd K. schrieb: > W.S. schrieb: >> Warum widersprichst du eigentlich? > > Weils nicht wahr ist was Du sagst. > >> Ich habe selber einen EDU und ich >> weiß definitiv, daß damit das Standalone-Flashen NICHT geht > > Ich habe auch zwei (ein V8 und ein V9) und es geht mit beiden. Und zwar > indem ich dazu den J-Link-Commander verwende (jlink.exe) mit den Befehl > > loadbin <speicharabbild.bin> <startadresse> Merkst du eigentlich noch was? Ich hab geschrieben, daß das Standalone-Flashen nicht geht und das IST WAHR. Punkt. Was du beschreibst, ist genau DAS, was als Vorbereitung für das Debuggen gemacht wird. Das ist was anderes - was ich ebenfalls schrieb. Grob gesagt: keine Lizenz für J-Flash. Bevor du in die Tasten haust, solltest du vielleicht erstmal lesen, was da steht. W.S.
Bernd K. schrieb: > Kannst auch direkt beim Build mit objcopy gleich ein .bin aus dem .elf > erzeugen lassen, und das wiederum ist wahrscheinlich eh in den meisten > Beispiel-Makefiles die man so findet schon eingebaut. Oder falls man mit > Makefiles auf Kriegsfuß steht einfach in der IDE in den > Toolchain-Settings .bin als Ausgabeformat wählen. Danke :) Bei uns ist aber default HEX eingestellt - muss ich halt nacharbeiten. W.S. schrieb: > Merkst du eigentlich noch was? > Ich hab geschrieben, daß das Standalone-Flashen nicht geht und das IST > WAHR. Punkt. Das ist bei mir in einem Batch drinnen der erst hex2bin't, dann löscht, dann flasht und denn verifiziert. Geht super, ich weiß es ginge auch kürzer. Wo ist das Problem? Oder was meinst Du mit "standalone"? rgds
Jörg W. schrieb: > Als ich das letzte Mal die Segger-Tools in der Hand hatte (in > Verbindung einem SAM-ICE), funktionierte der ganze Salat überhaupt > nicht. Naja.. es ist eben nicht jedes OS für jede Aufgabe geeignet. Bedenke bitte, daß es nicht Segger's eigentlicher Broterwerb ist, sich mit den gefühlten 100 verschiedenen grafischen Frontends von Linux, FreeBSD und Konsorten herumzuschlagen. Da ist es durchaus verständlich, daß deren Software eben für Windows geschrieben wurde und Portierungen nach Linux etc. eben eher experimentell sind. W.S.
noch einer, der nicht lesen will: 6a66 schrieb: > Oder was meinst Du mit "standalone"? na das, was ich geschrieben habe: W.S. schrieb: > Grob gesagt: keine Lizenz für J-Flash. W.S.
W.S. schrieb: > Ich hab geschrieben, daß das Standalone-Flashen nicht geht und das IST > WAHR. Punkt. > > Was du beschreibst, ist genau DAS, was als Vorbereitung für das Debuggen > gemacht wird. Das ist was anderes - was ich ebenfalls schrieb. Wahrscheinlich wird hier tatsächlich aneinander vorbei geredet, aber wo ist der Unterschied für dich? Keine Lizenz für J-Flash hast du natürlich recht aber in beiden Fällen starte ich eine Software und das Flash ist beschrieben, also was ist in diesem Fall für dich anders bzw. Standalone?
W.S. schrieb: > Bedenke bitte, daß es nicht Segger's eigentlicher Broterwerb ist, sich > mit den gefühlten 100 verschiedenen grafischen Frontends von Linux, > FreeBSD und Konsorten herumzuschlagen. Ich brauche keine 100 grafischen Frontends. Aber wenn OpenOCD es schafft, mehrere Dutzend verschiedene Programmer auf allen gängigen OSen sauber zu bedienen (u. a. auch den J-Link), dann muss ich Segger für ihre private Bastellösung nicht übern grünen Klee loben. Mir sind generische Tools ohnehin am liebsten, sollte morgen ein Kunde einen ARM eines anderen Herstellers unterstützt haben wollen, dann muss ich meinen Workflow nicht gleich komplett umstellen (und selbst vom Workflow mit AVR oder MSP430 unterscheidet er sich nur durch die Namen der GDB-Server, die ich aufrufen muss). Aber deren Linux-Support ist ja offenbar gegenüber damal besser geworden, für die Freunde der grafischen Gimmicks.
Jörg W. schrieb: > Ich brauche keine 100 grafischen Frontends. Agree, ich auch nicht. Mir reicht das EINE von Windows völlig aus. Aber lassen wir das... Naja, und OpenOCD ist aus meiner Sicht ein einziger Krampf. Da ist ja sogar das Coocox-Brennprogramm noch eleganter... Aber wir leben in getrennten Welten, in meiner sind Anwendungen das A und O und in deiner sind es stattdessen Tools und Scripte. Das sind zwei völlig unterschiedliche Denkwelten. Aber deine Vorstellung, daß du dir ein generisches Programm wünschst, ist völlig illusorisch. Dazu müßte es nicht nur ein generell einheitliches Transportmittel wie SWD geben, sondern auch generell einheitliche Programmieralgorithmen und einheitliches Kommunikationsprotokoll zwischen PC und Adapter(n). Und das zusammen ist das Illusorische. Stattdessen braucht es für jeden Hersteller, jeden Chiptyp, jede Chiptyp-Variante ein spezielles, darauf angepaßtes Stück Programm und für jeden verdammten Adapter ein anderes Protokoll. Segger kann das mit den Algorithmen stemmen, teuer genug sind die ja, aber für OpenOCD? Die können ja nicht mal den ULink2 und die Ziel-Chip-Auswahl ist doch relativ mickrig. Ist ja auch zu verstehen, das ganze macht ne Menge Arbeit und wer soll die bezahlen - du etwa? Am ehesten ginge dein Wunsch mittels fest im µC eingebautem Bootlader, der eine Umsetzung zwischen Hardwarebedingungen und einheitlichem API erledigen könnte. Ja, Konjunktiv. Unter so einen einheitlichen Hut kriegt man die Hersteller nie und nimmer. Nicht mal die beiden Bootlader-Größen NXP und ST sind da bisher zusammengekommen. Und du wünschst dir eine generische Brenn-Applikaton. W.S.
W.S. schrieb: > OpenOCD? Die können ja nicht mal den ULink2 und die Ziel-Chip-Auswahl > ist doch relativ mickrig. Ich seh' schon, wir leben in getrennten Welten. OpenOCD kann außer AVRs (weil deren Programmieralgorithmus nicht veröffentlicht ist) allen Furz und Feuerstein (auch vieles weit jenseits der ARM-Welt) programmieren mit mehreren Dutzend verschiedenen Adaptern. Neuere ULink2 (mit CMSIS-DAP Firmware) sollten übrigens auch unterstützt sein. Für die alten isses einfach nur das übliche Dilemma: wenn Keil keine Lust hat, das Protokoll zu beschreiben und sonst niemand Veranlassung, es zu reverse engineeren, dann mangelt es eben an 3rd-Party-Support für solche Tools. Aber das das für dich alles „mickrig“ ist, brauchst du sowas einfach auch nicht. Deine Entscheidung – so, wie ich meine für mich treffen kann. Nebenbei fand ich noch in einem alten Artikel der OpenOCD-Mailingliste, dass möglicherweise das SAM-ICE zusammen mit OpenOCD gar nicht nur auf die Atmel-ARMs limitiert ist. Keine Ahnung, ob dem so ist, habe gerade keinen anderen ARM da, um es zu testen. > Und du wünschst dir eine generische Brenn-Applikaton. Ich wünsch' sie mir nicht nur, sondern mit OpenOCD habe ich sie. ;-) (OK, AVRs und MSP430 außen vor, aber bei ersteren komme ich mit den vorhandenen gut genug zurecht, letztere waren nur mal eine Episode am Rande, weil's ein Kunde unbedingt so wollte.)
:
Bearbeitet durch Moderator
Jörg W. schrieb: > ann muss ich Segger > für ihre private Bastellösung WTF??? Segger hat eine Bastellösung? Ich bring dich mal auf den aktuellen Stand: J-Link ist der de-facto Industriestandard. Jede IDE unterstützt J-Link oder sie taugt nichts. J-Link Software ist für alle gängigen OS verfügbar. J-Link (für den kommerziellen Einsatz) ist schweineteuer, dafür aber dennoch jeden Cent wert, denn es unterstützt jeden ARM-Controller unter dieser Sonne und die Software von Segger ist erste Sahne. Das ist die Meßlatte, nicht umgekehrt. Dagegen wirkt OOCD mit seinen läppischen (gefühlt 3 bis 5) verschiedenen Conrollern die es unterstützt wie eine Bastellösung. Da helfen auch nicht die 100 verschiedenen Frickelport-Treiber nicht die es beinhaltet.
W.S. schrieb: > Ich hab geschrieben, daß das Standalone-Flashen nicht geht und das IST > WAHR. Punkt Nein, falsch. Ich hab Dir oben erklärt daß das mit jlink.exe ganz hervorragend geht. In der Software-Suite sind mindestens 3 verschiedene Tools und eine DLL-Library enthalten mit denen man Standalone (was meinst Du damit überhaupt?) flashen kann, als da wären: Kostenlos (EDU) * Der GDBServer (für den Debugger, in der IDE) * Der Commander (für Batchfiles in der Produktion) * Die DLL (für eigene Anwendungen in der Produktion) Kostenpflichtig * J-Flash Ich wüsste nicht was J-Flash für einen Mehrwert gegenüber dem Commander bieten soll, evtl ist es nochmal ne halbe Sekunde schneller als der Commander aber wer so viele Controller am Tag flasht daß sich das auswirkt wird das eh aus der Portokasse zahlen können. Alle anderen Hobbyisten und Studenten können problemlos mit den Commander und ner Batchdatei shell-script Makefile flashen. Sowohl standalone als auch verheiratet und sogar geschieden funktioniert das ohne Probleme.
Bernd K. schrieb: > die Software von Segger ist erste Sahne. Darin unterscheiden sich halt unsere Ansichten diametral. Diese Software ist das, was ich mit „Bastellösung“ meinte. Die Hardware ist OK, wenngleich überteuert und mittlerweile doch etwas klobig wirkend. (Ist mittlerweile eigentlich wenigstens ein Adapter auf den 10poligen 1,27-mm-Cortex-M-Stecker dabei, den ARM selbst so normiert?) > Dagegen wirkt OOCD mit seinen läppischen (gefühlt 3 bis 5) verschiedenen > Conrollern die es unterstützt OK, das beweist hinreichend, dass du OpenOCD gar nicht kennst. Damit müssen wir auch nicht weiter diskutieren.
:
Bearbeitet durch Moderator
> Darin unterscheiden sich halt unsere Ansichten diametral. > Diese Software ist das, was ich mit „Bastellösung“ meinte. Tut mir Leid Joerg, aber das halte ich fuer ziemlichen Unsinn. Hast du schonmal zwei Programmieradapter gleichzeitig benutzt? Mit J-Link geht. Ist jetzt praktisch wenn man Kommunikation zwischen zwei Controllern entwickelt. Oder einen Debugger ueber TCP/IP angebunden? Ist sehr praktisch fuer die Produktion. Oh...und die Geschwindigkeit ist natuerlich auch ganz nett. Und bisher hat Segger bei mir IMMER absolut stabil und sehr zuverlaessig funktioniert. Bastelloesungen kenne ich nur von anderen. Olaf
Jörg W. schrieb: >> Dagegen wirkt OOCD mit seinen läppischen (gefühlt 3 bis 5) verschiedenen >> Conrollern die es unterstützt > > OK, das beweist hinreichend, dass du OpenOCD gar nicht kennst. Damit > müssen wir auch nicht weiter diskutieren. Umgekehrt wird ein Schuh draus: Die drei Mainstream-Controller die Du je damit benutzt hat wurden zufällig von OOCD unterstützt und du hast Glück gehabt. Und deswegen sind jetzt bei Dir die kommerziellen Tools die wirklich out-of-the-box jeden noch so exotischen Controller unterstützen, das sind dann bei Dir Bastellösungen. Verkehrte Welt in der Du da lebst.
Olaf schrieb: > Hast du schonmal zwei Programmieradapter gleichzeitig benutzt? Ja, regelmäßig. Auch schon vier, aber das war noch mit AVR (JTAGICEmkII + AVaRICE). > Mit > J-Link geht. Mit OpenOCD auch, natürlich nur, sofern man sie unterscheiden kann (typischerweise anhand der USB-Seriennummer). > Oder einen Debugger ueber TCP/IP angebunden? Ja, GDB arbeitet gegen den Server immer über TCP (OK, rein seriell könnte er auch noch, hat mittlerweile aber kaum noch Relevanz), und OpenOCD ist halt ein GDB-Server (Segger hat auch einen eigenen, weiß ich). IPv6 ist bei OOCD derzeit noch nicht drin. Wenn ich's brauchen würde (war letztens kurz davor), würde ich es wohl mal implementieren. > Oh...und die Geschwindigkeit ist > natuerlich auch ganz nett. Dürfte aber auch eher ein Problem der Hardware sein. Und auch hier nochmal: OOCD hat überhaupt kein Problem mit dem Segger-Teil. Hab' ich schon benutzt, geht genauso unproblematisch wie ein beliebiger anderer Adapter. Und nein, die einfachen Bitbanger würde ich mittlerweile auch eher nicht mehr nehmen.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Die Hardware ist OK, wenngleich überteuert und mittlerweile doch > etwas klobig wirkend. ?? Überteuert? Schon mal geschaut was Produkte von Mitbewerbern kosten? Was meinst du mit klobig? Den J-Link an und für sich? Bei Smartphones verstehe ich ja noch wenn es so dünn wie möglich sein muss aber trägst du deinen J-Link in der Hostentasche spazieren? ;-) Wenn es um den 20 Pin JTAG Adapter geht... der ist halt Standard. aber du musst den ja nicht benutzen, du kannst ja auch alles andere an den J-Link dran klemmen, https://www.segger.com/jlink-adapters.html.
Jörg W. schrieb: > Bernd K. schrieb: >> die Software von Segger ist erste Sahne. > > Darin unterscheiden sich halt unsere Ansichten diametral. > > Diese Software ist das, was ich mit „Bastellösung“ meinte. Si tacuisses, philosophus mansisses... Jörg, jetzt läßt du aber die Hosen gewaltig runter. Jeder hier im Forum, der ernsthaft mit den Seggerschen Produkten arbeitet und auch das OpenOCD-Projekt in Augenschein genommen hat weiß, was du da für eine völlig verstiegene Ansicht postest. Jetzt bist du in der Lage der Katze, die nicht mehr weiß, wie sie mit Anstand wieder von dem Baum runterkommt, auf den sie in ihrer Unkenntnis der Dinge sich verstiegen hat. Vielleicht solltest du etwas bedächtiger deine Ansichten formulieren und weniger markige Sprüche verbreiten, gelle? W.S.
Guest schrieb: > ?? Überteuert? Schon mal geschaut was Produkte von Mitbewerbern kosten? Ein Atmel-ICE kostet 60 Euro. Hat aber bei Atmel auch ewig gedauert, bis sie endlich mal von ihrem hohen Ross runter waren. Die Vorgänger wollten sie immer noch für 300 verkaufen, natürlich immer mit dem Etikett “low cost” versehen. ;-) Kann sein, dass das J-Link noch ein paar Gimmicks mehr hat, aber im Großen und Ganzen sind die Teile durchaus vergleichbar. Dass Atmel sein ICE nur für die Atmel-ARMs unterstützen will, hat ja nichts mit den Kosten für eine derartige Hardware zu tun. Ein ST-LINK kostet gerade mal 20 Euro. Ein LPC-LINK2 kostet nur wenig mehr, es gibt sogar eine J-Link-Firmware dafür … Klar, das J-Link ist das einzige herstellerübergreifende Tool dabei, aber den Vorteil kann man auch nur nutzen, wenn man tatsächlich herstellerübergreifend arbeitet. Kann sein, dass das Teil bei richtig großen ARMs ein paar Vorteile bietet, aber hier war ja nach Cortex-M0 gefragt. Da sehe ich außer der Herstellerunabhängigkeit keinen weiteren Vorteil für das J-Link. > Was meinst du mit klobig? Den J-Link an und für sich? Ja. > Bei Smartphones > verstehe ich ja noch wenn es so dünn wie möglich sein muss aber trägst > du deinen J-Link in der Hostentasche spazieren? ;-) Nö, aber der Kram, den man auf dem Tisch rumliegen hat, wird ja auch kleiner mit der Zeit. Wenn der Programmierdongle dann genauso groß ist oder größer als die Ziel-Applikation, dann ist die Gefahr groß, dass er mit dem Target (mechanisch) Katz' und Maus spielt. > Wenn es um den 20 Pin JTAG Adapter geht... der ist halt Standard. Beim Cortex-M nicht mehr, da ist der kleine 10-Pinner von ARM propagiert (als 9-Pin bei Segger bezeichnet, wegen des weggelassenen Pins für die Richtungserkennung). http://infocenter.arm.com/help/topic/com.arm.doc.faqs/attached/13634/cortex_debug_connectors.pdf Man kann die kleinen Teile ja gut finden oder nicht, aber es ist halt der, den ARM dafür genormt hat (so wie den großen 20poligen seinerzeit auch).
:
Bearbeitet durch Moderator
W.S. schrieb: > Jetzt bist du in der Lage der Katze, die nicht mehr weiß, wie sie mit > Anstand wieder von dem Baum runterkommt, auf den sie in ihrer Unkenntnis > der Dinge sich verstiegen hat. Warum? Du postest hier seit Jahr und Tag zweifelhafte Ansichten, da werde ich mir wohl mal eine leisten können, die andere für zweifelhaft halten. Dass die Formulierung sehr provokant war, ist mir natürlich klar ;-), aber ich steh' da dahinter. Mit dem J-Flash bin ich hinten und vorn nicht klar gekommen, sowas entspricht einfach nicht meiner Arbeitsweise.
:
Bearbeitet durch Moderator
Bernd K. schrieb: > Nein, falsch. Ich hab Dir oben erklärt daß das mit jlink.exe ganz > hervorragend geht. In der Software-Suite sind mindestens 3 verschiedene > Tools und eine DLL-Library enthalten mit denen man Standalone (was > meinst Du damit überhaupt?) flashen kann, als da wären: Ich habe das DEDIZIERT geschrieben, also nochmal: 1. ich starte J-Flash 2. ich benutze J-Flash 3. ich beende J-Flash. Und beim J-Link-Edu funktioniert Nr. 2 NICHT. War das jetzt deutlich genug? W.S.
W.S. schrieb: > Ich habe das DEDIZIERT geschrieben, also nochmal: > > 1. ich starte J-Flash > 2. ich benutze J-Flash > 3. ich beende J-Flash. > > Und beim J-Link-Edu funktioniert Nr. 2 NICHT. > War das jetzt deutlich genug? 1. Ich starte J-Link Commander 2. Ich benutze J-Link Commander 3. Ich beende J-Link Commander Selbes Ergebnis. Wie ich weiter vorne aufgezählt habe gibt es mehrere verschiedene eigenständige Tools mit denen man außerhalb der IDE flashen kann und nur ein einziges davon braucht eine Lizenz, alle anderen sind kostenlos. Das widerspricht also eindeutig Deiner Aussage man könne mit dem EDU nicht standalone flashen.
Bernd K. schrieb: > Das widerspricht also eindeutig Deiner Aussage man könne mit dem EDU > nicht standalone flashen. Nun lass doch mal. Er hat das ausschließlich auf das J-Flash-Tool bezogen, das wissen wir ja nun, und dieses Tool (welches ich etwas provokant als „private Bastellösung“ tituliert habe) hat es ihm ganz offenbar so sehr angetan, dass alles andere in seinen Augen halt keine praktikable Lösung ist. Ansonsten ist das ja mittlerweile ausreichend hin und her gekaut worden, was die EDU-Variante kann und was nicht. Vom legalen Aspekt her ist es aber offenbar nicht statthaft, mit dieser kommerziell zu arbeiten.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Klar, das J-Link ist das einzige herstellerübergreifende Tool dabei, > aber den Vorteil kann man auch nur nutzen, wenn man tatsächlich > herstellerübergreifend arbeitet. Kann sein, dass das Teil bei > richtig großen ARMs ein paar Vorteile bietet, aber hier war ja nach > Cortex-M0 gefragt. Da sehe ich außer der Herstellerunabhängigkeit > keinen weiteren Vorteil für das J-Link. Jain, im Prinzip gebe ich dir Recht aber es gibt da viele Features beim J-Link, die es nicht bei anderen gibt (RTT, SWO Viewer, J-Scope, J-Link Debugger, Unlimited Flash Breakpoints, Unterstützt von fast allen IDEs, ...). Man muss aber einfach sehen, das es nicht das eine beste Werkzeug gibt sondern jeder einen anderen Workflow und Ansprüche hat und deshalbe gerne ein anderes Werkzeug einsetzt.
Guest schrieb: > Jain, im Prinzip gebe ich dir Recht aber es gibt da viele Features beim > J-Link, die es nicht bei anderen gibt (RTT, SWO Viewer, J-Scope, J-Link > Debugger, Unlimited Flash Breakpoints, Unterstützt von fast allen IDEs, > ...). OK, ich denke zwar, dass dieses oder jenes davon auch anderswo da ist, aber in der Summe natürlich ein netter Satz Features sind.
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.