Hallo Zusammen, für einen räumlich entfernten Kollegen, der unter irgendeinem Linux arbeitet, suche ich ein Commandline-Werkzeug das die Funktion von atprogram.exe übernimmt. Konkret möchte ich über den Atmel-ICE in einem Tiny1616 einen UPDI-Reset ausführen. In atprogram.exe sähe das ungefähr so aus: atprogram -t atmelice -i updi -d attiny1616 reset Das Kommando soll in ein Skript eingebaut werden. Ich habe selbst aktuell kein Linux hier, möchte dem Kollegen aber zumindest einen Tipp geben können. Danke, marcus
Danke für die Rückmeldung. Ich hatte vor meinem Eingangspost ein bisserl rumrecherchiert, wurde aber aus den Suchergebnissen, inkl. avrdude, nicht schlau. -> Konkret möchte ich über den Atmel-ICE in einem Tiny1616 einen UPDI-Reset ausführen. In atprogram.exe sähe das ungefähr so aus: atprogram -t atmelice -i updi -d attiny1616 reset <- Bezüglich avrdude: Wie würde das von mir beschriebene Kommando mit avrdude aussehen?
Marcus H. schrieb: > Konkret möchte ich über den Atmel-ICE in einem Tiny1616 einen UPDI-Reset > ausführen. Was nennst du "einen UPDI-Reset"? Willst du einfach nur ein Reset auf dem Target-µC ausführen? > In atprogram.exe sähe das ungefähr so aus: > atprogram -t atmelice -i updi -d attiny1616 reset > > Wie würde das von mir beschriebene Kommando mit avrdude aussehen? Da man den µC reseten muß, um mit ISP oder UPDI zu sprechen, würde ich einfach irgendeine lesende Operation ausführen. Z.B. ein Fuse-Byte lesen. Natürlich muß man avrdude den µC und vor allem den Programmer (ATMEL ICE im UPDI Modus) richtig verklickern. Dazu braucht man die -p und -c Kommandozeilenoptionen. Allerdings braucht man eine brandneue avrdude Version, die das ICE als UPDI Programmer unterstützt. Ich habe weder ein ICE noch einen UPDI fähigen µC, deswegen kann ich das nicht testen.
Axel S. schrieb: > Marcus H. schrieb: >> Konkret möchte ich über den Atmel-ICE in einem Tiny1616 einen UPDI-Reset >> ausführen. > > Was nennst du "einen UPDI-Reset"? Willst du einfach nur ein Reset auf > dem Target-µC ausführen? Das hier: -> atprogram -t atmelice -i updi -d attiny1616 reset <- Reset der MCU über UPDI. Der Resetcontroller zeigt dann der Firmware beim Start, dass UPDI die Resetquelle war (statt WDT oder POR). Damit wird ein für diesen Reset spezifisches Verhalten ermöglicht. > >> In atprogram.exe sähe das ungefähr so aus: >> atprogram -t atmelice -i updi -d attiny1616 reset >> >> Wie würde das von mir beschriebene Kommando mit avrdude aussehen? ... > Allerdings braucht man eine brandneue avrdude Version, die das ICE als > UPDI Programmer unterstützt. Ich habe weder ein ICE noch einen UPDI > fähigen µC, deswegen kann ich das nicht testen. Ich finde keine avrdude Doku, die beschreibt wie der Befehl aussehen sollte. Ein Linux in einer VM würde ich zum Testen noch zur Not noch aufsetzen. -> https://sourceforge.net/p/ardude/home/Home/
:
Bearbeitet durch User
In der Zwischenzeit habe ich Ubuntu 18.04LTS in eine VM installiert und den Atmel-ICE angehängt. Dann habe ich gemäß diesem Link http://ubuntuhandbook.org/index.php/2017/01/install-avrdude-6-4-ubuntu-16-04/ den avrdude installiert. sudo add-apt-repository ppa:ubuntuhandbook1/apps sudo apt-get update sudo apt-get install avrdude avrdude-doc Leider kennt avrdude in der aktuellen Version 6.3 den attiny1616 nicht. Hat jemand eine weitere Idee, wie man unter Ubuntu 18.04LTS einen attiny1616 programmieren kann?
Axel S. schrieb: > Allerdings braucht man eine brandneue avrdude Version, die das ICE als > UPDI Programmer unterstützt. Brandneu ist wohl relativ, wenn ich das richtig sehe sind die entsprechenden Änderungen Anfang 2018 reingekommen. Marcus H. schrieb: > aktuellen Version 6.3 Die ist allerdings alles andere als aktuell, die stammt aus 2016.
guest schrieb: > Brandneu ist wohl relativ, wenn ich das richtig sehe sind die > entsprechenden Änderungen Anfang 2018 reingekommen. Wo sind die reingekommen? Auf der Projekt-Homepage ( http://savannah.nongnu.org/projects/avrdude ) finde ich als letzte Version die 6.3.
Leider behandelt Microchip Linux etwas stiefmütterlich. Wenn es nur darum geht, per Linux und updi einen Reset zu senden, scheint es mir erfolgversprechender, das ganze Atmel/Microchip-Geraffel an die Seite zu legen und es statt dessen zu versuchen mit: Pyupdi: https://github.com/mraardvark/pyupdi/blob/master/pyupdi.py cupdi: https://github.com/PitterL/cupdi jtag2updi: https://github.com/ElTangas/jtag2updi und entsprechender, leicht verfügbarer Hardware. Für die ersten beiden braucht's nur einen USB-seriell Adapter, für jtag2updi einen Atmega328p bzw. Arduino Nano oder Uno.
Np R. schrieb: > Wo sind die reingekommen? > > Auf der Projekt-Homepage ( http://savannah.nongnu.org/projects/avrdude ) > finde ich als letzte Version die 6.3. In den Sourcen: https://savannah.nongnu.org/svn/?group=avrdude bzw. direkt: http://svn.savannah.gnu.org/viewvc/avrdude/trunk/avrdude/
Beitrag #5999605 wurde vom Autor gelöscht.
guest schrieb: > In den Sourcen: > https://savannah.nongnu.org/svn/?group=avrdude Danke! Habe ich gleich mal gezogen und ein Debian-Paket davon gebaut. Nur um dann erst festzustellen, dass die Version in Debian Buster auch schon bis svn commit 1429 geht....
Marcus H. schrieb: > Hat jemand eine weitere Idee, wie man unter Ubuntu 18.04LTS einen > attiny1616 programmieren kann? Die avrdude-Version in meinem Debian Buster unterstützt den Attiny1616. Da Ubuntu 18.04 auf (einer frühen Version von) Debian Buster basiert, sollte es möglich sein, relativ schmerzfrei das Debian-Buster Paket auf dem Ubuntu zu installieren. Auf einer Produktiv-Maschine würde ich Pakete unterschiedlicher Distris nicht mischen. In einer VM nur für diesen Zweck spricht aber nichts dagegen.
Hallo samweis, danke für Deine Bemühungen. Ich bin fasziniert davon, dass es unter Linux eine ganze Reihe von Möglichkeiten gibt, irgendwie einen AVR zu flashen. Was nicht wirklich direkt unterstützt wird, sind aktuelle Chips mit dem kommerziellen Standardbrenner AtmelICE. Der Bedarf an professionellen Werkzeugen scheint hier nicht zu bestehen. Np R. schrieb: > Leider behandelt Microchip Linux etwas stiefmütterlich. Zumindest was die Atmel-Schiene angeht. MPLAB gibt es für Linux. > > Wenn es nur darum geht, per Linux und updi einen Reset zu senden, > scheint es mir erfolgversprechender, das ganze Atmel/Microchip-Geraffel > an die Seite zu legen und es statt dessen zu versuchen mit: > > Pyupdi: https://github.com/mraardvark/pyupdi/blob/master/pyupdi.py > cupdi: https://github.com/PitterL/cupdi > jtag2updi: https://github.com/ElTangas/jtag2updi > > und entsprechender, leicht verfügbarer Hardware. Für die ersten beiden > braucht's nur einen USB-seriell Adapter, für jtag2updi einen Atmega328p > bzw. Arduino Nano oder Uno. Leicht verfügbare Hardware wäre im professionellen Umfeld eher der für wenig Geld vom Hersteller gelieferte Atmel-ICE. Wir haben eine Entwicklungs-/Prüfhardware für Windows. Im Moment mag ich nicht glauben, was für eine Aktion es ist, diese unter Linux, in diesem Fall Ubuntu 18.04LTS zum Laufen zu bringen. Natürlich könnte ich die Prüfhardware umbauen, aber das ist irgendwie hirnrissig. Np R. schrieb: > Marcus H. schrieb: >> Hat jemand eine weitere Idee, wie man unter Ubuntu 18.04LTS einen >> attiny1616 programmieren kann? > > Die avrdude-Version in meinem Debian Buster unterstützt den Attiny1616. > Da Ubuntu 18.04 auf (einer frühen Version von) Debian Buster basiert, > sollte es möglich sein, relativ schmerzfrei das Debian-Buster Paket auf > dem Ubuntu zu installieren. > Auf einer Produktiv-Maschine würde ich Pakete unterschiedlicher Distris > nicht mischen. In einer VM nur für diesen Zweck spricht aber nichts > dagegen. Danke, den Tipp werde ich mal an den Linux-Kollegen weitergeben. Wie oben bereits geschrieben - danke für Deine Bemühungen. Grüße, marcus
Np R. schrieb: > guest schrieb: > >> In den Sourcen: >> https://savannah.nongnu.org/svn/?group=avrdude > Danke! > > Habe ich gleich mal gezogen und ein Debian-Paket davon gebaut. > Nur um dann erst festzustellen, dass die Version in Debian Buster auch > schon bis svn commit 1429 geht.... Heißt das, dass Du eine einfache Möglichkeit gefunden hast, einen Atmel ICE / attiny1616 kompatiblen avrdude in Ubuntu 18.04LTS zu installieren? Wie läuft das ab? Danke Dir, marcus
Marcus H. schrieb: > Heißt das, dass Du eine einfache Möglichkeit gefunden hast, einen Atmel > ICE / attiny1616 kompatiblen avrdude in Ubuntu 18.04LTS zu installieren? > Wie läuft das ab? > > Danke Dir, > marcus Nach dem Posting von guest Beitrag "Re: Atmel-ICE mit AVR unter Linux / atprogram.exe-Ersatz" habe ich mir die aktuellen Quellen ("trunk") von avrdude heruntergeladen, kompiliert und ein Debian-Paket davon gebaut. Das geht auf jeden Fall auch auf dem Ubuntu. Eine Anleitung dazu gibt's in den Quellen selbst: http://svn.savannah.gnu.org/viewvc/avrdude/trunk/avrdude/BUILD-FROM-SVN?view=markup Ein paar Header-Dateien und Dependencies wirst Du noch brauchen. Das so erstellte Paket ist aber genauso aktuell wie das aktuelle Paket aus Debian Buster. Du kannst aber auch einfach das avrdude-Paket aus Debian Buster herunter laden: https://packages.debian.org/buster/avrdude Das sollte mit dpkg -i <Paketname> auf dem Ubuntu installierbar sein (könnte aber erfordern, dass Du Abhängigkeiten nachinstallieren musst). Oder Du benutzt gleich eine Debian Buster VM.
Ich stehe hier gerade wie die Kuh vorm Gnu... Als Zielsystem ist Ubuntu 18.04LTS vorgegeben. Tatsächlich fehlen ein paar Abhängigkeiten. Insbesondere kennt aptitude unter Ubuntu 18.04LTS nur libtinfo5. mah@ubuntu:~$ sudo dpkg -i avrdude_6.3-20171130+svn1429-2_amd64.deb (Reading database ... 134695 files and directories currently installed.) Preparing to unpack avrdude_6.3-20171130+svn1429-2_amd64.deb ... Unpacking avrdude (6.3-20171130+svn1429-2) over (6.3-20171130+svn1429-2) ... dpkg: dependency problems prevent configuration of avrdude: avrdude depends on libhidapi-libusb0 (>= 0.8.0~rc1+git20140201.3a66d4e+dfsg); however: Package libhidapi-libusb0 is not installed. avrdude depends on libncurses6 (>= 6); however: Package libncurses6 is not installed. avrdude depends on libtinfo6 (>= 6); however: Package libtinfo6 is not installed. dpkg: error processing package avrdude (--install): dependency problems - leaving unconfigured Processing triggers for man-db (2.8.3-2ubuntu0.1) ... Errors were encountered while processing: avrdude * * Start von AVRDUDE: mah@ubuntu:~$ avrdude avrdude: error while loading shared libraries: libhidapi-libusb.so.0: cannot open shared object file: No such file or directory * * Kannst Du mir bitte einen Tipp geben, wie es hier weitergeht?
:
Bearbeitet durch User
Marcus H. schrieb: > dpkg: dependency problems prevent configuration of avrdude: Das ist normal. dpkg installiert nur das Paket aber nicht dessen Abhängigkeiten. Es meckert nur, dass diese Abhängigkeiten fehlen. Wenn Du jetzt z.B. aptitude startest, wird es Dir avrdude als "broken package" anzeigen. Aptitude kümmert sich aber auch um die Auflösung von Abhängigkeiten. Wenn Du in aptitude "e" drückst, zeigt Dir der Anhängigkeits-Auflöser die Möglichkeiten an, das Problem zu beheben. Blättern zwischen den Lösungen kannst Du mit "," und ".". Eine Lösung wird sein, einfach avrdude wieder zu deinstallieren. Das willst du natürlich nicht. ;-) Die andere Lösung sollte sein, die fehlenden Pakete nachzuinstallieren. Diese sollten in den Ubuntu Repositories alle vorhanden sein. Es kann aber sein, dass die Versionen in dem alten Ubuntu zu alt sind. (Dann findet aptitude keine Lösung, sondern meckert, dass Paket abc nicht in Version xy verfügbar ist). Dann müsstest Du die entsprechenden Pakete, auf die dies zutrifft, auch noch aus dem Debian Buster Repo holen. Mit der Gefahr, dass auch diese wieder Abhängigkeiten nach sich ziehen... Probier's einfach. Möglicherweise reicht das Ubuntu Repo. Dann bist Du schnell fertig. Wenn nicht und wenn es zu kompliziert wird, bleiben Dir zwei Möglichkeiten: 1. Debian Buster VM 2. avrdude aus den Quellen selber kompilieren. Dazu solltest Du vorher folgende Pakete installieren: libhidapi-dev libftdi1-dev libusb-1.0-0-dev libbison-dev und wahrscheinlich auch noch bison flex byacc autoconf build-essential wenn die noch nicht installiert sind. (Sollte ich etwas vergessen haben, wird ./configure schon meckern ;-) ).
:
Bearbeitet durch User
Np R. schrieb: > Leider behandelt Microchip Linux etwas stiefmütterlich. Kann man in diesem Falle gar nicht mal so sagen. Der UPDI-Code ist von Atmicrochip direkt aus Norwegen ins AVRDUDE gekommen. Es bin hier eher ich, der einfach keine Zeit findet, endlich mal alle möglichen Bugs und Patches durchzugehen, und der sich andererseits schämt, einfach den Status Quo als Version 6.4 mal rauszublasen. Aber vielleicht wäre die letztgenannte Variante wirklich die vorerst günstigste, nachdem nun die UPDI-basierten AVRs deutlich an Masse zugenommen haben. Ist schade, dass der entsprechende Code bislang nur im SVN und noch nicht in einem Release ist. Wenn drei Leute jetzt rufen: „Ja, mach das so!“, dann mach ich es. :-)
Aber Aber schrieb: > Jörg W. schrieb: >> dann mach ich es. > > Ja wie jetzt, mit Bugfixes oder einfach den Status rauslasen? Letzteres. Mehr als das habe ich mir zwar immer mal vorgenommen, aber dann doch bloß nicht die Zeit gefunden – weshalb sich ein Release immer weiter rausschiebt. :( Also, wenn hier jemand auftaucht und mir zusichert, dass er die Bug- und Patchliste durchzugehen gewillt ist und dann die entsprechenden Codeänderungen einpflegt, testet und ggf. die Doku anpasst, dann würde er von mir sofort Commit-Rechte bekommen. Das Problem ist ja nur, dass ich (ungewollt) Einzelkämpfer bin und eben auch noch 'ne ganze Menge anderer Dinge an der Backe habe.
Jörg W. schrieb: > Wenn drei Leute jetzt rufen: „Ja, mach das so!“, dann mach ich es. Dann melde ich mich jetzt mit drei verschiedenen User Namen an und rufe "Ja, mach das so!"
Jörg W. schrieb: > Wenn drei Leute jetzt rufen: „Ja, mach das so!“, dann mach ich es. :-) Eins. De facto ist die Version "6.4" ja schon Teil z.B. von Debian stable (als Version "6.3-20171130+svn1429-2"). Jörg W. schrieb: > Das Problem ist ja nur, dass > ich (ungewollt) Einzelkämpfer bin und eben auch noch 'ne ganze Menge > anderer Dinge an der Backe habe. Das verstehe ich. Genauso, wie ich auch verstehe, dass aus so etwas schnell eine (würgende) Verpflichtung wird und viele Angst haben, sie nicht wieder los zu werden. Deine Werbung ist also etwas ungeschickt. ;-)
Np R. schrieb: > De facto ist die Version "6.4" ja schon Teil z.B. von Debian stable (als > Version "6.3-20171130+svn1429-2"). Ist ein Argument. > Deine Werbung ist also etwas ungeschickt. ;-) Naja, ich wollte hier auch nicht wie ein Staubsaugerverkäufer auftreten. :)
Np R. schrieb:
...
Woah, danke. Ich habe diesen Thread an den Kollegen weitergeleitet.
Bin gespannt, wie wir das Thema lösen werden. Werde Meldung erstatten.
Jörg W. schrieb: > Naja, ich wollte hier auch nicht wie ein Staubsaugerverkäufer auftreten. > :) Ich wollte nur sagen, dass Du vielleicht mehr Erfolg hast, wenn Du "Häppchen" anbietest, statt interessierte Enthusiasten gleich mit 175 offenen Bugs zu erschlagen (von denen, wenn ich das richtig sehe, zumindest ein Teil sowieso BS ist). ;-) @ Marcus H. Np R. schrieb: > Wenn Du jetzt z.B. aptitude startest, Synaptic geht natürlich auch. Ich weiß nicht, welche Vorlieben oder Vorkenntnisse Dein Kollege hat. Zum Bauen des Paketes gibt es ja prinzipiell auch zwei Möglichkeiten: 1. Den des upstream-Entwicklers: ./bootstrap ./configure make sudo checkinstall -D make install (checkinstall muss installiert sein). 2. Der offizielle Debian Weg: Buster Quell-Pakete der /etc/apt/sources.list hinzufügen (deb-src ...) apt-get build-dep avrdude apt-get source avrdude dpkg-buildpackage -us -uc ... Keine Ahnung, was ich da raten soll. Viele Wege führen nach Rom...
Np R. schrieb: > Ich wollte nur sagen, dass Du vielleicht mehr Erfolg hast, wenn Du > "Häppchen" anbietest, statt interessierte Enthusiasten gleich mit 175 > offenen Bugs zu erschlagen Wenn mal jemand 10 oder 20 Bugs oder Patches so einigermaßen am Stück durchgehen und entweder bestätigen und reparieren oder schließen würde, wäre das ein guter Anfang. Selbst dazu komme ich nicht. Sind immer mal nur ein oder zwei geworden, die ich so nebenbei noch mit hinbekommen habe.
Hallo Zusammen, ich hatte versprochen mich nochmal zu melden. Die konkrete Aufgabenstellung die zu meiner Frage geführt hatte, wurde anderweitig gelöst, so dass der UPDI-Reset nicht mehr benötigt wird. (ich habe auf unseren Baugruppen ein anderes nutzbares Signal gefunden) Damit hat sich für mich dieses Thema erstmal erledigt. Vielen Dank für an alle, insbesondere samweis, für die geduldige Unterstützung und natürlich an Jörg und seine Mitstreiter für die Arbeit an den verschiedenen AVR Werkzeugen. Vielleicht helfen die hier zusammengetragenen Infos irgendwann einem echten Linux-Anwender weiter. marcus
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.