Die Application Note "AVR910: In-System Programming" https://ww1.microchip.com/downloads/en/appnotes/atmel-0943-in-system-programming_applicationnote_avr910.pdf beschreibt im Abschnitt 4 einen "Simple Low-cost In-System Programmer" auf Basis eines AT90S1200, zu dessen Firmware auf die Datei "avr910.asm" verwiesen wird. Diese Datei ist aber leider im PDF und auch in der HTML-Version weder verlinkt, noch kann ich sie via Google auf microchip.com oder irgendwo anders im Web finden. Da ich mich aber gerade sehr für diesen Quelltext interessiere, möchte ich hiermit mal in die Runde fragen, ob jemand vielleicht diese Datei noch irgendwo auf der Platte liegen hat und sie hier hochladen könnte. Grüße Johannes
Ich habe hier eine Version, die offenbar (Kürzel "JS" im Namen) Modifikationen von John Samperi enthält. John war zumindest vor Jahren (ist es vielleicht heute noch) sehr aktiv auf AVRfreaks.net. Ansonsten ergab eine Web-Recherche auch dort noch Treffer: https://www.serasidis.gr/circuits/avr_isp/avr_isp.htm Ich habe dir auch das benötigte Include 2313def.inc mit angehängt.
Norbert T. schrieb: > http://cappels.org/dproj/910page/avr910a.htm Das ist übrigens die originale (?) Version für den AT90S1200. Die ich gepostet habe ist für die spätere Variante mit AT90S2313/ATtiny2313. Die Teile sind pinkompatibel, aber letztere haben natürlich doppelt so viel Flash und haben insbesondere nicht mehr den primitiven, 3 Ebenen tiefen Hardware-Stack.
Super, vielen Dank euch allen! Das werde ich mir mal genau ansehen. Motopick schrieb: > Es gibt sogar einen C-Port fuer den MSP430! Mein Ziel ist tatsächlich die Überführung in ein C-Programm, allerdings für den RP2040 / Raspberry Pi Pico. Weiß zufällig jemand, ob es soetwas schon gibt? Über Google habe ich jedenfalls bisher nichts dazu gefunden.
Warum willst du so ein primitives Protokoll auf den Raspberry Pi transplantieren? Es sollten sich genügend STK500v2-Protokoll-Implementierungen finden, die man auf sowas laufen lassen kann.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Warum willst du so ein primitives Protokoll auf den Raspberry Pi > transplantieren? Weil ich offensichtlich keine Ahnung habe. :-D Jörg W. schrieb: > Es sollten sich genügend STK500v2-Protokoll-Implementierungen finden, > die man auf sowas laufen lassen kann. OK, darüber werde ich mich informieren, danke für den Tipp.
Johannes F. schrieb: > Jörg W. schrieb: >> Warum willst du so ein primitives Protokoll auf den Raspberry Pi >> transplantieren? > > Weil ich offensichtlich keine Ahnung habe. :-D Du musst einfach bedenken: das Protokoll ist um die 25 Jahre alt und war in der Form geschrieben worden, damit man mit den 1 KiB Flash eines AT90S1200 einen Programmer bauen konnte. Der STK500 hatte dann schon einen AT90S8535 und damit deutlich mehr Möglichkeiten, ein gescheiteres Protokoll zu implementieren. Dessen erste Version dient wohl nach wie vor dem Arduino als Bootloader, die zweite Version war noch ein ganzes Stückchen verbessert worden und ist eine Art de-facto-Standard für viele AVR-Programmierer. Witzigerweise war auf dem STK500 dann noch ein AT90S1200 (und später ein ATtiny2313) drauf als separater Bootloader, auf dem läuft tatsächlich das alten AVR109/910-Protokoll. Aber das ist nur für den Firmwareupgrade des STK500 da.
:
Bearbeitet durch Moderator
> Mein Ziel ist tatsächlich die Überführung in ein C-Programm http://www.mikrocontroller.net/articles/Launchprog und Beitrag "Launchprog V 1.1" > Weil ich offensichtlich keine Ahnung habe. :-D Mach dir nichts drauss. Das alte Protokoll funktioniert fuer alte AVR ganz vorzueglich.
Motopick schrieb: > Das alte Protokoll funktioniert fuer > alte AVR ganz vorzueglich. "vorzüglich" ist etwas anderes, darfste mir ruhig glauben. Schließlich habe ich über viele Jahre AVRDUDE gepflegt. "vorzüglich" darf man zu STK500v2 sagen, und selbst das natürlich nur für die alten AVRs – für die, die jetzt hinzu gekommen sind mit ihren Möglichkeiten wie page erase ist auch STK500v2 nicht mehr ganz so toll. Das Protokoll ist eine mittelmäßige Krücke, die mit den begrenzten Ressourcen der damaligen kleinen Controller zurechtkommen musste.
Jörg W. schrieb: > Du musst einfach bedenken: das Protokoll ist um die 25 Jahre alt und war > in der Form geschrieben worden, damit man mit den 1 KiB Flash eines > AT90S1200 einen Programmer bauen konnte. Danke dir für die Erläuterungen. Wie so oft im Forum habe auch ich wohl die Frage falsch gestellt: Das eigentliche Thema ist, dass ich gerne einen Raspi Pico dazu benutzen würde, AVR-Controller via ISP/SPI zu flashen. Aufgrund meiner bisher stark begrenzten Kenntnisse habe ich dabei an die AVR910-Appnote gedacht, ohne in Erwägung zu ziehen, dass es da bereits bessere/aktuellere Methoden gibt.
:
Bearbeitet durch User
Johannes F. schrieb: > dass ich gerne einen Raspi Pico dazu benutzen > würde, AVR-Controller via ISP/SPI zu flashen. Du weißt, daß neuere AVR-Controller statt ISP auch andere Schnittstellen verwenden, UPDI und DebugWire? Beide haben den Vorzug, nur eine Leitung zum µC zu benötigen. https://www.elektronik-labor.de/AVR/UPDI.html https://www.mikrocontroller.net/articles/DebugWIRE https://github.com/dcwbrown/dwire-debug
Harald K. schrieb: > Du weißt, daß neuere AVR-Controller statt ISP auch andere Schnittstellen > verwenden, UPDI und DebugWire? Ja, für UPDI habe ich mir ein ATtiny416 Xplained Nano besorgt und dort die drei Widerstände entfernt, die den mEDBG mit dem On-board-tiny416 verbinden. Ich verwende aber gern auch noch ältere AVRs mit SPI-ISP wie bspw. ATmega328PB, ATtiny861A und ATtiny84A, daher der Wunsch nach einem günstigen ISP-Programmer auf Basis eines Raspi Pico.
Johannes F. schrieb: > daher der Wunsch nach einem > günstigen ISP-Programmer auf Basis eines Raspi Pico. Fertige USBasp(-Clone) gibt es mit Kabeln und 10/6-Adapter für 9,99 Günstiger wird es auch im Selbstbau nicht. Oliver
Oliver S. schrieb: > Günstiger wird es auch im Selbstbau nicht. Es sei denn, man hat den Pico halt schon da und kann ihn nebenbei auch für anderes benutzen. USBasp ist gut, allerdings sollte man nicht vergessen, dass das Software-USB doch etwas fragiler ist als eine ordentliche Hardware-USB-Schnittstelle.
Johannes F. schrieb: > Ich verwende aber gern auch noch ältere AVRs mit SPI-ISP wie bspw. > ATmega328PB, Der kann DebugWire. > ATtiny861A Der kann DebugWire > und ATtiny84A, Und auch der kann DebugWire.
> Der kann DebugWire.
Muss man das nicht erst per SPI/ISP aktivieren?
Harald K. schrieb: > Der kann DebugWire. Was soll diese Anmerkung denn? Kennst du debugWIRE überhaupt, hast du es jemals beneutzt? Scheinbar nicht, sonst hättest du diese Anmerkung nicht gebracht.
Motopick schrieb: > Muss man das nicht erst per SPI/ISP aktivieren? Da könntest Du recht haben, jedenfalls bei den µCs, die noch ISP kennen. Jörg W. schrieb: > Kennst du debugWIRE überhaupt, hast du es jemals beneutzt? Habe ich. Mit dem MPLAB Snap. Wie kommst Du auf die Idee, es könnte anders sein?
Harald K. schrieb: > Wie kommst Du auf die Idee, es könnte anders sein? Offenbar hast du zumindest die komplette Technologie dahinter nicht im Mindesten verstanden. debugWIRE ist, was der Name sagt: ein ROM-Monitor, um das Debuggen der entsprechenden AVRs überhaupt zu ermöglichen. Es ist kein universelles Programmierprotokoll, und selbst die Debugfähigkeiten sind recht limitiert (es gibt nur Software-Breakpoints, d.h. für jeden Breakpoint wird eine BRK-Instruction geflasht, das ICE merkt sich den originalen Befehl an dieser Stelle und flasht ihn nach Erreichen des Breakpoints zurück). Wie andere schon anmerkten, braucht debugWIRE zwingend ohnehin noch ISP, um überhaupt die Fuse erstmal zu setzen. Auf AVRs, die kein ISP haben, gibt es auch kein debugWIRE. Hauptgefahr bei debugWIRE ist noch dazu, dass die /RESET-Leitung bestimmten elektrischen Anforderungen genügen muss, deren Einhaltung du erst feststellen kannst, nachdem du die DWEN-Fuse (per ISP) geetzt hast. Wenn das nicht funktioniert (weil du beispielsweise zu viel kapazitive Last an /RESET hast), dann war das Ganze eine Einbahnstraße, aus der es kein zurück mehr gibt.
Da das Stichwort UPDI hier im Thread bereits gefallen ist, möchte ich an dieser Stelle mal fragen, wie es eigentlich um die Zugänglichkeit von dessen Spezifikation bestellt ist. Microchip beschreibt es ja als „proprietary interface“, was für mich suggeriert, dass sie unter Verschluss gehalten wird. Dennoch gibt es einige Open-Source-Projekte, die das Flashen mittels UPDI unterstützen sollen, z.B.: https://pypi.org/project/pymcuprog/ https://github.com/ElTangas/jtag2updi Die Suche https://www.google.com/search?q=site%3Amicrochip.com+updi+filetype%3Apdf hat mir aber nichts wirklich Verwertbares geliefert ...
> ... unter Verschluss ...
Keineswegs, steht in den Datenblättern der uC.
Ich habe mir auf dieser Basis mein Selbstbauprogrammiergerät um UPDI
erweitert, wobei ich das 'D' allerdings (bewusst) rudimentär gehalten
habe.
Das Flashen hat Atmel/Microchip schon immer dokumentiert, das Debuggen dagegen nicht.
S. L. schrieb: > steht in den Datenblättern der uC OK, da habe ich tatsächlich noch nicht nachgeschaut ... Bin davon ausgegangen, dass es dafür eine AppNote oder ähnliches Dokument geben würde. Dann sorry für die Frage und vielen Dank für die schnellen Antworten.
:
Bearbeitet durch User
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.