Hallo, ich bin auf der Suche nach einem einfachen Programmiertool für das AVR-ISP Mk2. Das ganze soll unter Win7 laufen. Ich hab mein Hex File, die Settings für die Fuses und will den Leuten in der Fertigung möglichst wenig Möglichkeiten für Fehler lassen. AVR-Dude per Batchcommand? Oder gibt es da eine nette GUI? Wenn ich mir "AVR8 Burn-o-Mat" oder "AVRDudess" anschaue, bieten die zu viele Möglichkeiten was zu verstellen. Die Stückzahl liegt bei ~100Stk/Jahr. Habt ihr da einen ip für mich? :-) Sarah
Sarah schrieb: > AVR-Dude per Batchcommand? ja, und dafür ein Icon auf dem Bildschirm. Das sollte jeder schaffen...
Wenn du was für die Fertigung brauchst und du verwendest ein Hex-File, dann müssen die Leute immer noch die Fuses und Lockbits einstellen, also auch eine Fehlerquelle. Ich verwende für solche Sachen grundsätzlich ein *.elf-File, da kann ich die Fuses und Lockbits mit reinpacken und dann geht nix schief. Zum Programmieren verwende ich auch den AVRISP-mkII und das alte AVR-Studio. Das ist klein, startet schnell (nicht wie das Atmel Studio) und die Leute müssen dann nur das *.elf auswählen, programmieren, fertig. Das haben bis jetzt alle fehlerfrei hinbekommen...
Is ja nicht so, dass man in Batchcommands dem AVRdude noch die Fuses und Lockbits mitgeben könnte ;) Schon ist das wieder leichter als nen AVR Studio starten zu müssen.
Martin Wende schrieb: > Is ja nicht so, dass man in Batchcommands dem AVRdude noch die > Fuses und > Lockbits mitgeben könnte ;) > Schon ist das wieder leichter als nen AVR Studio starten zu müssen. Ok, hast gewonnen :-) Aber ich muß zu meiner Entschuldigung sagen, daß ich mit dem AVRdude noch nicht gearbeitet habe.
> AVR-Dude per Batchcommand? So weit muss man gar nicht gehen. Bei AVR Studio gibt es auch noch die stk500.exe.
Schau Dir doch mal den: "Auto Macro Recorder" an. Das Teil gibt es z.B. bei Heise. Wenn Du Dich mit dem Stichwort Macro Recorder ins Netz begibst, findest Du bestimmt noch andere Programme. Damit lassen sich relativ komplexe Abläufe automatisieren. Top, wenn der Anwender keine speziellen Eingaben machen soll und ihm nur das: "Klicke hier und da" abgenommen werden soll. Deine projektspezifischen Eingaben wie Dateinamen oder konstante Zahlen kannst Du im Makro verstecken.
Macht nix. Würde dann so aussehen:
1 | Using the default programmer, download the file diag.hex to flash, |
2 | eeprom.hex to EEPROM, and set the Extended, High, and Low fuse bytes |
3 | to 0xff, 0x89, and 0x2e respectively: |
4 | % avrdude -p m128 -u -U flash:w:diag.hex \ |
5 | > -U eeprom:w:eeprom.hex \ |
6 | > -U efuse:w:0xff:m \ |
7 | > -U hfuse:w:0x89:m \ |
8 | > -U lfuse:w:0x2e:m \ |
9 | > -U lock:w:0x3f:m |
10 | |
11 | "-U" indicates a memory operation, |
12 | "w" indicates a write |
13 | "lfuse" the location to perform the operation on |
14 | "0xff" the hex value being written |
15 | "m" take the immediate value specified on command line |
Martin Wende schrieb: > Macht nix. > > Würde dann so aussehen:Using the default programmer, download the file > diag.hex to flash, > eeprom.hex to EEPROM, and set the Extended, High, and Low fuse bytes > to 0xff, 0x89, and 0x2e respectively: > % avrdude -p m128 -u -U flash:w:diag.hex \ >> -U eeprom:w:eeprom.hex \ >> -U efuse:w:0xff:m \ >> -U hfuse:w:0x89:m \ >> -U lfuse:w:0x2e:m \ >> -U lock:w:0x3f:m > > "-U" indicates a memory operation, > "w" indicates a write > "lfuse" the location to perform the operation on > "0xff" the hex value being written > "m" take the immediate value specified on command line Ich danke dir! Ich habs mal angeschaut, am Wochenende werde ich vielleicht mal testen. Scheinbar kann man in der letzten Version damit auch gleich ein *.elf in den µC schreiben. Allerdings ist die letzte WinAVR-Version (Wo AVRdude enthalten ist) wohl von 2010, und das letzte AVRdude ist vom Herbst 2013. Gibt es eine compilierte Windows-Version von AVRdude 2013? Nur eine Frage noch: In der ersten Zeile das "-u -U flash..." ist das ein Schreibfehler oder ist das richtig so mit den 2x "-u". Ich habe in der Beschreibung nichts darüber gefunden (bis jetzt).
Hallo Sarah, am einfachsten geht es mit den dafür vorgesehenen Mitteln. Beim Atmel-Studio befindet sich das Programm "STK500.exe", das ist zur Batchdatei-Steuerung des MKII gemacht. Ich habe damit schon eine Batch-Auswahl zum programmieren verschiedener Geräte gemacht. Den Leuten, die es benutzen, waren die vielen Parameter in den Programmierfenstern zu umständlich. Jetzt wählen sie aus einer Liste den Gerätetyp, den Rest (Dateiname, Fuses, ...) macht die Batchdatei. Die Leute sind zufrieden. Eine Beschreibung findest du im Atmel-Studio Menü unter: "Help -> AVR-TOOLS -> AVRISP mkII User Guide -> Command Line Software" Das Programm (STK500.exe") selbst ist unter "...\Atmel\AVR Tools\STK500\" auf der Festplatte zu finden, wobei ... dein Installationspfad ist. Zumindest ist das bei den Versionen 4.x des Studio so. Ich denke bei neueren Versionen ist das gleich, oder ähnlich. Falls nicht, besorge dir die STK500.exe, sie ist auch ohne das Studio lauffähig. Gruß. Tom
Klasse, vielen Dank. Ich schaue mir mal beide Sachen an. Batchmode ist für mich ok. :-) Sarah
npn schrieb: > Wenn du was für die Fertigung brauchst und du verwendest ein Hex-File, > dann müssen die Leute immer noch die Fuses und Lockbits einstellen Müssen sie nicht. Batchfiles können nämlich durchaus mehr als ein Kommando enthalten.
Und ist die Sache mit den Fuses im ELF File nicht auch etwas umstritten? Weils dafür keinen wirklichen Standard gibt und man sich darauf verlassen muss, dass sein Tool das grade so irgendwie da rausliest? Mir war da so.
@npn:
1 | -u |
2 | |
3 | Disables the default behaviour of reading out the fuses three times before programming, |
4 | then verifying at the end of programming that the fuses have not changed. |
5 | If you want to change fuses you will need to specify this option, as avrdude will see the fuses have changed |
6 | (even though you wanted to) and will change them back for your "safety". |
7 | This option was designed to prevent cases of fuse bits magically changing (usually called safemode). |
c-hater schrieb: > npn schrieb: > >> Wenn du was für die Fertigung brauchst und du verwendest ein Hex-File, >> dann müssen die Leute immer noch die Fuses und Lockbits einstellen > > Müssen sie nicht. Batchfiles können nämlich durchaus mehr als ein > Kommando enthalten. Wie schon gesagt, ich hatte bisher noch nicht mit Batchfiles beim Flashen gearbeitet. Werde das aber auf jeden Fall mal probieren. Macht Sinn, weil man dann eben das AVR-Studio nicht mehr als reines Programmier-Hilfsmittel braucht.
cyblord ---- schrieb: > Und ist die Sache mit den Fuses im ELF File nicht auch etwas > umstritten? > Weils dafür keinen wirklichen Standard gibt und man sich darauf > verlassen muss, dass sein Tool das grade so irgendwie da rausliest? Mir > war da so. Ich hatte da mal was in der GCC-Dokumentation gelesen und schreibe die Fuses und Lockbits seit Jahren schon in meinen Quelltext. Und Geflasht habe ich bisher immer mit dem AVR-Studio bzw. Atmel-Studio. Also im Endeffekt ruft das Studio ja die stk500.exe auf (Programmer ist der AVRISP-mkII). Ich weiß natürlich nicht, wie sich dann andere Tools verhalten (z.B. eben AVRdude), wenn sie ein *.elf-File angeboten bekommen. Aber ich denke mal, wenn das Einfügen der Fuses und Lockbits im GCC vorgesehen ist und unterstützt wird, werden sich die Programmiertools daran halten, oder? Aber ich werde auf jeden Fall mal Tests machen mit Batchfiles, die dann über AVRdude den µC flashen. Mal sehen, wann ich dazu komme...
Martin Wende schrieb: > @npn:-u > > Disables the default behaviour of reading out the fuses three times > before programming, > then verifying at the end of programming that the fuses have not > changed. > If you want to change fuses you will need to specify this option, as > avrdude will see the fuses have changed > (even though you wanted to) and will change them back for your "safety". > This option was designed to prevent cases of fuse bits magically > changing (usually called safemode). Ich danke dir für das Zitat. Das hatte ich bis jetzt noch nicht gefunden.
TomA schrieb: > Falls nicht, besorge dir die STK500.exe, sie ist auch ohne das Studio > lauffähig. Nein, ist sie leider nicht. Zwar kann sie unabhängig vom Studio gestartet werden, aber sie erfordert trotzdem eine Studio-Installation, sonst kann sie garnix. Sie benötigt nämlich noch diverse DLLs und Konfigurationsdateien aus der Studio-Installation, um funktionieren zu können. Irgendwann hatte ich sogar schonmal im Detail aufgedröselt, was das alles ist. Wenn ich mich richtig erinnere, waren das so etwa 5 DLLs und ein bestimmtes Verzeichnis mit den Konfigurationsdaten für die verschiedenen Target-Devices. Das Schlimmste war jedenfalls, daß die stk500.exe die Konfigurationsdateien nur über einen Registry-Eintrag findet und dieser Eintrag unterhalb von HKLM liegt. Also nix mit einer einfachen Installation nur des STK500-Krams auch für normale Benutzer. Zumindest zum Anlegen dieses einen Scheiß-Registry-Eintrags werden zwingend Adminrechte benötigt.
Je nach Ausbildungsstand der Produktionsmitarbeiter würde ich noch eine kleine GUI erstellen mit Rot/Grün Rückmeldung und Ausgabe von Fehlercodes wenn es schiefgeht.
Hallo Leute, der ISP-MKII braucht den USB-Treiber, sonst geht gar nichts. Ist aber lange her, als ich das gemacht hatte. Zur Sicherheit kann ich das nochmal nachsehen. Morgen werde ich voraussichtlich in einer Firma sein, wo ich das mit Batch- und STK500.exe gemacht habe. Ich bin sicher, daß dort kein Atmel-Studio auf dem Rechner installiert ist. Kann mal nachsehen, ob und wenn ja, was ich dort zusätzlich, installiert habe. Ich glaube mich zu erinnern, daß ich das ganze Verzeichnis "STK500" auf den Prüffeldrechner kopiert habe. Das komplette Verzeichnis ist bei mir grad mal 3,1 MByte groß, das nimmt nicht viel Platz auf der Platte. Am Besten in der Doku nachsehen, oder einfach ausprobieren. Gruß. Tom
Alternativ kann man auch Standalone-Programmer aus einem kleinen Mega mit angeflanschtem DataFlash bauen. Die Software wird nur vom Programmierer oder Produktionsleiter upgedatet und der Werker muss lediglich einen Startknopf drücken, wenn er den Target kontaktiert hat. So schwer sind ISP oder TPI oder PDI ja nicht zu impementieren. Das Ganze kommt ohne PC am Arbeitsplatz aus. Mit eigener Stromversorgung kann man das Ding sogar herumtragen und an verschiedenen Programmierplätzen nutzen, falls das notwendig ist.
Hallo Leute, jetzt wollte ich wissen wie es geht und habe es, auf einem Windows-Vista Laptop, ausprobiert. Dort war zuvor kein Atmel-Studio installiert. Das kopieren des STK500-Verzeichnis allein hat nichts gebracht, auch das kopieren der geforderten DLL's ins systemverzeichnis blieb erfolglos. Erst das installieren des ATMEL-Studio (Version 4.16) führte zum Erfolg. Dabei kann auch gleich der Jungo USB-Treiber mitinstalliert werden. Nach der Installation habe ich das Studio, bis auf die Verzeichnisse in den Bildern, wieder gelöscht. Auch den gesamten ATMEL-Studio Programmaufruf habe ich aus dem Startmenü gelöscht. Im Verzeichnis "AvrStudio4\dll" wird nur die Datei "AvrCommon.dll" gebraucht. Das Verzeichnis "STK500" habe ich gelassen, wie es installiert wurde. Sonst ist von der Installation nichts übrig, das Verzeichnis "...\Atmel\AVR Tools" ist nur noch 3MByte groß. Nun funktioniert der Aufruf von STK500.exe wie gewünscht. Gruß. Tom
Hallo Leute, da war ich wohl etwas voreilig mit dem löschen des Studio. Habe jetzt mal versucht einen Tiny2313 auszulesen, hat nicht funktioniert. Es fehlen die Informationen, wie er mit dem Baustein umzugehen hat. Diese befinden sich, für alle Bausteine, im Verzeichnis "...\Atmel\AVR Tools\Partdescriptionfiles". Dieses Verzeichnis darf nicht gelöscht werden. Am sichersten wäre das Studio nicht zu löschen. Gruß. Tom
Bitte 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.



