Es ist schon etwas früh am Morgen, daher erstmal nur der englische
Text. Falls jemand damit Verständnisprobleme hat, würde ich ihn auch
noch auf Deutsch verfassen.
More than two years after the previous release (5.11.1), AVRDUDE 6.0
finally made it to go public.
I'd like to thank everyone who has been involved into that release,
both active developers with SVN access as well as numerous users who
contributed bugfixes, improvements and suggestions.
The primary reason for the major version number bump was a changed
syntax of the configuration file (programmer types are now strings
rather than keywords), but that version number change has certainly
also "raised the bar" about many other things that should have been
done before releasing it. Among those are:
. direct reading of ELF files (provided libelf with its header files
is around when ./configure runs)
. keep track of input file contents; when programming just a
bootloader only, nothing else but the bootloader area is touched
. config file can refer to a "parent" device; this dramatically
simplifies the config file as only those things that have been
changed compared to the parent must be specified anew
As an experiment, I'm trying to provide an "official" Win32 binary
release for the first time. It has been compiled using a MinGW32
cross-compilation environment on my FreeBSD host system. If this
turns out to be a complete failure, please tell me, so I can stop this
experiment, and leave Windows binaries to those who know more about
the matter than me. If it works, you might want to tell me
nevertheless, so I might continue that service in future.
Here are the complete release notes for 6.0 (from the NEWS file):
1
* Major changes compared to the previous version:
2
3
- Programmer types in configuration file are no longer keywords but
4
specified as string.
5
6
So you need to change 'type = XYZ;' to 'type = "XYZ";' in own
7
config files. (internal: The parser does not need to know all
8
programmer types now, new programmers will update only the table
9
in pgm_type.c.)
10
11
- The erase cycle counter (formerly options -y / -Y) has been
12
removed.
13
14
- Specifying a -U option without a memory type (short form of
15
option argument list) now defaults to "application" memory for
16
Xmega devices, and "flash" for everything else. This ensures
17
the Xmega bootloader is not accidentally touched.
18
19
- For programmers that support it, the default erase method is a
20
page erase now, rather than a chip erase (Xmega only).
21
22
- Keep track of input file contents
23
Memory segments are being tracked to remember whether they've
24
been actually read from a file. Only segments that came from a
25
file are being programmed into the device, or considered for
26
verification. This drastically improves handling speed for
27
sparse files (e.g. files that have a second bootloader segment),
28
and it ensures the device contents is actually compared for
29
everything mentioned in the file (even in case the file has
30
large 0xFF blocks).
31
32
33
- The -U option now accepts ELF files as input files, and extracts
34
the appropriate section contents that matches the requested memory
35
region. To enable this feature, the host system used for the
36
compilation must have a libelf around, including the respective
37
header files (i.e., package "libelf-devel" on many Linux systems).
38
39
- Programmers and parts lists
40
41
They are now sorted at output with '-c ?'/'-p ?'. (patch #7671:
42
Sorting programmers and parts lists for console output)
43
44
Programmers and parts lists in documentation generated from lists
45
mentioned above. (patch #7687: Autogenerating programmers and
46
parts lists for docs)
47
48
Output list of programmer types with '-c ?type', add list to
49
documentation
50
51
- Configuration files now accepts parent parts/programmers, parts
52
starting with '.' (eg. .xmega) are not included in output parts
53
list and can be used as abstract parents
54
55
(bug #34302: Feature request : device configuration with parent classes)
Erst am Sonntag habe ich mir den (damals) aktuellen Stand von avrdude
geholt und übersetzt. Hätte nicht gedacht, dass Software derart
schnell veraltet. ;-)
Danke, Jörg, für deine tolle Arbeit!
Lies mal das „Kleingedruckte“ auf der Download-Seite. ;-)
Entweder noch einen Moment Geduld, bis die Mirrors das aufgesammelt
haben, oder halt mal mit der Hand die URL editieren, um die Daten
direkt von Savannah zu holen. Nein, einen direkten Link mag ich
nicht posten, denn der würde sich via Gugel rumsprechen, und das
höhlt die Idee der Mirrors dann aus.
avrdude-6.0.1.exe: can't open config file "avrdude-6.0.1.conf": No such file or directory
3
avrdude-6.0.1.exe: error reading system wide configuration file "avrdude-6.0.1.conf"
avrdude-6.0.1.conf liegt im gleichen Verzeichnis wie avrdude-6.0.1.exe,
welches über PATH gefunden wird. Warum wird die .conf nicht gefunden?
War IIRC schon bei älteren Versionen so, wobei ein avrdude.conf im
gleichen Verzeichnis gefunden wird...
Johann L. schrieb:> Wie ist eigentlich der Suchpfad für die .conf?
$prefix/etc/avrdude.conf
Frag mich aber nicht, was $prefix in einer Windows-Konfiguration
ist. :-( /usr/local?
Mit -C angeben geht aber immer.
> War IIRC schon bei älteren Versionen so, wobei ein avrdude.conf im> gleichen Verzeichnis gefunden wird...
Eric Weddington hat meiner Erinnerung nach bei seinen Builds immer
--prefix und --sysconfdir auf den gleichen Wert gesetzt. Das hilft
aber auch nur so lange, wie man es dann auch tatsächlich in das damit
bezeichnete Verzeichnis hinein installiert.
Hmm:
1
/* Use Windows API call to search for the Windows default system config file.*/
Jörg Wunsch schrieb:> Mit -C angeben geht aber immer.
Wenn du mir verrätst wie. Konkret liegen beide in e:\WinAVR\4.7.2\bin
Versucht und nicht funktionieren tun:
-C e:\WinAVR\4.7.2\bin\avrdude-6.0.1.conf
-C e:/WinAVR/4.7.2/bin/avrdude-6.0.1.conf
-C e/WinAVR/4.7.2/bin/avrdude-6.0.1.conf
-C /e/WinAVR/4.7.2/bin/avrdude-6.0.1.conf
-C ./avrdude-6.0.1.conf
-C .\avrdude-6.0.1.conf
-C avrdude-6.0.1.conf
Wie muß ich die Datei denn angeben? So langsam gehen mir die Ideen
aus...
> /* Use Windows API call to search for the Windows default system config file.*/> SearchPath(NULL, "avrdude.conf", NULL, PATH_MAX, sys_config, &filename);> (aus confwin.c)>> Das würde aber heißen, dass er es entlang PATH finden sollte, oder?
Nur für die avrdude.conf, aber nicht für -C datei, oder?
Johann L. schrieb:> Wie muß ich die Datei denn angeben? So langsam gehen mir die Ideen> aus...
Mir allerdings auch.
Unter unixoiden Systemen benutze ich während der Entwicklung immer
(cd builddir)
./avrdude -C avrdude.conf ...
ohne Probleme.
Ich werde den Kram mal auf einem Windows installieren müssen. Mal
sehen, wo ich eins finden kann.
Also hier geht det so.
Ich habe extra mal das avrdude.conf in avrdude-6.0.1.conf umbenannt
(wie bei dir). Wenn ich es beim originalen Namen belasse, findet
er es im aktuellen Verzeichnis auch ohne -C.
Oh mann, ich hatte nen Tippteufel im Dateiname. Nach Umbenennung
funktionieren
-C e:\WinAVR\4.7.2\bin\avrdude-6.0.1.conf
-C /e/WinAVR/4.7.2/bin/avrdude-6.0.1.conf
Das reicht um ersma weiter zu machen. Aber ohne absoluten Pfad
funktioniert's immer noch nicht, es sei denn nach cd ins Verzeichnis in
dem avrdude.exe liegt.
Jörg Wunsch schrieb:> Lies mal das „Kleingedruckte“ auf der Download-Seite. ;-)>> Entweder noch einen Moment Geduld, bis die Mirrors das aufgesammelt> haben, oder halt mal mit der Hand die URL editieren, um die Daten> direkt von Savannah zu holen. Nein, einen direkten Link mag ich> nicht posten, denn der würde sich via Gugel rumsprechen, und das> höhlt die Idee der Mirrors dann aus.
The .nl mirror still haven't gotten 6.0.1.
Other Savannah mirrors can be found here
http://download-mirror.savannah.nongnu.org/mirmon/savannah/
I chose a .no mirror ,and got the 6.0.1 from there
/Bingo
Johann L. schrieb:> Aber ohne absoluten Pfad funktioniert's immer noch nicht
Auch nicht, wenn du es avrdude.conf (ohne Versionsnummer) nennst?
Nur unter diesem Namen wird es normal gesucht.
Jörg Wunsch schrieb:> Johann L. schrieb:>> Aber ohne absoluten Pfad funktioniert's immer noch nicht>> Auch nicht, wenn du es avrdude.conf (ohne Versionsnummer) nennst?
Doch, damit funkttioniert es, und -C braucht's dann eh nicht. Im
Verzeichnis gibt's bereits eine avrdude.conf, die ich nicht durch die
6.0.1 überschreiben wollte — was auch notwendig ist, da die conf zur 6.x
hin nicht aufwärtskompatibel erweitert wurde.
> Nur unter diesem Namen wird es normal gesucht.
Aber wenn er -C avrdude.conf findet, warum dann nicht -C foo.conf? Sieht
mir immer noch nach einem Bug aus.
Hallo nochmal, Jörg.
Mal eine etwas andere Frage: Ist es fuer die nahe Zukunft geplant, dass
AVRDUDE das FLIP (fuer DFU bootloader) Protokoll unterstuetzen wird?
MfG Stephan
Johann L. schrieb:> Aber wenn er -C avrdude.conf findet, warum dann nicht -C foo.conf?
Weil -C das intern zuvor ermittelte sys_config[] komplett
überschreibt:
1
case'C':/* system wide configuration file */
2
if(optarg[0]=='+'){
3
ladd(additional_config_files,optarg+1);
4
}else{
5
strncpy(sys_config,optarg,PATH_MAX);
6
sys_config[PATH_MAX-1]=0;
7
}
8
break;
Damit muss man es stets mit einem Config-File angeben, das entweder
als absoluter oder relativer Pfad bezogen auf das aktuelle Verzeichnis
gefunden werden kann.
Das ist unter Unix und Windows auch gleich, nur die vorherige Ermittlung
des sys_config[] unterscheidet sich. Da die Suche ohnehin nur dem
Windows-API aufträgt, nach "avrdude.conf" zu schauen (die Option -C
ist an dieser Stelle noch gar nicht ausgewertet worden), wäre alles
andere auch nicht nützlich.
Man könnte natürlich in Erwägung ziehen, vor dem "avrdude.conf" noch
nach "avrdude-${version}.conf" zu schauen. Patches welcome. ;-)
Stephan B. schrieb:> Mal eine etwas andere Frage: Ist es fuer die nahe Zukunft geplant, dass> AVRDUDE das FLIP (fuer DFU bootloader) Protokoll unterstuetzen wird?
Sender Jerewan: "Im Prinzip ja, aber ..." ;-)
Es gibt bereits einen Patch, der das tun sollte, aber mein erster
Versuch damals war nicht sehr erfolgreich, und der Einreicher hat
sich in Schweigen gehüllt. (Steht alles im zugehörigen Patch-Tracker.)
In der Vorbereitung auf Release 6.0 hatte ich genügend andere Dinge
zu tun, die ich wichtiger fand, daher habe ich an diesem Patch im
Moment nichts weiter gemacht.
Derzeit habe ich aber gerade jemanden, der sich dafür interessiert.
Es könnte also sein, dass es gar nicht mehr so lange dauert.
Hallo nochmal.
Ich habe mir mal erlaubt das Patch zu ueberarbeiten, und auf die neuste
Version 6.0.1 zu "updaten".
Mein Ergebnis haengt an, vielleicht kann Joerg es ja nach ausreichenden
Testergebnissen ja "mainstream" machen.
Also: Bitte testen g
MfG Stephan
Moin Jörg,
habe eben erst diesen Thread entdeckt...
Letzte Woche brauchte ich AVRDude (auf Windows 7) und habe das ZIP
(V6.0.1) runtergeladen und es in ein Verzeichnis entpackt, dass im Pfad
liegt. Dann zu meinem Projektverzeichnis gewechselt und AVRDude
gestartet.
Läuft ohne zu zicken. Weiß garnicht was du hast. Du kennst dich mit
Windows besser aus als du möchtest :p
Danke dir (und den anderen ) für die neue Version.
900ss D. schrieb:> Weiß garnicht was du hast.
Aber ich weiß zumindest, was ich nicht habe: ein Windows. ;-)
Die Win32-Version ist mit dem MinGW32-Compiler als Cross-Compiler unter
FreeBSD entstanden. Daher mag ich einfach nicht zu viele Erwartungen
in sie setzen. Andererseits freut es mich natürlich zu hören, dass
diese Version ganz offensichtlich zumindest für mehr als einen
Windows-Nutzer funktioniert.
Habe ich das richtig gelesen der JTAGICE 3 wird offiziell unterstützt?
Das ging doch zuvor nicht oder irre ich mich? Das wäre auf jeden Fall
eine tolle Neuigkeit!
Dennis X. schrieb:> Habe ich das richtig gelesen der JTAGICE 3 wird offiziell unterstützt?
So "offiziell", wie AVRDUDE halt sein kann. ;-)
> Das ging doch zuvor nicht oder irre ich mich?
Es ist keinerlei Dokumentation von Atmel dazu veröffentlicht. Der Dank
gebührt hier Knut Schwichtenberg, der einiges an reverse engineering
dafür getan hat. Zwar ist die Kommunikation reichlich verschieden von
den Vorgängern (und gewiss auch nicht alles erraten), allerdings ist
zumindest der wesentliche Ablauf vieler Funktionen nicht so
grundsätzlich
anders als beim JTAGICEmkII, was die Sache wiederum dann doch hat nicht
ganz so schwer werden lassen.
Ein paar Ecken und Kanten werden sicher noch drin sein, aber vermutlich
mehr auf der Debugger-Seite (AVaRICE) als auf der Programmierer-Seite
(AVRDUDE).
Etwas spät, weil ich das gerade zufällig aus einem anderem Thread
entdeckte:
Jörg Wunsch schrieb:>> - The erase cycle counter (formerly options -y / -Y) has been> removed.
Warum das denn?
Für mich sieht das wie ein Rückschritt aus. Zum Glück habe ich eine
5er-Version auf der Platte, diese Option benutze ich nämlich.
Gruß,
Micha
Micha H. schrieb:> Warum das denn?
Weil ich keinen einzigen Nutzer mehr finden konnte (hatte bereits
zwei Jahre zuvor mal rumgefragt).
Weil ich in diesem Counter keinen wirklichen Nutzen (mehr) sehe. Brian
Dean hatte ihn zu Zeiten eines AT90S1200 implementiert, für den damals
nur 1000 Flash-Zyklen garantiert waren. Als er ihn dann später mal
getestet hatte, war er erstaunt, dass er mehr als 150000 Zyklen
ausgehalten hat. Damit hatte sich eigentlich schon damals der
ursprüngliche Zweck dieses Counters erübrigt, denn so viel Löschungen
nimmt man im normalen Betrieb ohnehin praktisch nicht vor.
Weil der Counter für seitenweises Modifizieren (JTAGICE oder Dragon
mit Software-BPs, Bootloader, Flash als Datenspeicher) sowieso nie
gegriffen hat.
Weil es in den Protokollierungen recht nervig war, dass immer erstmal
auf dem EEPROM rumgerödelt worden ist, denn gelesen wurde er immer,
auch wenn es gar nicht angefordert worden ist.
Aber wenn dir so viel daran gelegen ist, kann ich ihn als #ifdef auch
gern wieder einbauen. Dann musst du dir halt deine eigene Version
compilieren; immer noch besser, als ewig auf einer immer weiter
veraltenden Version herumzuhocken.
Jörg Wunsch schrieb:> Micha H. schrieb:>> Warum das denn?>> Weil ich keinen einzigen Nutzer mehr finden konnte (hatte bereits> zwei Jahre zuvor mal rumgefragt).
Da habe ich wohl gerade blau gemacht ;-)
> Weil ich in diesem Counter keinen wirklichen Nutzen (mehr) sehe.
Ich finde den recht nützlich, weniger wegen der Flashzyklen, sondern als
Hinweis auf die Zahl der erfolgten Modifikationen.
> Weil es in den Protokollierungen recht nervig war, dass immer erstmal> auf dem EEPROM rumgerödelt worden ist, denn gelesen wurde er immer,> auch wenn es gar nicht angefordert worden ist.
Warum dann nicht einfach auch das Lesen von Schalter abhängig machen?
> Aber wenn dir so viel daran gelegen ist, kann ich ihn als #ifdef auch> gern wieder einbauen.
Lieber das als garnichts. Aber ich fände es schade, eine gute
Funktionalität zu opfern, auch wenn sie selten genutzt wird.
Danke für Deine Antwort,
Micha
Micha H. schrieb:>> Aber wenn dir so viel daran gelegen ist, kann ich ihn als #ifdef auch>> gern wieder einbauen.>> Lieber das als garnichts. Aber ich fände es schade, eine gute> Funktionalität zu opfern, auch wenn sie selten genutzt wird.
Wobei noch anzumerken wäre, dass der Counter nicht bei allen µCs sauber
funktioniert hat. Wenn ich mich richtig erinnere, dann klappte es z.B.
beim ATxmega128A1 nicht.
Micha H. schrieb:> Aber ich fände es schade, eine gute Funktionalität zu opfern, auch wenn> sie selten genutzt wird.
Nun, du bist in den 13 Jahren, die es AVRDUDE jetzt gibt, der Erste,
der mir begegnet, der das wirklich nutzt.
Konrad S. schrieb:> Wenn ich mich richtig erinnere, dann klappte es z.B. beim ATxmega128A1> nicht.
Bei den Xmegas ist der Schalter sowieso sinnlos, denn da werden die
Seiten per page erase gelöscht und neu beschrieben. Da müsste man einen
Zähler pro page einrichten. ;-)
Micha H. schrieb:>> Aber wenn dir so viel daran gelegen ist, kann ich ihn als #ifdef auch>> gern wieder einbauen.>> Lieber das als garnichts.
Bitte öffne mal bei Savannah einen Feature Request dafür (Bugreport,
als "Feature" deklarieren). Sonst kann es sein, dass das wieder in
Vergessenheit gerät, bis ich mal dazu komme.
Jörg Wunsch schrieb:> Da müsste man
Nene, lass mal gut sein. Ich hab anfangs den Counter benutzt und
festgestellt, dass mein "Erprobungscontroller", der erstmal alles Neue
ausprobieren muss, nach über einem Jahr keine 500mal geflasht wurde.
Seitdem verzichte ich auf die Zählerei und schlafe trotzdem gut. ;-)
Jörg Wunsch schrieb:> Micha H. schrieb:>> Aber ich fände es schade, eine gute Funktionalität zu opfern, auch wenn>> sie selten genutzt wird.>> Nun, du bist in den 13 Jahren, die es AVRDUDE jetzt gibt, der Erste,> der mir begegnet, der das wirklich nutzt.
Dann wird es wohl Zeit, daß ich mal die Hand hebe. Ich habe das auch
defaultmäßig aktiviert im "make flash" Target.
XL
Axel Schwenke schrieb:> Dann wird es wohl Zeit, daß ich mal die Hand hebe.
OK, zwei. :)
Btw., beim JTAGICE3 habe ich Einzelbyte-Updates noch nicht hin bekommen.
Da müsste man wohl in den Debugmodus, was ich bislang beim AVRDUDE
vermeiden wollte. Beim JTAGICE mkII hängt die Möglichkeit von
Einzelbyte-EEPROM-Updates davon ab, dass die OCDEN-Fuse gesetzt ist
(offenbar gehen diese Updates bei JTAG immer über die Target-CPU).
Hallo Jörg,
meinen ersten Post nehme ich gerne zum Anlass mich für Avrdude mal zu
bedanken. Ich nutze das Teil seit einigen Jahren auf Win, Mac und Linux.
Was mich aber immer gestört hat war, dass ich den Chiptyp mit angeben
muss. Nehme ich irgendeinen, dann meckert das Programm "device signature
= 0xabc; expected signature for <device> is 0x123". Das ist doch
verkehrt herum, oder nicht? Gäbe es doch nur "auto" oder
"signature_based"... Spricht was dagegen?
Viele Grüsse
Holger
Holger M. schrieb:> Spricht was dagegen?
Ja.
Erstens der Aufbau von AVRDUDE, bei dem device und programmer intern
zuerst da sein müssen. Man müsste dann erstmal ein dummy device
aufsetzen, nur damit man die Signatur lesen kann, anschließend daraus
den Wert für die -p-Option ermitteln, alles wieder zurückdrehen und
von vorn beginnen. Oder man müsste die komplette Initialisierungsphase
für die Programmer-Implementierung zweiteilen: eine
Anfangsinitialisierung, Ermittlung der Signatur und des tatsächlichen
Typs, Allozieren des Speichers, dann weitermachen.
Gemessen daran, dass du (bzw. dein Makefile) ja von vornherein weißt,
was du programmieren willst (dem Compiler musst du es ja auch sagen),
wäre das ein ziemlicher Aufwand.
Soll nicht heißen, dass das nicht unmöglich ist, aber ich hätte
dringendere Dinge zu erledigen als das. Wenn es jemand komplett
rundum implementieren will, kann er sich gern mit mir abstimmen,
damit es dann nahtlos integriert werden kann.
Zweitens die Tatsache, dass verschiedene Controller verschiedene
Prozeduren benötigen. Historisch war es vor allem der AT90S1200,
dessen ISP-Algorithmus während der Initialisierungsphase noch stark
anders aufgebaut war als der aller Nachfolger. In der „Neuzeit“ sind
es vor allem die Xmegas, die aus der Rolle fallen: PDI statt ISP, und
eine andere, mit den Megas inkompatible JTAG-Implementierung. Man
müsste dann also zumindest von vornherein wieder sowas schreiben wie
„-p xmega“, damit intern die Algorithmen entsprechend gedreht werden
können (so ähnlich macht es ja AVaRICE, allerdings ist dort manches
einfacher zu handhaben als bei AVRDUDE).
Also ich hoffe das führt jetzt nicht zu weit in diesem
Veröffentlichungsthread.
Jörg Wunsch schrieb:> Erstens der Aufbau von AVRDUDE, bei dem device und programmer intern...
Alte, gewachsene Strukturen also.
> Gemessen daran, dass du (bzw. dein Makefile) ja von vornherein weißt,> was du programmieren willst (dem Compiler musst du es ja auch sagen),> wäre das ein ziemlicher Aufwand.
Nun ja, bei der ersten Programmierung weiss ich sehr genau, was sich im
Gerät befindet. Bekomme ich allerdings irgendwann danach eines auf den
Tisch, so ist das anders. In der Realität sind aufgrund von
Verfügbarkeiten und gewünschtem Funktionsumfang verschiedene Chips
verbaut.
Momentan wird deswegen ein aus zwei AvrDude-Aufrufen bestehender Ablauf
verwendet. Kommt der AVR-ISP mkII zum Einsatz, so lassen sich die
Befehle zügig nacheinander absenden und ausführen. Der Dragon dagegen
ist bis zu fünf Sekunden nach dem ersten Aufruf nicht verfügbar. (Ein
zusätzliches Zeitproblem)
> Soll nicht heißen, dass das nicht unmöglich ist, aber ich hätte> dringendere Dinge zu erledigen als das. Wenn es jemand komplett> rundum implementieren will, kann er sich gern mit mir abstimmen,> damit es dann nahtlos integriert werden kann.
Eigentlich wollte ich das nicht selber anfassen, denn bei mir ist die
Zeit genauso knapp. (s.u.)
> Zweitens die Tatsache, dass verschiedene Controller verschiedene> Prozeduren benötigen. Historisch war es vor allem der AT90S1200,...
Das ist wertvolles Fachwissen, das Du hast, nicht ich. Meiner Meinung
nach sollte man in diesem Zuge auch nur Chips berücksichtigen, die
aktuell in nennenswerten Stückzahlen erhältlich sind.
> ... Man müsste dann also zumindest von vornherein wieder sowas schreiben wie „-p
xmega“, damit ...
Diese Idee finde ich sehr gut.
Mein Interesse mit dem Thema nach vorne zu kommen, ist schon mal
geweckt. PN?
Holger M. schrieb:> Momentan wird deswegen ein aus zwei AvrDude-Aufrufen bestehender Ablauf> verwendet. Kommt der AVR-ISP mkII zum Einsatz, so lassen sich die> Befehle zügig nacheinander absenden und ausführen. Der Dragon dagegen> ist bis zu fünf Sekunden nach dem ersten Aufruf nicht verfügbar. (Ein> zusätzliches Zeitproblem)
Liegt an deinem OS und seinem USB-Stack.
Das AVRISPmkII macht am Ende keinen USB-Reset, das JTAGICEmkII (und
der davon abgeleitete Dragon) tun das jedoch. Danach ist das OS an
der Reihe, das Dingens wieder in den Bus einzusortieren, wofür die
einzelnen Systeme recht unterschiedlich lange benötigen.
> Mein Interesse mit dem Thema nach vorne zu kommen, ist schon mal> geweckt. PN?
Nur, wenn du konkrete Ideen hast, wie man das personell untersetzen
kann. Ich kann das auf absehbare Zeit einfach mal nicht abdecken.
Der Tip mit dem USB-Reset ist hilfreich, danke. Die Dragons durch AVRISP
mkII zu ersetzen ist auch viel günstiger und schneller, als alles
andere...
Nach einem wirklich kurzen Blick in die main.c könnte ich mir das Lesen
der Signatur in einer separaten Funktion vorstellen. Aber leider kann
auch ich keine Ressourcen dafür anbieten.
Vielleicht finden sich weitere Interessierte, die dieses Feature auch
gerne hätten, aber dazu ist ein deutsches Forum möglicherweise etwas zu
regional.
Trotzdem danke für's Erläutern.
Holger M. schrieb:> Nach einem wirklich kurzen Blick in die main.c könnte ich mir das Lesen> der Signatur in einer separaten Funktion vorstellen.
Naja, du musst durch die Initialisierung des jeweiligen programmers
laufen. Diese kann sich derzeit aber auf die Annahme verlassen, dass
das device seine Speicherbereiche bereits alloziert hat (deren Größe
ja über die avrdude.conf bekannt ist).
Was man so ungefähr tun müsste ist:
. Erstellen eines dummy device, welches lediglich Speicher für die
Signaturbytes hat.
. Damit in die Initialisierung des Programmers reingehen.
. Signatur lesen. (*)
. Programmer de-initialieren. (**)
. Dummydevice verwerfen, richtiges device ermitteln und allozieren.
. Programmer damit neu initialisieren.
(*) Alle programmer-Implementierungen müssen kontrolliert werden, dass
sie hier auf noch nichts im device außer dem Speicher für die Signatur
zugreifen. Insbesondere darf sich der programmer auch nicht den Zeiger
auf die "struct avrpart" (meist "p" genannt) irgendwo cachen, denn der
muss ja hernach nochmal geändert werden.
(**) Hoffen oder besser noch verifizieren, dass alle programmer
tatsächlich mehrfach initialisiert und de-initialisiert werden können.
„Eigentlich“ nicht viel, aber der Teufel steckt erfahrungsgemäß im
Detail.
Jörg Wunsch schrieb:> Micha H. schrieb:>> Warum das denn?>> Weil ich keinen einzigen Nutzer mehr finden konnte (hatte bereits> zwei Jahre zuvor mal rumgefragt).
Hallo zusammen, ich hatte die -y Option auch immer gerne in meinen
Skripten aktiviert. Bin gerade auf der Suche nach dem Grund für das
Entfernen der Option auf diesen Thread gestoßen. Ich fand das Feature
ganz hilfreich, um den Überblick zu bewahren. Viel weiter als 100 war
der Counter aber bei meinen Controllern wohl auch noch nicht gewesen.
Hallo,
ich möchte gerne die aktuelle Version von AVRDUDE unter Linux
kompilieren und installieren, leider klappt nicht!
Kann mich ein Linux Expert helfen?
gemacht habe ich:
1
tarxzfavrdude-6.1.tar.gz
2
cdavrdude-6.1
3
./configure
4
make
bis ./configure läuft alles ok aber bei "make" kommt folgende Fehler:
Martin e. C. schrieb:> Wo finde ich diese Paket?
Da musst du deinen Paketmanager mal fragen. Wenn ich ein Ubuntu
nehme, tippe ich da "yacc" oder "bison" in die Suche ein, und er
zeigt mir, was er dafür alles hat.
Zu Fuß:
1
sudo apt-get install byacc
2
sudo apt-get install bison
Eins von beiden genügt, aber auch noch den "flex" mit installieren,
falls er es nicht schon ist.
Jörg Wunsch schrieb:
> Da musst du deinen Paketmanager mal fragen. Wenn ich ein Ubuntu> nehme, tippe ich da "yacc" oder "bison" in die Suche ein, und er> zeigt mir, was er dafür alles hat.>> Zu Fuß:> sudo apt-get install byacc> sudo apt-get install bison>> Eins von beiden genügt, aber auch noch den "flex" mit installieren,> falls er es nicht schon ist.
Ok du wars schneller.
Beide sind installiert und flex "ist die neuste Version" (sagt die
Konsole), trotzdem kommt das obere Fehler.
avrftdi_private.h:19:2: warning: #warning No libftdi or libusb support. Install libftdi1/libusb-1.0 or libftdi/libusb and run configure/make again. [-Wcpp]
21
#warning No libftdi or libusb support. Install libftdi1/libusb-1.0 or libftdi/libusb and run configure/make again.
avrftdi_private.h:19:2: warning: #warning No libftdi or libusb support. Install libftdi1/libusb-1.0 or libftdi/libusb and run configure/make again. [-Wcpp]
27
#warning No libftdi or libusb support. Install libftdi1/libusb-1.0 or libftdi/libusb and run configure/make again.
Martin e. C. schrieb:> Frank M. schrieb:>> yacc aka bison installieren sollte helfen.>> aka?> Wo finde ich diese Paket?
aka oder a.k.a. steht im Englischen als Abkürzung für "also known as" (=
"auch bekannt als")
Sorry,
Frank
Thread beobachten
Seitenaufteilung abschalten