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:
DIAMEX AVR ISP [1]
DIAMEX EXA-PROG [2]
Der EXA-PROG scheint für den gleichen Preis mehr Controller-Architekturen zu unterstützen. Spricht etwas gegen die Variante?
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.
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.
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."
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).
Da müsstest du schon noch Präferenzen benennen. :-)
Das ist eigentlich nicht so schwer
es muss sauber unter Linux funktionieren
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
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).
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."
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. ;-)
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 …
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.
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.
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).
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.
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
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.
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.
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.
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.
(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.
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.
