Hallo, meine Frage deutet sich im Titel ja schon an - ich bin allerdings sehr verwundert, dass ich dazu nichts weiter finden kann. Daher schreibe ich jetzt hier. Folgendes Szenario: Ich nutze überwiegend Linux und MacOSX mit der avr-gcc toolchain inkl. avrdude. Ich möchte damit XMegas programmieren. Nun bin ich auf der Suche nach einem Programmieradapter. Ich habe bereits einen LUFA-basierten AVRISP mkII-clone von "barion-st.com", den ich auf Ebay gekauft hatte. Damit habe ich vor einiger Zeit auch schonmal flashen können. Ich musste damals avrdude 5.11 verwenden, weil die LUFA-Programmer unter avrdude 6.x nicht mehr funktionieren. Inzwischen habe ich ne Weile nichts mehr mit XMegas gemacht. Jetzt habe ich meinen Xmega mal wieder rausgekramt und musste feststellen, dass ich weder unter Ubuntu noch unter MacOSX mit diesem Programmer arbeiten kann. Die üblichen Problemstellen habe ich bereits angeschaut, d.h. udev rules, die LUFA-avrdude Firmware auf den Programmer flashen, älte Versionen von avrdude verwenden, avrdude 6.0.1 patchen und selber bauen, etc. Nach zwei Tagen vergeblichem Probieren will ich jetzt einfach einen anderen Programmer kaufen. Nur welchen? Hier ist eine Liste mit Programmern, über die ich gestolpert bin: - Barion-st.com AVRISP mkII-clone - habe ich hier, bekomme ich aber nicht zum Laufen - DIAMEX ALL-AVR - läuft scheinbar ebenfalls nicht mit neueren avrdude Vesionen - OLIMEX AVRISP mkII adapter - ebenfalls LUFA-basiert; vermutlich kein Unterschied zu dem von Barion-St - AVR-Dragon - ziemlich teuer für ein Hobby und zudem anfällig für alle Arten von Problemchen (siehe AVR-Programmieradapter-Artikel hier auf der Webseite) - ATMEL-ICE (bare board) - kommt prinzipiell in Frage, wird aber scheinbar von avrdude (noch) nicht unterstützt. - Original AVRISP mkII - nicht mehr lieferbar oder überteuert So, und nun frage ich mich: Womit arbeitet ihr denn alle so? Kann doch nicht sein, dass XMega nur mit dem AVR_Studio nutzbar ist?! Vielen Dank, Johannes
> Kann doch nicht sein, ... Kann doch sein. Atmel mag wohl keine Nischenbetriebssysteme. Also leider: Windows in vm (keine Virtualbox wg USB). Atmel Studio (bei mir 6.2, weil altes Windows) und Atmel-ICE. Den Krampf mit printf und Rätselraten war ich so satt. Seitdem ist ein Debugger der geringste Hardwarelevel, den ich akzeptiere. Glücklicherweise ist Atmel diesbezüglich eingeknickt und verkäuft ein solides Kästchen für 50€. Nun sind die AVR wieder mit von der Partie. Ansonsten:
1 | avrdude -v |
2 | |
3 | avrdude: Version 6.1, compiled on Aug 26 2015 at 19:45:37 |
4 | |
5 | avrdude -c ? |
6 | |
7 | Valid programmers are: |
8 | ... |
9 | atmelice = Atmel-ICE (ARM/AVR) in JTAG mode |
10 | atmelice_dw = Atmel-ICE (ARM/AVR) in debugWIRE mode |
11 | atmelice_isp = Atmel-ICE (ARM/AVR) in ISP mode |
12 | atmelice_pdi = Atmel-ICE (ARM/AVR) in PDI mode |
13 | ... |
Danke für deine Nachricht; dass avrdude ab 6.1 den AtmelICE unterstützt, wusste ich gar nicht. Prima, dann sieht es so aus, als hätte ich was gefunden. Das blanke Board ist ja mit 40€ auch für Hobbyzwekce noch bezahlbar. Welches "solide Kästchen" für 50€ meinst du denn?
neuer PIC Freund schrieb im Beitrag #4386928: > (keine Virtualbox wg USB) Extension Pack installieren und USB läuft wunderbar.
> Welches "solide Kästchen" für 50€ meinst du denn? ATATMEL-ICE-BASIC-ND von dk. Ist mittlerweile aber teurer. 21€ mehr für ein Plastikgehäuse und ein schnödes Kabel. Da kann man das PCBA auch mit Tesa tapen und Kabel nach Bedarf selbst basteln. > Extension Pack installieren und USB läuft wunderbar. Hatte ich probiert. Vielleicht jetzt mit einer neueren Version. Programmieren hatte damals auch funktioniert, aber mit dem FW-Update des ATMEL-ICE war Sense. Qemu rettete die Linux-Ehre.
Johannes N. schrieb: > Folgendes Szenario: Ich nutze überwiegend Linux und MacOSX mit der > avr-gcc toolchain inkl. avrdude. Ich möchte damit XMegas programmieren. OK. > Nun bin ich auf der Suche nach einem Programmieradapter. Ich habe > bereits einen LUFA-basierten AVRISP mkII-clone von "barion-st.com", den > ich auf Ebay gekauft hatte. Damit habe ich vor einiger Zeit auch > schonmal flashen können. Ich musste damals avrdude 5.11 verwenden, weil > die LUFA-Programmer unter avrdude 6.x nicht mehr funktionieren. Das ist wohl ein Bug. Hab jetzt nicht gecheckt ob es da einen offiziellen Bugreport oder gar einen Fix gibt, aber ein Workaround findet sich hier: http://www.avrfreaks.net/forum/lufa-based-avrisp-mkii-doesnt-work-avrdude-601 > Inzwischen habe ich ne Weile nichts mehr mit XMegas gemacht. Jetzt habe > ich meinen Xmega mal wieder rausgekramt und musste feststellen, dass ich > weder unter Ubuntu noch unter MacOSX mit diesem Programmer arbeiten > kann. Die üblichen Problemstellen habe ich bereits angeschaut, d.h. udev > rules, die LUFA-avrdude Firmware auf den Programmer flashen, älte > Versionen von avrdude verwenden, avrdude 6.0.1 patchen und selber bauen, > etc. > > Nach zwei Tagen vergeblichem Probieren will ich jetzt einfach einen > anderen Programmer kaufen. Halte ich nicht für zielführend. Allerdings kann man dir gar nicht helfen, wenn du nicht mit mehr als "geht nicht" rüberkommst. Jörg Wunsch (der avrdude Maintainer) ist hier unterwegs und liest deinen Post sicher früher oder später. Noch zielführender wäre ein Bugreport deinerseits. Oder wenigstens eine Frage auf der avrdude Mailingliste. > So, und nun frage ich mich: Womit arbeitet ihr denn alle so? avrdude. Oder DFU (dfu-programmer) > Kann doch nicht sein, dass XMega nur mit dem AVR_Studio nutzbar ist?! Sicher nicht.
Hallo Axel, den Link kenne ich natürlich. Es gibt dazu bereits einen Bugreport: bug #40831 Natürlich habe ich den dafür nötigen Fix bereits ausprobiert und avrdude gepatcht und selber übersetzt. Es funktioniert aber nicht (Fehlermeldung ist genauso wie in dem Link, den du gepostet hast). Ich habe die Vermutung, dass mein Programmer einfach Mist ist. Wie ich schon schrieb: Er ging schonmal mit avrdude 5.11, aber selbst das klappt gerade nicht mehr. Wer weiß, was da kaputt ist... ich habs jetzt lange genug probiert. Meine Frage hier bezog sich ja nicht darauf, wie ich diesen speziellen Programmer zum Laufen bekomme - sondern womit ihr so arbeitet. Ich habe jetzt den ATMELICE bestellt. Damit kann ich mir sicher sein, dass zumindest die Hardware kein Murks ist. Das weiß man bei diesen ganzen billig-clones halt nicht. avrdude 6.1. habe ich mir eben von den sources gebaut und hoffe, dass es dann klappt. avrdude -c ? listet jedenfalls den ATMELICE (wie von "neuer PIC Freund" gepostet)
Johannes N. schrieb: <schnipp> > Ich habe jetzt den ATMELICE bestellt. Damit kann ich mir sicher sein, > dass zumindest die Hardware kein Murks ist. Ja gut. Das ist der klassische Trade-off. Man kann ein Problem entweder mit Geld bewerfen, damit es weggeht. Oder man investiert Zeit um die Ursache zu finden und zu beheben. Anscheinend hast du zu wenig Zeit. Oder Ehrgeiz ;)
Hallo Axel, Kein Grund, polemisch zu werden. Ich weiß ja nicht, wie das bei dir ist... Aber meine Zeit ist sehr rar geworden und die investiere ich dann lieber in ein Projekt an dem ich Spaß habe. Das studenlange neu-Übersetzen und Ausprobieren von Patches und Hacks gehört für mich nicht dazu. Hätte ich mehr Zeit, wäre das vielleicht anders. Momentan ist mir meine Freizeit mehr Wert, als die 40€ für den ATMELICE. Zumal der sein Geld sicherlich auch unabhängig davon Wert ist. Das grundlegende Problem der LUFA-basierten Programmer scheint laut bugtracker ja behoben zu sein und wird sicherlich in einer der nächsten avrdude Versionen eingepflegt werden. Es entsteht also nicht mal ein Community-Mehrgewinn, wenn ich mich noch weiter hinsetze und herumoperiere. Danke, "neuer PIC Freund" für den Hinweis mit avrdude 6.1. Ich hoffe, damit kann ich dann erstmal wieder arbeiten.
:
Bearbeitet durch User
Johannes N. schrieb: > Kein Grund, polemisch zu werden. Ich weiß ja nicht, wie das bei dir > ist... Aber meine Zeit ist sehr rar geworden und die investiere ich dann > lieber in ein Projekt an dem ich Spaß habe. Das studenlange > neu-Übersetzen und Ausprobieren von Patches und Hacks gehört für mich > nicht dazu. Mir war schon klar, daß dir diese meine Feststellung nicht gefallen würde. Sie ist aber alles andere als Polemik - vielmehr die Essenz der Beobachtungen die ich in diesem Forum und anderswo immer wieder machen darf: der aktuelle Ingeniernachwuchs scheint zunehmend unfähig zu sein, Fehler systematisch einzugrenzen. Und kann folgerichtig Fehler weder identifizieren noch beheben. In meinen dunklen Stunden mache ich gern Microsoft dafür verantwortlich. Die haben den Leuten über die Jahre eingebleut, daß ein Reboot des Systems eine valide Problemlösungsstrategie ist. Und für Härtefälle dann eine Neuinstallation.
> der aktuelle Ingeniernachwuchs scheint zunehmend unfähig zu sein,
Fehler systematisch einzugrenzen.
100% ACK.
Für mich ist das der Fachkräftemangel. Selbst denken ist heutzutage out.
Das Prinzip ist immer dasselbe: Jeder will Klickibunti. Ein 2.5
Programmer aus China, den tollen avr-gcc und einen Mega8. Zuerst
Google&Copy&Paste. Den Rest erledigt dieses Forum mit gefühlten 100
Posts.
Der TE hat jetzt ein höherwertiges Tool in der Hand. Bleibt zu hoffen,
dass eines Tages avarice mit dem ATMEL-ICE läuft oder Atmel das Studio
für Linux hinbiegt. Dann könnte es auch unter Linux ingenieurmäßig mit
Atmels billigsten weitergehen.
Ey Leute, macht mal schön langsam. Kennen wir uns jenseits dieses Posts? Ich glaube nicht. > der aktuelle Ingeniernachwuchs scheint zunehmend unfähig zu sein, > Fehler systematisch einzugrenzen. Nein, falsch. Der "Ingeniernachwuchs" ist in der Lage, festzustellen, wann es nicht mehr sinnvoll ist, einen Fehler einzugrenzen. Es ist, wie immer, ein Tradeoff zwischen Zeit und Geld. Und wenn die Zeit der Engpass ist, warum sollte man sie dann sinnlos verschwenden? Ich habe ja oben bereits erklärt, warum ich das nicht mehr für sinnvoll halte: Der Mehrgewinn ist weder für mich, noch für die Community erkennbar. Höchstwahrscheinlich hat der Programmer einen Schlag weg, vielleicht wurde mal ein Pin kurzgeschlossen? Meine Güte, das Ding ist eine blanke Platine. Der hat 12,50€ gekostet und wurde nur gekauft, um mal den Fuß in die XMega-Tür zu bekommen. Ist doch sinnvoll, sich bei Zeiten ein vernünfitges Tool dafür zuzulegen. > Und kann folgerichtig Fehler weder identifizieren noch beheben. Ich finde es prima, wie hier mal wieder alles glattgebügelt wird. Kennen wir uns? Nein. Weißt du auch nur ansatzweise, was ich sonst so treibe? Nein. Also, was soll diese Unterstellung? Lass deinen Frust über die Arduino-Schwemme woanders ab. Naja, jetzt hab ich genug Trolle gefüttert. Ich bin dann mal weg.
:
Bearbeitet durch User
Konrad S. schrieb: > Extension Pack installieren und USB läuft wunderbar. Naja, für eine hinreichend einfache Definition von „wunderbar“. Dafür, dass das Ding nichtmal Opensource ist (und damit bspw. dann auch auf nicht-Linux-Systemen nicht zu haben), ist es grottenschlecht. Komm nur nicht niemals auf die Idee, auf diese Weise bspw. einen Firmwareupgrade eines Atmel-ICE durch ein Atmel Studio machen zu lassen. Das ist eine Sackgasse, denn danach hast du ein Atmel-ICE in der Hand, welches sich zwar nicht mehr direkt mit dem Bootloader meldet (sonst könnte man einen neuen Upgrade versuchen), aber auch nicht mehr als ICE ansprechbar ist. Irgendein halbgarer Zustand. Wer sich eine VM auf Linux antun möchte, sollte zu VMware greifen (der einfache VMware Player ist wohl immer noch kostenlos, wenn auch gut versteckt). Der Support fürs Atmel-ICE in AVRDUDE ist noch nicht in dem Topf, wo's richtig kocht (ich hätte ihn gern auf libhidusb aufgesetzt, wie OpenOCD auch), aber sollte unter Linux zumindest brauchbar gehen, benutze ich auch oft genug in der Firma. Debuggen geht leider noch nicht, im AVaRICE bin ich noch nicht dazu gekommen, das mal einzubauen. Die Sache mit dem LUFA-Patch, sorry, irgendwie fehlt mir auch die Zeit, mich besser um AVRDUDE zu kümmern.
Jörg W. schrieb: > Dafür, dass das Ding nichtmal Opensource ist (und damit bspw. dann > auch auf nicht-Linux-Systemen nicht zu haben), ist es grottenschlecht. > > Komm nur nicht niemals auf die Idee, auf diese Weise bspw. einen > Firmwareupgrade eines Atmel-ICE durch ein Atmel Studio machen zu > lassen. Das ist eine Sackgasse, denn danach hast du ein Atmel-ICE > in der Hand, welches sich zwar nicht mehr direkt mit dem Bootloader > meldet (sonst könnte man einen neuen Upgrade versuchen), aber auch > nicht mehr als ICE ansprechbar ist. Irgendein halbgarer Zustand. Ich hab damit nur ein paar mal USB-Chips konfiguriert unf Firmware-Updates bei AVRISPmkII gemacht, ohne Probleme. Aber gut zu wissen, dass "gleich nebenan" eine Fallgrube lauert. Dann lass ich auch das Liebäugeln mit dem ICE erstmal sein. Hier gibt es kein nativ laufendes Windows.
Konrad S. schrieb: > Dann lass ich auch das Liebäugeln mit dem ICE erstmal sein. Wie schon geschrieben: VMware klappt dahingehend problemlos. Nein, ich bekomme kein Geld von denen. ;-) (Im Gegenteil, habe ihnen sogar welches bezahlt.)
> Der Support fürs Atmel-ICE in AVRDUDE ist noch nicht in dem Topf, wo's > richtig kocht Hab meinen ATMEL-ICE bekommen und bringe ihn mit avrdude 6.1 ebenfalls nicht zum Laufen. Ich werde die Tage versuchen, mal avrdude 6.2 zu übersetzen - für den Fall, dass das was bringt. Hier ist meine Fehlermeldung:
1 | sudo avrdude -c atmelice_pdi -p x128a1u -P usb -v -v -v -v -t |
2 | |
3 | avrdude: Version 6.1, compiled on Dec 13 2015 at 15:43:25 |
4 | Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ |
5 | Copyright (c) 2007-2014 Joerg Wunsch |
6 | |
7 | System wide configuration file is "/usr/local/CrossPack-AVR-20131216/etc/avrdude.conf" |
8 | User configuration file is "/Users/XXXX/.avrduderc" |
9 | User configuration file does not exist or is not a regular file, skipping |
10 | |
11 | Using Port : usb |
12 | Using Programmer : atmelice_pdi |
13 | avrdude: jtag3_open_pdi() |
14 | avrdude: usbdev_open(): Found Atmel-ICE CMSIS-DAP, serno: XXXXXXXXXXX |
15 | avrdude: usbdev_open(): error claiming interface 0: usb_claim_interface: couldn't claim interface |
16 | avrdude: usbdev_open(): no usable interface found |
17 | avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2141) |
18 | avrdude: jtag3_open_common(): Did not find any device matching VID 0x03eb and PID list: 0x2141 |
19 | |
20 | avrdude done. Thank you. |
> Die Sache mit dem LUFA-Patch, sorry, irgendwie fehlt mir auch die Zeit, > mich besser um AVRDUDE zu kümmern. Lass mich wissen, wenn ich dabei in irgend einer Form behilflich sein kann.
Johannes N. schrieb: > avrdude: usbdev_open(): error claiming interface 0: usb_claim_interface: > couldn't claim interface Hmm, klebt da noch irgendein anderer Prozess drauf?
Jörg W. schrieb: > Johannes N. schrieb: >> avrdude: usbdev_open(): error claiming interface 0: usb_claim_interface: >> couldn't claim interface > > Hmm, klebt da noch irgendein anderer Prozess drauf? Oder ein Kernel Treiber? Eventuell hidraw? da1l6
Für andere mit einem ähnlichen Problem: Hier kommt die Lösung: http://www.avrfreaks.net/comment/1421981#comment-1421981
Jörg W. schrieb: > Naja, für eine hinreichend einfache Definition von „wunderbar“. > > Dafür, dass das Ding nichtmal Opensource ist (und damit bspw. dann > auch auf nicht-Linux-Systemen nicht zu haben), ist es grottenschlecht. > > Komm nur nicht niemals auf die Idee, auf diese Weise bspw. einen > Firmwareupgrade eines Atmel-ICE durch ein Atmel Studio machen zu > lassen. Das ist eine Sackgasse, denn danach hast du ein Atmel-ICE > in der Hand, welches sich zwar nicht mehr direkt mit dem Bootloader > meldet (sonst könnte man einen neuen Upgrade versuchen), aber auch > nicht mehr als ICE ansprechbar ist. Irgendein halbgarer Zustand. Kann ich nicht bestätigen. Wurde hier schon durchgeführt und lief ohne Probleme. Auch das Flashen anderer Geräte. Was hier allerdings mit dem Atmel ICE wie ein Sack Nüsse läuft, ist das Debugging per DebugWire (unter Windows 7 mit AVR Studio 7). Bei einigen Controllern funktioniert nur das Setzen des DWEN-Flags und dann gar nichts mehr, was jedes Mal eine Wiederbelebung via HV-Programming notwendig macht. Bei denen, bei denen es funktioniert, läuft es auch äußerst bescheiden. Siehe auch hier: Beitrag "Atmel ICE und AVR Studio 7.0 - Debugging nicht möglich" Beruflich bin ich eher mit etwas teureren Systemen unterwegs und im Vergleich dazu ist das Debugging mit den kleinen ATmegas und den ATMEL-Tools "der allerletzte Rotz"®. Die IDE ist .NET-typisch fett, lahm und braucht ewig und drei Tage für den Start und das Debugging kann ich hier nur äußerst diplomatisch als Glücksspiel bezeichnen. Mag sein, dass es auch an der USB-Implementierung von VirtualBox liegt, aber alle andere Software und Geräte kamen hier bis jetzt problemlos damit zurecht.
:
Bearbeitet durch User
Gastino G. schrieb: > Was hier allerdings mit dem Atmel ICE wie ein Sack Nüsse läuft, ist das > Debugging per DebugWire (unter Windows 7 mit AVR Studio 7). Bei einigen > Controllern funktioniert nur das Setzen des DWEN-Flags und dann gar > nichts mehr, was jedes Mal eine Wiederbelebung via HV-Programming > notwendig macht. Das klingt allerdings nach einem Hardware-Problem. DW ist protokollmäßig ziemlich fragil, weil es ein bidirektionales Onewire-Protokoll ist, welches auch noch schnell sein möchte. Damit das funktioniert, musst du einen kurzen Pfad von /RESET zu deinem ISP-Stecker haben, und an /RESET darf nichts weiter dran sein (insbesondere natürlich kein Abblock-Kondensator). Je nach Controller und Gegebenheiten kann ein Pullup von 4,7 oder 10 kΩ das Verhalten verbessern, manchmal aber auch nicht. > Bei denen, bei denen es funktioniert, läuft es auch > äußerst bescheiden. Das wiederum kann ich nicht bestätigen (jetzt aber nicht auf das olle Studio bezogen, welches ich praktisch nicht benutze, sondern auf AVaRICE). Im Wisen darum, dass debugWIRE ja eigentlich nur ein Monitor-ROM-Programm ist, und dass daher bspw. alle Breakpoints nur als Software-Breakpoints mittels Umflashen der jeweiligen Page realisiert werden können, bin ich erstaunt, wie gut das doch noch geht. Der Unterschied zu JTAG-Debugging war viel kleiner, als ich erwartet hätte. > Die IDE ist .NET-typisch fett, lahm > und braucht ewig und drei Tage für den Start Ja, keine Frage. Ich kann den Visual-Affenzirkus-Kram auch nicht leiden. > und das Debugging kann ich > hier nur äußerst diplomatisch als Glücksspiel bezeichnen. Mag sein, dass > es auch an der USB-Implementierung von VirtualBox liegt, Ja, liegt es. In VMware läuft es anstandslos. > aber alle > andere Software und Geräte kamen hier bis jetzt problemlos damit > zurecht. Absense of evidence is no evidence of absense. Über die miserable USB-Implementierung der VirtualBox darfst du dich bei Oracle beklagen, nicht bei Atmel.
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.