Hallo, da ich für eine Serienproduktion gerne den Zeitaufwand minimieren würde, suche ich nach einem schnelleren Programmer, als mein derzeitiger Parallelport an PonyProg. Damit braucht mein Mega8515 (also 8k) ca. 12 Sekunden für Flash & EEPROM programmieren & verify, Fuses setzen, und nochmal verify (um sicherzustellen, dass die Lockbits gesetzt wurden, und wirklich nur noch 01 02 03 04... ausgelesen wird) Der neue Programmer sollte per USB laufen und mit einer Software zusammenarbeiten, die skriptgesteuert (also per Kommandozeile) bedienbar ist. Das dürfte bei stk500.exe oder avrdude der Fall sein. Ich liebäugle mit dem AVRISP mkII oder besser noch einem Dragon, denn die Debug-Funktion würde ich mir gern mal ansehn. Ist der ISP vom Dragon vergleichbar mit dem mkII, läuft der Dragon auch an avrdude? Und dann natürlich die wichtigste Frage: sind diese USB-Programmer spürbar schneller als meine 12 Sekunden? Man liest bei manchen USB-Seriell Konvertern ja was von mehreren Minuten, aber ich hoffe, das ist bei den original AVR Programmern nicht der Fall? Danke für Tips, Tobias
Es gibt auch das Gerücht, dass man mehrere avrisp mkII gleichzeitig an einem Rechner verwenden kann. Evtl. hilft dies auch bei der Beschleunigung des Vorgangs.
Sowohl Dragon, als auch AVR-ISP mkII sind geile Teile. Immer up to date und zuverlässig und schnell, wobei beide Geräte erst an USB2.0 Full-Speed Ports ihr wahres Potential zeigen. Zu AVRDude kann ich nix sagen. Per AVR-Studio 4 kann man aber beide Teile automatisieren.
Tobias wrote: > Ich liebäugle mit dem AVRISP mkII oder besser noch einem Dragon, > denn die Debug-Funktion würde ich mir gern mal ansehn. Ist der ISP > vom Dragon vergleichbar mit dem mkII, läuft der Dragon auch an > avrdude? Die ISP-Blöcke in der Firmware der aktuellen Atmel-Teile (also AVRISP mkII, JTAG ICE mkII, AVR Dragon) sind gleich. JTAG ICE und Dragon haben ein wenig zusätzlichen Overhead, da sie den praktisch protokollfreien Datenstrom des AVRISP mkII in das Framing einpacken, das dort benutzt wird (10 Bytes Overhead pro Paket). Das sollte aber bei den üblichen Blocktransfers (256 Bytes am Stück) kein großer Unterschied sein. Ja, avrdude kann mit all diesen Teilen umgehen. Vorteil vom AVR Dragon ist, dass er auch via JTAG programmieren kann (so das Target das hergibt), das ist schneller als ISP und ist fremdgetaktet, funktioniert also auch ohne CPU-Takt. > Und dann natürlich die wichtigste Frage: sind diese USB-Programmer > spürbar schneller als meine 12 Sekunden? Für ISP kann ich dir keine Angaben machen, da ich es mit diesen Teilen nicht benutze. Wesentliches Kriterium dürfte dort die eingestellte ISP-Frequenz sein: sie muss kleiner als 1/4 der CPU-Frequenz des Targets sein. Je besser du dich diesem Wert annäherst, um so kürzer die Zeit (aber man kann nur eine diskrete Liste der Frequenzen einstellen). Für JTAG kann ich dir sagen, dass ich hier mit avrdude auf einem Unix ein Image von 45 KiB in 3 s schreibe und in 4,5 s kontrollgelesen habe. (Das ist mit'm JTAG ICE, aber der Dragon hat diesbezüglich die gleiche Hard- und Firmware, sollte also auf gleiche Geschwindigkeit kommen.) Lästig ist bei all diesen USB-Teilen, dass sie sich nach dem ,tschüss' erstmal vom USB verabschieden und neu anmelden; dadurch braucht es (je nach Betriebssystem) einige Sekunden, bis man neu darauf zugreifen kann. Dafür programmiere ich bis zu 4 CPUs in einer Kommandozeile komplett parallel, dann passiert das Ab- und Wieder-Angemelde danach beinahe gleichzeitig.
>Es gibt auch das Gerücht, dass man mehrere avrisp mkII gleichzeitig an >einem Rechner verwenden kann. Ist kein Gerücht, das geht!
Travel Rec. wrote: > ..., wobei beide Geräte erst an USB2.0 > Full-Speed Ports ihr wahres Potential zeigen. Da musst du aber einen ziemlich schnellen AVR haben. Wenn ich mir den schnellsten AVR mit 20 MHz nehme, kann ich ihn nur mit weniger als 5 MHz ISP-Frequenz programmieren. Die nächste tatsächlich implementierte ISP-Frequenz ist 4 MHz. Highspeed-USB läuft mit 12 MHz (und beide Raten sind Bitraten, keine Bytes/s), damit bleibt schon noch ein wenig Luft für den USB-Paketierungs-Overhead.
Ich erinnere mich da an ein Posting zum Dragon Beitrag "AVR Dragon nur so schnell wie STK500?" Deshalb hab ich mir noch keinen gekauft. Bisher reicht mir ein ISP mkII Aber kann das mit dem Dragon einer bestätigen? Ist der bei ISP wirklich so lahm?
Es macht schon einen Unterschied, an einer schnarchlangsamen USB1.1-Schnittstelle zu hängen oder eben an USB2.0, da die Pakete erst dann versendet werden, wenn sie voll sind oder das Timeout zuschlägt. Und das geht bei 2.0 wesentlich fixer, wenn die Daten erstmal am Laufen sind. An USB1.1 ist der Dragon tatsächlich etwas schleppend unterwegs. Beim Einzel-Controller-Programmieren stört das aber weniger.
Travel Rec. wrote: > Es macht schon einen Unterschied, an einer schnarchlangsamen > USB1.1-Schnittstelle zu hängen oder eben an USB2.0, da die Pakete erst > dann versendet werden, wenn sie voll sind oder das Timeout zuschlägt. Ich glaube, hier verwechselst du das mit einem primitiven USB<->RS-232-Konverter. Dieser weiß natürlich nicht, ob auf seiner RS-232-Seite noch weitere Daten ankommen werden, die er in das aktuelle Paket übernehmen kann oder nicht. Daher wartet er einen Timeout ab (was hat dieser Timeout mit USB1.1 oder USB2.0 zu tun?, der wird doch im Chip eingestellt). Die Firmware der AVR-Teile dagegen weiß ja, wann das gegenwärtige Paket vollständig ist und es abgesendet werden kann, wofür dann der Timeout? Auf der Hostseite wird alles, was in einem Syscall raus ist auch als ein Paket gesendet, da braucht's auch keinen Timeout. Oder was übersehe ich hier? Ganz davon abgesehen, die eingesetzten PDIUSBD12 von NXP sind ausdrücklich als full-speed USB (also 12 Mbit/s) deklariert. ;-)
>>Es gibt auch das Gerücht, dass man mehrere avrisp mkII gleichzeitig an >>einem Rechner verwenden kann. > > Ist kein Gerücht, das geht! Na das ist doch toll ;-)
Travel Rec. wrote: > Ich teste das nochmal und schreibe dann meine Ergebnisse ;-) Hier mal der Vergleich: avrdude mit einem AVR Dragon, Target ist ein ATmega324P, eine wahllose Datei hinreichender Größe programmiert, das erste Mal mit ISP:
1 | $ avrdude -c dragon_isp -P usb -p m324p -U dtmfgen32.elf |
2 | |
3 | avrdude: AVR device initialized and ready to accept instructions |
4 | |
5 | Reading | ################################################## | 100% 0.16s |
6 | |
7 | avrdude: Device signature = 0x1e9508 |
8 | avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed |
9 | To disable this feature, specify the -D option. |
10 | avrdude: erasing chip |
11 | avrdude: reading input file "dtmfgen32.elf" |
12 | avrdude: input file dtmfgen32.elf auto detected as raw binary |
13 | avrdude: writing flash (25620 bytes): |
14 | |
15 | Writing | ################################################## | 100% 12.73s |
16 | |
17 | avrdude: 25620 bytes of flash written |
18 | avrdude: verifying flash memory against dtmfgen32.elf: |
19 | avrdude: load data flash data from input file dtmfgen32.elf: |
20 | avrdude: input file dtmfgen32.elf auto detected as raw binary |
21 | avrdude: input file dtmfgen32.elf contains 25620 bytes |
22 | avrdude: reading on-chip flash data: |
23 | |
24 | Reading | ################################################## | 100% 7.04s |
25 | |
26 | avrdude: verifying ... |
27 | avrdude: 25620 bytes of flash verified |
28 | |
29 | avrdude: safemode: Fuses OK |
30 | |
31 | avrdude done. Thank you. |
Der Zielprozessor lief dabei mit 16 MHz, die ISP-Frequenz war auf 2 MHz eingestellt, da 4 MHz nicht mehr stabil lief (klar, es muss ja kleiner als 1/4 der CPU-Frequenz sein). Das zweite Mal mit JTAG:
1 | $ avrdude -c dragon_jtag -P usb -p m324p -U dtmfgen32.elf |
2 | |
3 | avrdude: AVR device initialized and ready to accept instructions |
4 | |
5 | Reading | ################################################## | 100% 0.02s |
6 | |
7 | avrdude: Device signature = 0x1e9508 |
8 | avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed |
9 | To disable this feature, specify the -D option. |
10 | avrdude: erasing chip |
11 | avrdude: reading input file "dtmfgen32.elf" |
12 | avrdude: input file dtmfgen32.elf auto detected as raw binary |
13 | avrdude: writing flash (25620 bytes): |
14 | |
15 | Writing | ################################################## | 100% 3.01s |
16 | |
17 | avrdude: 25620 bytes of flash written |
18 | avrdude: verifying flash memory against dtmfgen32.elf: |
19 | avrdude: load data flash data from input file dtmfgen32.elf: |
20 | avrdude: input file dtmfgen32.elf auto detected as raw binary |
21 | avrdude: input file dtmfgen32.elf contains 25620 bytes |
22 | avrdude: reading on-chip flash data: |
23 | |
24 | Reading | ################################################## | 100% 3.01s |
25 | |
26 | avrdude: verifying ... |
27 | avrdude: 25620 bytes of flash verified |
28 | |
29 | avrdude: safemode: Fuses OK |
30 | |
31 | avrdude done. Thank you. |
Fazit scheint mir dabei, dass ISP einfach wirklich an seine Grenzen stößt. Wenn ich das auf deine eingangs geschilderte Beschreibung umrechne, dürfte die gesamte ISP-Rate vergleichbar sein. Was natürlich als Vorteil bliebe mit den USB-angeschlossenen Geräten ist, dass man relativ einfach mehrere Targets parallel programmieren kann. Hier mal aus Spaß der Vergleich mit (paralleler) HV-Programmierung in einem STK500:
1 | $ avrdude -c stk500pp -P /dev/cuad1 -p m324p -U dtmfgen32.elf |
2 | |
3 | avrdude: AVR device initialized and ready to accept instructions |
4 | |
5 | Reading | ################################################## | 100% 0.01s |
6 | |
7 | avrdude: Device signature = 0x1e9508 |
8 | avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed |
9 | To disable this feature, specify the -D option. |
10 | avrdude: erasing chip |
11 | avrdude: reading input file "dtmfgen32.elf" |
12 | avrdude: input file dtmfgen32.elf auto detected as raw binary |
13 | avrdude: writing flash (25620 bytes): |
14 | |
15 | Writing | ################################################## | 100% 4.08s |
16 | |
17 | avrdude: 25620 bytes of flash written |
18 | avrdude: verifying flash memory against dtmfgen32.elf: |
19 | avrdude: load data flash data from input file dtmfgen32.elf: |
20 | avrdude: input file dtmfgen32.elf auto detected as raw binary |
21 | avrdude: input file dtmfgen32.elf contains 25620 bytes |
22 | avrdude: reading on-chip flash data: |
23 | |
24 | Reading | ################################################## | 100% 2.68s |
25 | |
26 | avrdude: verifying ... |
27 | avrdude: 25620 bytes of flash verified |
28 | |
29 | avrdude: safemode: Fuses OK |
30 | |
31 | avrdude done. Thank you. |
Das ist vergleichbar mit der JTAG-Geschwindigkeit (was natürlich für JTAG spricht für die AVRs, die es haben -- es ist viel einfacher aufzusetzen und geht auch in-system). Weiß nicht, ob die HV-Programmierung im Dragon dank USB noch einen Tick schneller wäre als im STK, ich war zu faul, die vielen Drähte jetzt erst zu stöpseln. Die zwei 10poligen Kabel des STK sind da doch irgendwie handlicher.
hi weiss ja nicht obs ne alternative ist (preislich, menge, möglichkeiten) aber es gibt distris wo man seine controller schon programmiert beziehen kann. mfg phil
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.