Hallo zusammen, ich wollte nach langer Abstinenz mal wieder eine LED am Mikrocontroller zum Blinken lassen. Folgendes hat sich bisher herauskristallisiert: - Minimaler Aufbau auf Steckbrett gewünscht - Früher hatte ich Atmega8 und AtTiny13 (?) rumfliegen, das sollte die grobe Richtung sein in die es geht - Programmierung unter Linux - Makefile mit Unterstützung für avrdude ist vorhanden - IDE nicht notwendig, max. VSCode, der Rest dann per Makefile auf der Konsole Meine Frage im Wesentlichen: Welcher Programmer ist unkompliziert unter den gegebenen Umständen zu nutzen (keine Treiber-Probleme o.Ä.). Mir sind zwei Stück durch den günstigen Preis aufgefallen die geeignet zu sein scheinen: 1. DIAMEX AVR ISP [1] 2. DIAMEX EXA-PROG [2] Der EXA-PROG scheint für den gleichen Preis mehr Controller-Architekturen zu unterstützen. Spricht etwas gegen die Variante? Viele Grüße [1] https://www.reichelt.de/isp-programmer-fuer-atmel-avr-usb-anschluss-diamex-avr-isp-p305274.html?&trstct=pos_0&nbc=1
Dennis S. schrieb: > Der EXA-PROG scheint für den gleichen Preis mehr > Controller-Architekturen zu unterstützen. Was interessieren dich andere Architekturen, wenn du eh' nur AVR machen willst? > Spricht etwas gegen die Variante? Dass es die (auch zum Update nötigen) Tools da nur für Windows gibt:
1 | EXA-PROG Programmpaket: |
2 | Treiberdatei für Windows 7 und 8.x |
3 | Windows-Tool zum Test und Update von EXA-PROG |
- https://www.diamex.de/dxshop/EXA-PROG-AVR-ISP-und-UPDI-STM32-NXP-ESP Und siehe auch den dortigen Link auf den Beitrag "Diamex EXA-PROG mit AVRDUDE uter Linux (Mint)"
:
Bearbeitet durch Moderator
UPDI bietet natürlich den Pfad zu moderneren AVR-Generationen – wobei UPDI-Unterstützung eh keine Raketenwissenschaft ist, da es mehr oder weniger ein recht normales UART-Protokoll ist. Das kann man also auch mit einem DIY-Adapter bewerkstelligen. Der einzige Vorteil, den der Diamex hier bietet ist, dass er auch einen HV-Reset machen kann, falls man den Reset-Pin "weggefuset" hat. Ansonsten noch der Hinweis: auf den "Curiosity Nano"-Boards, die mit einem AVR ausgerüstet sind, ist ein EDBG-Chip drauf, den man auch abgesetzt als Programmer betreiben kann. Featuremäßig reicht das dann fast heran an die (teureren) AtmelICE und PICkit-Geräte heran.
Lothar M. schrieb: > Was interessieren dich andere Architekturen, wenn du eh' nur AVR machen > willst? Ist das eine versteckte Zustimmung meiner Aussage? :-) Lothar M. schrieb: > Dass es die (auch zum Update nötigen) Tools da nur für Windows gibt: Okay... blöd, dann fällt das ja quasi raus. Jörg W. schrieb: > Das kann man also auch mit einem DIY-Adapter bewerkstelligen. Ich kann dir insofern folgen, dass du der Meinung bist, dass ein Kauf nicht lohnt weil der Eigenbau trivial ist (?). Trotzdem: in meinen Augen ist es von Vorteil mit einer fertigen, funktionierenden Lösung für wenig Geld zu starten um eine Fehlerquelle möglichst zu eliminieren. Jörg W. schrieb: > Ansonsten noch der Hinweis: auf den "Curiosity Nano"-Boards Ich gucke mal was das bedeutet. Also frage ich jetzt einfach platter: Welchen Programmer könnt ihr heutzutage empfehlen? Anforderungen (soweit ich sie verstehe): - Zielplattform AVR, was nicht heißt dass nicht mehr unterstützt werden darf - Gute Unterstützung für Linux - Programmierbar mit avrdude - kein Bausatz sondern fertiges Produkt - Preis irgendwo im unteren zweistelligen Euro-Bereich. Gruß
Angehängte Dateien:
Jörg W. schrieb: > Ansonsten noch der Hinweis: auf den "Curiosity Nano"-Boards, die mit > einem AVR ausgerüstet sind, ist ein EDBG-Chip drauf, den man auch > abgesetzt als Programmer betreiben kann. Featuremäßig reicht das dann > fast heran an die (teureren) AtmelICE und PICkit-Geräte heran. Ja, programmieren kann man mit irgendwas, aber nicht debuggen. "The onboard debugger can be completely disconnected from the ATtiny416 microcontroller and it can be used to program other UPDI devices." https://www.microchip.com/en-us/development-tool/ATTINY416-XNANO
Dennis S. schrieb: > Zielplattform AVR Ist sehr allgemein. Es gibt mittlerweile X verschiedene Programmier- und Debugschnittstellen für AVRs: * ISP (der Klassiker) * JTAG (alte ATmega und viele Xmega) * PDI (Xmega) * TPI (ATtiny10 & Co) * UPDI (AVR0/1) * HVSP (alte 8-Pin AVRs) * HVPP (alte größere AVRs) * HV-UPDI (AVR0/1) Ich weiß gerade nicht, ob es überhaupt Programmer gibt, die tatsächlich alle diese Protokolle unterstützen. Wenn, dann sind sie (wie bspw. STK600) so teuer, dass sie aus deinem Raster rausfallen. Rundum gut versorgt wärst du natürlich mit sowas wie dem Atmel-ICE oder schätzungsweise auch einem PICkit (habe ich noch nicht benutzt), aber auch die fallen aus deinem Preisraster. Für alles andere wirst du an irgendeiner Stelle Abstriche machen müssen: bezüglich der unterstützten Protokolle, bezüglich des nicht-Windows-Supports, bezüglich fehlender HV-Programmierung sowieso, bezüglich fehlender Levelshifter (keine x-beliebige Target-Betriebsspannung möglich) etc. pp. Da müsstest du schon noch Präferenzen benennen. :-) Wenn du nur ISP machen willst und Target-Spannung kein Thema ist, würde ich zu irgendeinem USBasp raten. Davon kannst du gleich zwei kaufen und eins mit dem anderen bei Bedarf aktualisieren. ;) Persönlich habe ich immer ganz gern mit den Atmel-ICE gearbeitet, aber die sind mittlerweile doppelt so teuer wie zur Markteinführung und damit kaum noch sinnvoll. PICkit, wie geschrieben, habe ich keine Ahnung, könnten potenziell ein guter Ersatz für die inzwischen überteuerten Atmel-ICE sein (und möglicherweise ist das auch Absicht von Microchip).
Jörg W. schrieb: > Da müsstest du schon noch Präferenzen benennen. :-) Das ist eigentlich nicht so schwer 1. es muss sauber unter Linux funktionieren 2. Ich möchte in der Tat nicht unbedingt einen dreistellgen Betrag investieren Die Debugschnittstelle ist abhängig von der Wahl des Controllers. Da wir hier auf dem Niveau von "Lass eine LED" blinken würde ich sagen, dass das auch nachrangig ist. Ich bestelle jetzt einfach mal das Ding hier [1]. Wird schon schiefgehen. :-D [1] https://www.amazon.de/Paradisetronic-com-Programmierger%C3%A4t-ISP-Adapter-Programmer-Arduino/dp/B07Y3B8H91/ref=sr_1_1_sspa [Mod: Lebenslauf aus Link entfernt]
:
Bearbeitet durch Moderator
Dennis S. schrieb: > Das ist eigentlich nicht so schwer Die Frage nach der zu unterstützenden Programmierschnittstelle bleibt trotzdem noch (nur "klassische" AVRs mit ISP oder auch moderne AVR0/1 mit UPDI, schätzungsweise als Minimalanforderungen).
Wenn du nur ISP brauchst, würde ich den https://www.diamex.de/dxshop/DIAMEX-USB-ISP-Programmer-Stick-fuer-AVR empfehlen. Denn a) er hat sich bewährt b) wird von allen gängigen IDE unterstützt c) hat ein ordentliches Gehäuse dass die Platine schützt d) Passt sich an die Betriebsspannung des Target an, was z.B. bei Batteriebetrieb ohne Spannungsregler nützlich ist. Zum Vergleich der Exaprog: a) von dem habe ich hier im Forum noch nie gelesen. b) nur der ISP Modus wird von allen gängigen IDE unterstützt. c) trifft wohl auch zu d) Kann nur 3,3 V und 5 V Was mich sehr stutzig macht, sind diese Sätze in der Doku des Exaprog: "EXA-PROG verfügt über kein eigenes Programm zur Programmierung von Microcontrollern. Die Firmware des EXA-PROG wurde kompatibel zu vielen vorhandenen Programmiertools der Hersteller oder zu frei verfügbaren Tools geschrieben...Die Programmier-Modi STM32 und NXP/LPC sind weitgehend für die Benutzung eigener Programmiertools vorgesehen." Welche Tools das sind, bleibt aber ein Geheimnis.
Jörg W. schrieb: > Die Frage nach der zu unterstützenden Programmierschnittstelle bleibt > trotzdem noch (nur "klassische" AVRs mit ISP oder auch moderne AVR0/1 Ich bin davon ausgegangen, dass man für jede Schnittstelle einen geeigneten Controller findet der meinen Anforderungen genügt ("Flash das Ding damit eine LED blinkt"). Aber wenn das eine weitreichende Entscheidung ist: dann ISP. Ich kenne die Unterschiede sowieso nicht im Detail. ;-) Stefan F. schrieb: > Wenn du nur ISP brauchst, würde ich den > https://www.diamex.de/dxshop/DIAMEX-USB-ISP-Programmer-Stick-fuer-AVR > empfehlen Die Diamex-Produkte schienen ja meine Anforderung mit Linux nicht wirklich zu genügen. Gruß
Dennis S. schrieb: > Die Diamex-Produkte schienen ja meine Anforderung mit Linux nicht > wirklich zu genügen. Der Diamex AVR ISP funktioniert unter Linux (Debian) in Verbindung mit AVRDude hier problemlos. Aber OK, das ist nicht Raketenwissenschaft, das ist nur ein STK500 Emu mit seriell > USB-Wandler.
Björn W. schrieb: > Aber OK, das ist nicht Raketenwissenschaft Nun ja. Wie man's nimmt. :-) Sie schaffen es nicht, ein USB-konformes Protokoll zu implementieren. Es hängt damit an der Toleranz des Betriebssystems gegen Fehlverhalten, ob es funktioniert. Unter FreeBSD muss man dafür extra eine Option setzen, damit es fehlertolsranter wird … Beitrag "DIAMEX-AVR-USB timeouts mit avrdude auf FreeBSD" Behoben wird der Bug nicht mehr, ist ja ein Altprodukt. :-/ Aber unter Linux tut er (und unter FreeBSD mit der Kompatibilitätseinstellung auch).
Dennis S. schrieb: > - Minimaler Aufbau auf Steckbrett gewünscht > - Früher hatte ich Atmega8 und AtTiny13 (?) rumfliegen, das sollte die > grobe Richtung sein in die es geht > - Programmierung unter Linux > - Makefile mit Unterstützung für avrdude ist vorhanden > - IDE nicht notwendig, max. VSCode, der Rest dann per Makefile auf der > Konsole Microchip hat für Dich MPLABX parat, und dazu einen SNAP Programmer, der AVRs mit ISP, PDI, TPI, UPDI und JTAG bespielt, dazu PIC ICSP (nur LVP) und ARM SWD/JTAG. Der Snap liegt irgendwo in der Größenordnung von 30€. Sofern die jeweilige Schnittstelle das zulässt, kannst Du sowohl programmieren als auch debuggen. MPLABX IDE und IPE gibts auch in einer Linux-Version. Passt alles zusammen, funktioniert einfach so. Heutzutage nimmt man die neuen Microchip AVRs, weil die einfach mehr und bessere Peripherie haben. Du kannst natürlich auch einen kleinen PIC24 nehmen (mindestens 3-fache Rechenleistung gegenüber einem klassischen AVR, bei PIC24E nicht deutlichst mehr), das kann das Setup dann auch. fchk
Jörg W. schrieb: > Ist sehr allgemein. Es gibt mittlerweile X verschiedene Programmier- und > Debugschnittstellen für AVRs: > > * ISP (der Klassiker) > * JTAG (alte ATmega und viele Xmega) > * PDI (Xmega) > * TPI (ATtiny10 & Co) > * UPDI (AVR0/1) > * HVSP (alte 8-Pin AVRs) > * HVPP (alte größere AVRs) > * HV-UPDI (AVR0/1) > > Ich weiß gerade nicht, ob es überhaupt Programmer gibt, die tatsächlich > alle diese Protokolle unterstützen. Wenn, dann sind sie (wie bspw. > STK600) so teuer, dass sie aus deinem Raster rausfallen. PICKIT4 kann zumindest von der Hardware her bis auf HVPP alles - was die Firmware dann tatsächlich unterstützt, weiß ich jetzt bei AVR nicht. Ich hätte jetzt mal Verständnis dafür, dass sie das alte HVSP nicht mehr implementieren. Der Snap kann grundsätzlich keine HV-Programmierung, weder bei AVR noch bei PIC, weil ihm der DC-DC-Wandler fehlt. > Rundum gut versorgt wärst du natürlich mit sowas wie dem Atmel-ICE oder > schätzungsweise auch einem PICkit (habe ich noch nicht benutzt), aber > auch die fallen aus deinem Preisraster. Ein PICKIT4 kostet etwa 70-80€, ein SNAP so um die 30€. > kaum noch sinnvoll. PICkit, wie geschrieben, habe ich keine Ahnung, > könnten potenziell ein guter Ersatz für die inzwischen überteuerten > Atmel-ICE sein (und möglicherweise ist das auch Absicht von Microchip). Klar ist das Absicht. Die EDBGs sind die letzten AVR32, und den Klotz will Microchip sich nicht länger als nötig antun. Die Zukunft liegt ganz klar bei den eigenen Tools aus der PIC-Historie, und alles andere wird langfristig sterben. fchk
Frank K. schrieb: > PICKIT4 kann zumindest von der Hardware her bis auf HVPP alles - was die > Firmware dann tatsächlich unterstützt, weiß ich jetzt bei AVR nicht. Ich > hätte jetzt mal Verständnis dafür, dass sie das alte HVSP nicht mehr > implementieren. Naja, wer HVPP kann, kann auch HVSP ;-), das Hauptproblem ist ja nur der HV-Anteil. Ansonsten ist keins der Protokolle älter als das andere, die Seriellvariante wurde halt für die 8-pinnigen alten AVRs nötig (und den ATtiny13A gibt's ja nach wie vor). > Klar ist das Absicht. Die EDBGs sind die letzten AVR32 Schon eine Weile nicht mehr, das sind inzwischen SAMD21. Daran liegt es also bestimmt nicht, wohl eher daran, dass das nicht "corporate design" ist oder so (wobei es eigentlich auch kein Atmel-corporate design war, denn das war blau, letztmalig bei den JTAGICEmkII benutzt).
Frank K. schrieb: > Du kannst natürlich auch einen kleinen PIC24 > nehmen (mindestens 3-fache Rechenleistung gegenüber einem klassischen > AVR, bei PIC24E nicht deutlichst mehr), das kann das Setup dann auch. Das "nicht" sollte ein "noch" gewesen sein. Schit biologische Autokorrektur. fchk
JTAG fuer AVR sollte man vergessen. Diese Schnittstelle wurde von Beginn weg krampfhaft integriert. So liegt sie teilweise im ADC Pin Bereich. Also JTAG bedeutet dann 4 ADC Kanaele weg. Waehrend ISP immer auf SPI liegt. Da gibt es bewaehrte Massnahmen um die beiden zu trennen, ein 2G126 oder so, welcher mit dem Reset die Peripherie umschaltet
Purzel H. schrieb: > JTAG fuer AVR sollte man vergessen. Wenn man die älteren ATmegas debuggen will (ein Teil davon wird ja als "A"-Derivat nach wie vor produziert), dann kann man es nicht vergessen, denn dann hat man keine andere Chance. Man kann die entsprechenden Portpins trotzdem noch multiplexen, indem man während des Debuggens weniger wichtige Funktionen drauflegt. Im Code braucht man dann nur zwei
1 | MCUCSR |= _BV(JTD); |
2 | MCUCSR |= _BV(JTD); |
Wenn man darauf einen Breakpoint setzt und sie einzeln durch steppt, verletzt man die timing requirements, und das Abschalten des JTAG wird nicht wirksam. > Diese Schnittstelle wurde von Beginn > weg krampfhaft integriert. Wenigstens ist es "richtiges" JTAG, d.h. man kann es mit anderen JTAG-Geräten verketten. Da gab's andere MCUs, bei denen das nicht ging … Wenn man den Chip nur programmieren will, braucht man natürlich nicht unbedingt JTAG, wenngleich es gegenüber ISP den Vorteil hat, seinen eigenen Takt zu liefern, sodass man es auch bei "kaputt gefusetem" Oszillator noch benutzen kann.
Dennis S. schrieb: > Die Diamex-Produkte schienen ja meine Anforderung mit Linux nicht > wirklich zu genügen. Wieso? Die basieren alle je nach Modell auf einem USB-UART (den Linux unterstützt) oder werden über libusb angesprochen, was unter Linux sogar besser und einfacher geht, als unter Windows.
Frank K. schrieb: > Heutzutage nimmt man die neuen Microchip AVRs, weil die einfach mehr und > bessere Peripherie haben. Oder eben nicht, weil sie anders als die klassischen AVR programmiert werden und man dazu weniger Anleitungen und Codebeispiele findet. Beim MPLAB Snap sollte man wissen, dass er kein Gehäuse hat und dass man ihn für TPI, PDI und UPDI umlöten muss. Ist keine große Sache, aber für Anfänger ... naja. https://ww1.microchip.com/downloads/en/DeviceDoc/ETN36_MPLAB%20Snap%20AVR%20Interface%20Modification.pdf Kann man den MPLAB Snap eigentlich mit avrdude benutzen? Das war dem TO ja wichtig. Wenn man nur ISP mit 5V brauchst, würde ich einen USBASP Stick nehmen. Billiger geht es nicht. Die gibt es mit und ohne Gehäuse.
Beitrag #7395851 wurde von einem Moderator gelöscht.
Stefan F. schrieb: > Kann man den MPLAB Snap eigentlich mit avrdude benutzen? Das war dem TO > ja wichtig. Zumindest in der aktuellen Version:
1 | $ ./build_linux/src/avrdude -c '?' |
2 | |
3 | Valid programmers are: |
4 | … |
5 | snap = MPLAB(R) Snap in JTAG mode |
6 | snap_jtag = MPLAB(R) Snap in JTAG mode |
7 | snap_isp = MPLAB(R) SNAP in ISP mode |
8 | snap_pdi = MPLAB(R) SNAP in PDI mode |
9 | snap_tpi = MPLAB(R) SNAP in TPI mode |
10 | snap_updi = MPLAB(R) SNAP in UPDI mode |
11 | … |
Jörg W. schrieb: > Stefan F. schrieb: >> Kann man den MPLAB Snap eigentlich mit avrdude benutzen? Das war dem TO >> ja wichtig. > > Zumindest in der aktuellen Version: > >
1 | > $ ./build_linux/src/avrdude -c '?' |
2 | > |
3 | > Valid programmers are: |
4 | > … |
5 | > snap = MPLAB(R) Snap in JTAG mode |
6 | > snap_jtag = MPLAB(R) Snap in JTAG mode |
7 | > snap_isp = MPLAB(R) SNAP in ISP mode |
8 | > snap_pdi = MPLAB(R) SNAP in PDI mode |
9 | > snap_tpi = MPLAB(R) SNAP in TPI mode |
10 | > snap_updi = MPLAB(R) SNAP in UPDI mode |
11 | > … |
12 | > |
Man muss aber zwingend MPLABX installieren, um die AVR-Firmware zu installieren. Mit der meldet sich der SNAP wie auch das PICKIT4 quasi als Atmel EDBG mit der Atmel VID, und nur so kann man ihn mit AVR-Tools benutzen. Original kommen die Teile mit der PIC-Firmware, wo sie sich mit der Microchip VID melden und mit den PIC-Tools verwendet werden können. MPLABX macht dann bei der ersten Benutzung ein Firmwareupdate. Die MPLABX IPE (integrated Programming Environment) kann man auch per Kommandozeile aufrufen, und die kann eh alles. avrdude braucht es also nicht unbedingt. fchk
:
Bearbeitet durch User
Frank K. schrieb: > Mit der meldet sich der SNAP wie auch das PICKIT4 quasi als Atmel EDBG > mit der Atmel VID, und nur so kann man ihn mit AVR-Tools benutzen. Ah ja, stimmt, ist ein Alias für das Atmel-Protokoll ("jtagice3"):
1 | #------------------------------------------------------------ |
2 | # snap /snap_jtag |
3 | #------------------------------------------------------------ |
4 | |
5 | programmer |
6 | id = "snap", "snap_jtag"; |
7 | desc = "MPLAB(R) Snap in JTAG mode"; |
8 | type = "jtagice3"; |
9 | prog_modes = PM_JTAG | PM_XMEGAJTAG; |
10 | extra_features = HAS_VTARG_READ; |
11 | connection_type = usb; |
12 | usbpid = 0x2180, 0x217f, 0x2181; |
13 | ; |
(Die Einträge für die anderen Programmier-Protokolle sehen vergleichbar
aus.)
> avrdude braucht es also nicht unbedingt.
Hätte man auch beim Atmel Studio ja nicht unbedingt gebraucht (zumindest
nicht unter Windows), trotzdem gab es auch genügend Atmel-Kunden, die
AVRDUDE den Atmel-eigenen Programmen vorgezogen haben.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Hätte man auch beim Atmel Studio ja nicht unbedingt gebraucht (zumindest > nicht unter Windows), trotzdem gab es auch genügend Atmel-Kunden, die > AVRDUDE den Atmel-eigenen Programmen vorgezogen haben. Jepp. Läuft einfach wesentlich zuverlässiger als das (aus dem vollständigen Studio extrahierte) CLI-Atmel-Zeugs. Auch mit aller Erfahrung von vielen Jahren treffe ich immer wieder auf Rechner, bei denen das aus unerfindlichen Gründen schlicht nicht funktioniert, sendern mit völlig nutzlosen Fehlermeldungen den Dienst quittiert. Da hat man dann die Wahl, mit viel Mühe herauszufinden, was nun schon wieder das Problem ist, oder AVRDUDE zu verwenden. Im Allgemeinen bevorzuge ich letzteres... Macht einfach wesentlich weniger Arbeit.
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.