Moin,
ich hoffe ihr könnt mir helfen.
Ich bin es leid, ständig zwischen AVR-Studio und PonyProg hin- und her
zu wechseln, daher möchte ich jetzt avrdude zum programmieren benuten,
da ich diesen über die Kommandozeile steuern kann.

Verwendetes System: Pentium II, 400MHz, 128MB RAM, Windows 98 SE

Verwendeter Programmieradapter: ganz einfaches Ding am Parallelport,
weiß nicht genau wie man den nennt. Fun-Card-Programmer oder so.
Auf jeden Fall funktioniert er einwandfrei in PonyProg (Einstellung:
LPT1, AVR/ISP I/O).

Verwendeter AVR: ATtiny2313, 8MHz interner Oszillator (Werkseinstellung)

So, das komische ist nun, dass das programmieren des AVRs vorgestern mit
avrdude hervorragend ging. Und ich habe ihn zu diesem Zeitpunkt noch
genau so aufgerufen wie jetzt auch, also mit -c pony-stk200.
Doch seit gestern bekomme ich die unten angehängte Fehlermeldung.
avrdude sagt ja, dass er den Chip resetted und beschreibt, tut er aber
nicht wenn ichs mit PonyProg nachprüfe.

In PonyProg funktioniert aber alles weiterhin bestens, lesen UND
schreiben.
Ich verstehe beim besten Willen nicht, warum.. ich habe auch bereits
mehrere, ältere Versionen (runter bis 5.1) von avrdude probiert,
vergebens.
Mit der neusten gehts irgendwie garnicht, da will er eine DLL haben
(USBLIB0 oder so..).
Ich habe am Programmieradapter NICHTS verändert.
Ich habe lediglich WinAVR und AVR-Studio 2 mal neu installiert, weil da
anfangs irgendwo der Wurm drin war.

Was ist passiert? Hängt's evtl. mit den Fusebits zusammen? Was soll ich
tun?

Manchmal (anscheinend ganz willkürlich) erscheint auch eine Meldung
seitens avrdude, dass irgendwelche Fuse-Bits nicht gesetzt sind oder
geändert worden sind und ob ich sie zurücksetzen will. (Will ich das?)

Ich hoffe ihr wisst Rat. ;)

Gruß und gute Nacht,
Paul

avrdude -p t2313 -P lpt1 -c pony-stk200 -U flash:w:flash.hex 

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x0a911e
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: AVR device not responding
avrdude: reading input file "flash.hex"
avrdude: input file rechner.hex auto detected as Intel Hex
avrdude: writing flash (226 bytes):

Writing | ################################################## | 100% 0.9s

avrdude: 226 bytes of flash written
avrdude: verifying flash memory against flash.hex:
avrdude: load data flash data from input file flash.hex:
avrdude: input file flash.hex auto detected as Intel Hex
avrdude: input file flash.hex contains 226 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.4s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x12 != 0xff
avrdude: verification error; content mismatch

avrdude done.  Thank you.

>avrdude: verification error, first mismatch at byte 0x0000
>         0x12 != 0xff

Das ist normal mit avrdude und dem einfachen LPT-Programmer. Wenn Du es
20 mal versu
chst, geht es irgendwann wieder.

Ich war das irgendwann leid und habe mir den seriellen Programmer von
Klaus Leidinger gebaut:

http://www.klaus-leidinger.de/mp/Mikrocontroller/A...
- danke Klaus!

Diesen steuere ich über AVROSP II an. Ist viel schneller und hat
zugleich den Vorteil, auch uC-Modelle zu unterstützen, die avrdude nicht
kennt.

Und vor allem: Funktioniert immer!

73 der Dude

mosfetkiller wrote:

> avrdude: Device signature = 0x0a911e

Huch!  Das sollte dich schon stutzig machen, das ist keine gültige
device signature.  Du musst eine hornalte Version von avrdude
benutzen, dass sie dich damit überhaupt weitermachen lässt.  Aktuelle
Versionen brechen hier sofort ab, es sei denn, du überschreibst den
Test mit -F.

Aktuelle PCs sind einfach zu schnell mit dem Bitgewackel an der
parallelen Schnittstelle, vor allem für AVRs, die noch mit den 1 MHz
im Auslieferungszustand laufen (maximal zulässiger ISP-Takt < 250 kHz).
Neuere Versionen von avrdude unterstützen zu diesem Zweck eine Option
-i <N>, wobei <N> die Anzahl der Mikrosekunden bezeichnet, die beim
Bitwackeln zusätzlich zu warten ist.

Einfach mal mit -i 10 anfangen und dann entweder die Fuses auf die
Ziel-Taktfrequenz umstellen (falls diese wesentlich höher sein wird
als die 1 MHz), oder sukkzessive mit kleineren Werten testen.


Der Dude wrote:

> Das ist normal mit avrdude und dem einfachen LPT-Programmer.

Nein, ist es nicht, siehe oben.

> Diesen steuere ich über AVROSP II an. Ist viel schneller

Dann ist aber irgendwas faul.  Entweder ist avrdude zu schnell und
überschreitet den zulässigen ISP-Takt (wie soll dann aber ein anderer
Programmer viel schneller sein?), oder aber avrdude ist zu langsam,
aber dann würde es nicht zu obigem Fehler kommen.

Keine Frage natürlich, dass ein vernünftiger Programmer allemal besser
ist, als das Bit-Banging durch den Hostcomputer erledigen zu lassen.

Was übrigens wirklich viel schneller geht als ISP ist Programmierung
via JTAG, aber das liegt am Prinzip (und parallel HV-Programmierung
logischerweise auch) -- avrdude hin, avrdude her.

> und hat zugleich den Vorteil, auch uC-Modelle zu unterstützen, die
> avrdude nicht kennt.

Welche denn?  Die sollte man schnellstens hinzufügen.

Dafür hat AVR-OSP natürlich den Nachteil, dass du beim Wechsel des
Programmers (JTAG ICE, AVR Dragon, AVRISPmkII, STK500, ...) wieder ein
anderes Tool zur Ansteuerung brauchst, mit anderen Parametern auf der
Kommandozeile etc. pp.  avrdude dürfte mit einem einzigen Tool die
breiteste Palette an Programmiergeräten unterstützen, die man für
einen AVR benutzen kann.

Hi, sorry, hab mich vertan.
Die Device Signature lautet 0x1e910a!!


Die Option -i 10 nimmt avrdude nicht an :/

Weiß jetzt immer noch nicht, was ich tun soll.
Warum sollte ich einen anderen Programmer verwenden?
Er funktioniert mit PonyProg ja astrein.
Meinetwegen muss ich ja garnicht avrdude benutzen.
Wenn jemand noch einen anderen, Kommandozeilenorientierten Brenner weiß,
der den ATtiny2313 unterstützt, her damit. ;-)

Gruß,
Paul

> Hi, sorry, hab mich vertan.
> Die Device Signature lautet 0x1e910a!!

Wie kann man sich da so vertun? Hast du die Meldungen nicht einfach
mit Copy/Paste kopiert?

> Die Option -i 10 nimmt avrdude nicht an :/

Dann wird es wohl so sein, wie Jörg geschrieben hat: Dein Avrdude ist
"hornalt" (cooles Wort, lese ich heute zum ersten Mal :)).

Die aktuelle Version ist übrigens 5.5 (habe ihn, getriggert durch dein
Post, bei mir gerade upgedatet, besten Dank), mit avrdude -v kannst du
dir die Versionsnummer anzeigen lassen.

Die -i-Bremse ist für mich essentiell bei frisch gekauften AVRs (mit
1 MHz), da mein PC, obwohl nicht mehr der modernste, sonst zu schnell
ist.

Bevor du also nach anderen Programmen Auschau hältst, solltest du
erst mal deinen Avrdude aktualisieren.

Hi,
ich hab den Beitrag abends halbtot im Bett geschrieben, daher hab ich
die Meldung aus dem Netz kopiert und nur kurz was dran geändert (ich
weiß, dass ich genau diese Meldung auch hatte).

Ähm, ich habe doch bereits im 1. Post gesagt, dass ich schon alle
möglichen Ponyprog-Versionen getestet habe.. von der neusten bis zu
ältesten.

Aber gut, ich versuchs jetzt nochmal mit der 5.5er, die ich ebenfalls
noch nicht kannte. ;-)

Gruß,
Paul

Sorry wegen des Doppelposts. Aber wo zum Henker bekomme ich ein
vorkompiliertes avrdude 5.5 für Windows 98 her?
Die Entwicklerseite ist eine Katastrophe, ich finde da außer den Sources
garnichts..

Gruß,
Paul

mosfetkiller wrote:

> Sorry wegen des Doppelposts. Aber wo zum Henker bekomme ich ein
> vorkompiliertes avrdude 5.5 für Windows 98 her?

In dem Ton sicher gar nicht.  Dafür renne ich nicht extra rum, wo ich
ein Windows herbekomme, um es dir zu compilieren...

Das 5.4, das beim letzten WinAVR dabei ist, genügt für den hier
besprochenen Zweck aber auch.

> Die Entwicklerseite ist eine Katastrophe, ich finde da außer den Sources
> garnichts..

Es ist ja auch eine Entwicklerseite, und das Ergebnis eines
Opensource-Projekts ist natürlich in erster Linie Sourcecode.
Für die binary versions sind die jeweiligen Paketsysteme der
entsprechenden Plattformen zuständig.  Oder fändest du es jetzt
sinnvoll, wenn ich meine FreeBSD-Version (nur, weil ich gerade
damit entwickle) dort noch hochlade, obwohl es in den FreeBSD-Ports
verfügbar ist?  Für Windows ist WinAVR das zugehörige System für
das Verteilen von Binärversionen.

Meeensch, will doch hier niemanden angreifen, sollte nich so
rüberkommen. ;-)

Fands nur etwas komisch, dass man sich zuerst WinAVR saugen muss, um an
das aktuelle avrdude ranzukommen..
Das aktuelle WinAVR-Release ist außerdem vom 25.05., das neue avrdude
aber vom 30.10. ..
.. aber wenn das bei 5.4 auch schon geht, dann probier ich das auf der
Stelle mal.

Gruß,
Paul

Hallo Joerg,

hast Recht, das Programmieren an sich geht über AVROSP II nicht
schneller, aber der verify erscheint mir viel flinker.

>> und hat zugleich den Vorteil, auch uC-Modelle zu unterstützen, die
>> avrdude nicht kennt.

>Welche denn?  Die sollte man schnellstens hinzufügen.

Ich war letztens in der Verlegenheit, einen tiny24 programmieren zu
müssen. Hab es nach einiger Zeit mit avrdude aufgegeben.

Möglicherweise habe ich mich aber auch einfach zu blöd angestellt.

73

Super! Es klappt nun endlich, wenn ich den Parameter -i 80 mit angebe.
Mit kleineren Werten klappt es nicht.

Zwar komisch, dass PonyProg das schneller kann ohne sich zu verhaspeln,
aber dafür hat PP ja auch keine Kommandozeile. :-D
(Ja ja ich weiß, mein Programmer ist nun auch nicht wirklich für
maximale Performance ausgelegt.)

Habe leider noch etwas zu bemängeln, und zwar meckerte avrdude, dass er
die "libusb0.dll" nicht fand.
Musste dann erst noch manuell den Pfad c:\winavr\utils\libusb\bin in die
autoxecec.bat eintragen.
(Thread dazu:
http://www.avrfreaks.net/index.php?name=PNphpBB2&a...)

Aber nun geht ja alles. ^^

Gruß und Dank,
Paul!!

mosfetkiller wrote:

> Fands nur etwas komisch, dass man sich zuerst WinAVR saugen muss, um an
> das aktuelle avrdude ranzukommen..

WinAVR ist nun mal die Binärplattform für Win32-Binaries für die
diversen AVR-Opensource-Tools.

Das mit der libusb0.dll ist bekannt, ja, ich hoffe, Eric wird das in
seiner nächsten WinAVR-Version besser hinbekommen.

-i80 ist natürlich ziemlich langsam.  Mit was für einem Takt läuft
denn dein AVR?  Die Zeit, die eine bestimmte Variable beim Runter-
zählen pro Mikrosekunde braucht, wird initial an Hand eines Tests
abgeschätzt.  Diese Durchlaufzeit wird dann später mit der
angegebenen Zahl an Mikrosekunden multipliziert, um die Delayschleife
(natürlich mit volatile :) zu füttern.

Keine Ahnung, was Ponyprog hier ggf. anders macht.

Der Dude wrote:

>>Welche denn?  Die sollte man schnellstens hinzufügen.
>
> Ich war letztens in der Verlegenheit, einen tiny24 programmieren zu
> müssen. Hab es nach einiger Zeit mit avrdude aufgegeben.

Der sollte seit knapp zwei Jahren funktionieren und ich habe ihn auch
schon erfolgreich programmiert.  Allerdings kann ich nicht mehr sagen,
ob ich nur einen STK500 o. ä. getestet habe oder auch einen bitbang-
Adapter.

Hallo zusammen!

Also ich habe auch genau das gleiche Problem:

Hardware: Ponyprog-kompatibler Adapter, STK200

Mit Ponyprog funktioniert das Programmieren einwandfrei.
Mit avrdude (5.5) und dem obligatorischen "install_giveio.bat"
funktioniert wirklich nichts. OS ist Windows XP.
Ich dachte, avrdude sei eigentlich für diese 'elementare' Form von
Programmiergeräten entwickelt worden. Umso erstaunlicher finde ich,
dass ich genau mit diesen Adapters (wie STK200) bisher wirklich nur
Probleme mit avrdude hatte.
Irgendwelche Ideen??

Dank & Gruß,

Andreas

---------------8<-----------8<--------8<--------8<-------8<--------

Hier die Ausgabe von avrdude.

>avrdude -vv -p m8 -P lpt1 -c pony-stk200 -i100

avrdude: Version 5.5, compiled on Dec 19 2007 at 21:17:54
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         System wide configuration file is "C:\WinAVR\bin\avrdude.conf"

         Using Port            : lpt1
         Using Programmer      : pony-stk200
         Setting isp clock delay: 100
         AVR Part              : ATMEGA8
         Chip Erase delay      : 10000 us
         PAGEL                 : PD7
         BS2                   : PC2
         RESET disposition     : dedicated
         RETRY pulse           : SCK
         serial program mode   : yes
         parallel program mode : yes
         Timeout               : 200
         StabDelay             : 100
         CmdexeDelay           : 25
         SyncLoops             : 32
         ByteDelay             : 0
         PollIndex             : 3
         PollValue             : 0x53
         Memory Detail         :

                                  Block Poll               Page
      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages
MinW  Max
W   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------
----- ---
-- ---------
           eeprom         4    20   128    0 no        512    0      0
9000  90
00 0xff 0xff
           flash         33    10    64    0 yes      8192   64    128
4500  45
00 0xff 0x00
           lfuse          0     0     0    0 no          1    0      0
2000  20
00 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0
2000  20
00 0x00 0x00
           lock           0     0     0    0 no          1    0      0
2000  20
00 0x00 0x00
           calibration    0     0     0    0 no          4    0      0
0
 0 0x00 0x00
           signature      0     0     0    0 no          3    0      0
0
 0 0x00 0x00

         Programmer Type : PPI
         Description     : Pony Prog STK200
           VCC     =  (not used)
           BUFF    = 4,5
           RESET   = 9
           SCK     = 6
           MOSI    = 7
           MISO    = 10
           ERR LED = 0
           RDY LED = 0
           PGM LED = 8
           VFY LED = 0

bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]
avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.

>Irgendwelche Ideen??

Ja, Keine Ahnung, warum du dich mit dem Frickelkram abgibst. Für wenig
Geld gibt es einen ISP-Programmer von Atmel, der ohne Probleme mit
AVR-Studio funktioniert.

Und wenn Ponyprog funktioniert, dann nimm es halt.

Andreas Terstegge wrote:

> Ich dachte, avrdude sei eigentlich für diese 'elementare' Form von
> Programmiergeräten entwickelt worden.

Ja, ist es, allerdings unter einem Betriebssystem, das für die
Bit-Ein-und-Ausgabe auch betriebssystemseitig bereits einen Treiber
mitbringt.  (OK, die allerersten Versionen haben auch unter Unix
noch direkte Port-EA gemacht, aber das ist schon sehr lange her,
seither nehmen wir auch nicht mehr die gleiche PC-Hardwara wie vor
6...7 Jahren.)  Das entspannt die Sache deutlich, da sich avrdude
dort auf einen funktionierenden Systemdienst verlassen kann.

Leider hat Microsoft es nie fertig gebracht, ein zu den Unixen auch
nur annähernd gleichwertiges API auf die Beine zu stellen, damit man
den Parallelport für mehr als den Anschluss eines Druckers unter
Nutzung der Systemdienste benutzen kann.  Daher die Krücken mit
giveio.sys etc.

> bitbang_cmd(): [ AC 53 00 00 ] [ FF FF FF FF ]

1.) Hast du sichergestellt, dass seitens des Betriebssystems wirklich
nichts mehr auf den Port zugreift (Stichwort: Druckdienst).

2.) Der Port sollte auf SPP stehen im BIOS, nichts wie "bidirektional",
"enhanced" etc.

Hallo nochmal!

@gast: Ein ISP-Programmierer von Atmel ist nicht meine erste Wahl: Ich
habe hier gerade einen USBASP aufgebaut, der auf der USB-Seite prima mit
avrdude funktioniert. Ich bin aber gerade dabei, den RS232-Support zum
Debuggen des Targets dazuzubauen, und dafür verwende ich halt eine
'normalen' 10-polige ISP-Schnittstelle zu LPT1, um dieses
Programmiergerät selber zu programieren. Da ich avrdude ansonsten prima
finde, hätte ich es gerne auch hier eingesetzt (läßt sich ja viel
leichter in Makefiles oder Umgebungen wie Eclipse integrieren). Aber
leider muss ich da halt nach wie vor das kleine Ponny benutzen...

@Jörg: Ich habe gerade eben noch mal im BIOS nachgeschaut. Mein IBM-T43
stand vorher auf 'bidirektional'. Habe ihn gerade auf 'output only'
umgestellt, aber bzgl. avrdude keine Verbesserung erreicht. Immer noch
der gleiche Fehler. Naja, werde halt mit Ponyprog leben müssen, was auch
nicht so schlimm ist. Trotzdem wurmt es mich ein bischen, dass ponyprog
'es kann' und avrdude nicht.

Trotzdem vielen Dank für die Tips!

Andreas

Hallo nochmal!

Aaaah, gerade eben habe ich das Problem selber behoben: Nachdem ich
'just for fun' mal verschiedene LPT-Ports angegeben habe, funktioniert
es plötzlich mit LPT3 ?!?!?!?.
Ich habe allerdings nur ein LPT-Port am Laptop, und die Systemsteuerung
zeigt auch nur den LPT1-Port an. LPT3 dürfte es also offiziell gar nicht
geben ?!?

Ideen oder Erklärungen?

Andreas

Manche BIOSe benutzen die IO-Adresse 0x3BC, die historisch eigentlich
für den Druckerport auf der Monochrom-Grafikkarte (der sogenannten
Hercules-Karte) vorgesehen war, während der erste und zweite Drucker-
port standardmäßig auf 0x378 und 0x278 liegen.  AVRDUDE hat die
Adressen hart codiert, und nachdem wir neulich schon mal hier
diskutiert hatten, wie man das (insbesondere im Hinblick auf sowas
wie PCI-basierte Karten) ggf. via Win32-API abfragen kann, stellt sich
der Weg als so kompliziert heraus und noch dazu völlig uneinheitlich
zwischen den Windowsversionen und Basis- sowie Erweiterungskarten
gehandhabt, dass die Implementierung in keinem Verhältnis zwischen
Aufwand und Nutzen steht.

Siehe oben: von einem vernünftigen Betriebssystem würde man erwarten,
dass es diese Details in einem Treiber abstrahiert.  Auf einem
FreeBSD (auf dem AVRDUDE entstanden ist), sagt man einfach /dev/ppi0,
auf einem Linux /dev/parport0 und auf Solaris /dev/printers/0, und
das System ordnet es der tatsächlichen EA-Adresse zu.  Wenn man was
falsches angibt, bekommt man dann auch eine Fehlermeldung, statt dass
AVRDUDE ,,irgendwo'' rumprobieren muss.

Wenn jemand eine Idee hat, wie man einen vergleichbaren Windows-Treiber
schreibt (der dann möglichst auch noch gegen den Druckerdienst
gegenseitig verriegeln sollte): nur zu.

Würde es nicht schon reichen, wenn avrdude einfach die drei LPT-Adressen
nacheinander testet und feststellt, ob sich Hardware bzw. ein LPT-Port
hinter der Adresse vebirgt? Das sollte doch mit wenig Programmieraufwand
möglich sein.
Dann könnte die Namenszuordnung einfach mit LPT1 bei dem Port
beginnen, das zuerst gefunden wird. In meinem Fall würde dann halt erst
bei 0x3BC ein Port gefunden, aber trotzdem LPT1 genannt, wiel es eben
das einzige Port ist. So ähnlich wird doch Windows selber wohl auch die
Namenszuordnung vornehmen, oder ?

Natürlich würde das immer noch nicht mit allen speziellen Steckkarten
funktionieren oder für den Fall, dass noch virtuelle Ports vorhanden
sind.
Abr es würde verhindern, dass man wie in meinem Fall höchst unintuitiv
LPT3 benutzen muss, obwohl nur ein LPT1 vorhanden ist.

Andreas Terstegge wrote:

> Würde es nicht schon reichen, wenn avrdude einfach die drei LPT-Adressen
> nacheinander testet und feststellt, ob sich Hardware bzw. ein LPT-Port
> hinter der Adresse vebirgt?

Solche Automatismen mögen zwar Windows-typisch sein, verwirren aber mehr
als sie helfen.  Was ist, wenn mehr als ein Port vorhanden ist und auch
an allen ein Programmieradapter hängt?

> In meinem Fall würde dann halt erst
> bei 0x3BC ein Port gefunden, aber trotzdem LPT1 genannt, wiel es eben
> das einzige Port ist.

Nein, das ist kein Grund.  Du kannst in einem DOS/Windows-System auch
nur eine COM2 auf Adresse 0x2F8 haben, aber keine COM1 auf 0x3F8.  Nur
bei den Druckerports gibt es offenbar diesen Heckmeck, dass zwar
normalerweise LPT1 auf 0x378 ist, aber manchmal (nur bei IBM?) auf
0x378 keiner ist und dann der von 0x3BC als LPT1 eingetragen wird.

Wenn das Win32-API denn wenigstens eine vernünftige und einheitliche
Methode böte, wie man das für ein beliebiges logisches Gerät heraus
finden könnte... aber das hatten wir erst vor paar Tagen.

Nein, die einzig wirklich vernünftige Variante wäre es, dass sich jemand
mal hinsetzt, und für die Win32-Parallelports einen Bitbang-Treiber
schreibt, der sich nahtlos in die Treiberwelt integriert (und auch
gegen den Printspooler verriegelt wird), so wie es die Unixe seit
nunmehr vielen Jahren machen.  Aber offenbar ist das eine Arbeit für
jemanden, der seine Großmutter erschlagen hat, anders kann ich mir
nicht recht erklären, dass es das nach wie vor noch nicht gibt.

Alles andere ist und bleibt Flickschusterei.