Forum: Compiler & IDEs avrdude - Probleme bei Device ID


von Michael J. (jogibaer)


Lesenswert?

Hallo,

ich schreibe mir geraden einen ISP und bin auf ein für
mich seltsames Problem gestoßen.

Ich sende avrdude ja, welche CPU's ich unterstütze, und avrdude
sendet mir dann den zurück, welchen ich mit der -P Option angebe.

Das funktioniert aber komischerweise nur, wenn ich als Protokoll
AVR910 eingebe, bei AVR109 erkennt er die CPU nicht mehr und sendet
unabhängig von der -p Option immer die erste von mir gemeldete ID 
zurück.


So funktioniert es:

12:46:14 michael: ~$ avrdude -p m32 -c AVR910 -P /dev/ttyUSB0 -u  -U 
flash:w:test.hex

Found programmer: Id = "USB-ISP"; type = U
    Software Version = 0.1; Hardware Version = 1.0
Programmer supports auto addr increment.

Programmer supports the following devices:
    Device code: 0x76 = ATMEGA8
    Device code: 0x72 = ATMEGA32
    Device code: 0x43 = ATMEGA128


-> liefert zurück 0x72


und so nicht:

12:46:04 michael: ~$ avrdude -p m32 -c AVR109 -P /dev/ttyUSB0 -u  -U 
flash:w:test.hex

Connecting to programmer: .
Found programmer: Id = "USB-ISP"; type = U
    Software Version = 0.1; Hardware Version = 1.0
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=256 bytes.

Programmer supports the following devices:
    Device code: 0x76
    Device code: 0x72
    Device code: 0x43

-> liefert immer 0x76 zurück


Ich habe mitgekommen, das es bei den ID ein ziemliches durcheinander 
gibt

-> /etc/avrdude.conf

avrdude Version 5.4.1

Kann mir jemand mal Nachhilfe erteilen ?


Danke
Jogibär

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Michael Jogwich wrote:

> Das funktioniert aber komischerweise nur, wenn ich als Protokoll
> AVR910 eingebe, bei AVR109 erkennt er die CPU nicht mehr und sendet
> unabhängig von der -p Option immer die erste von mir gemeldete ID
> zurück.

Das liegt einerseits an dem ganzen Kuddelmuddel mit den Device-IDs,
andererseits natürlich daran, dass AVR109 ja ein Bootloader ist, der
logischerweise sowieso nur exakt einen einzigen Prozessortyp
unterstützen kann.  Damit geht avrdude davon aus, dass der erste (und
hoffentlich einzige) gemeldete CPU-Typ der ist, den der Bootloader in
der anderen Richtung auch wieder als gültigen Wert akzeptieren
wird. ;-)

Die eigentliche CPU-Erkennung erfolgt anschließend über die device ID
statt über diesen dummen Bytecode, und das ist letztlich auch die
Vorgehensweise, die die Appnote AVR109 empfiehlt.  Der Bytecode war
von Anfang an eigentlich nur eine dumme Idee.

von Michael J. (jogibaer)


Lesenswert?

Hallo,

stimmt, bei meinem Bootloader habe ich nur eine CPU drine,
da ist es wurscht.

Allerdings wollte ich bei meinem ISP den schnellen Blockmodus benutzen,
ansonsten dauert das ja ewig ein größeres Programm zu übertragen.

Kann ich trotzdem irgenwie den Blockmodus nutzen ?


Jogibär

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Michael Jogwich wrote:

> Kann ich trotzdem irgenwie den Blockmodus nutzen?

Müsste ich jetzt nachgucken, aber ich denke schon, dass das geht.

von Michael J. (jogibaer)


Lesenswert?

Hallo Jörg,

in der manpage habe ich aber keinen Hinweis gefunden, wie
ich den Blockmodus trotzdem benutzen kann.

Könntest Du mir mal bitte einen kleinen Hinweis geben ?


Danke
Jogibär

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Wenn der Programmer ihn anbietet, wird er benutzt.

von Michael J. (jogibaer)


Lesenswert?

Jörg Wunsch wrote:
> Wenn der Programmer ihn anbietet, wird er benutzt.

Hallo,

das ist ja klar.

Nur in dem Modus AVR109, wo avrdude diesen benutzen würde,
haut das mit der Typübergabe einfach nicht hin!


Bei AVR910 benutzt avrdude nicht den Blockmodus, weil dieses
Protokoll diesen nicht hat.Ich kann diesenauch nicht erzwingen.
(Mein ISP kann beide Protokolle).

Das Problem dürfte klar sein, oder ?


Jogibär

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Jetzt verstehe ich, ja.

Im Prinzip müsste man den buffered mode aus dem butterfly.c ins
avr910.c kopieren können.  Wenn ein AVR910 den nicht versteht, sollte
es doch (soweit ich das Protokoll in Erinnerung habe) mit einem
Fragezeichen antworten.  Falls er nicht verfügbar ist, bleibt alles
so, wie es ist, falls er verfügbar ist, dann so verfahren, wie in
butterfly.c.

Allerdings müsste man die Annahme, dass das mit dem Fragezeichen
funktioniert und es nicht zum Verklemmen des AVR109 führt, noch
gegen alle gängigen AVR109-Implementierungen gegentesten.  Dazu würde
ich neben dem originalen AVR109 von Atmel vor allem auch die
Bootstraps des STK500 rechnen.

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
Noch kein Account? Hier anmelden.