Hallo,
heute Abend hab ich mal in den Sourcen von avrdude geforscht, denn
ich hab eine PCI-LPT-Karte, die unter Windose als LPT2 angelegt wird.
Da diese Karte nicht die von avrdude vorgesehene Adresse hat, die LPT2
normalerweise hat, ging erstmal nichts.
Meine Karte bekam die $EC00.
Unter PonyProg und Bascom kann man die Adresse hinzufügen, und kann so
einfach per STK200 auf den AVR zugreifen.
Da ich erstmal keine Möglichkeit gefunden habe die Adresse per
Kommandozeile mitzugeben, wollte ich mir avrdude selber compilieren, was
nach einiger Zeit auch klappte. Dann noch die Adresse für LPT2 geändert,
und schon gings per avrdude auf den Zusatz-LPT :-)
Es war mehr Arbeit den PC soweit zu bringen, das er überhaupt
compiliert, als die LPT-Adresse zu ändern ^^
Es gibt ja schon unzählige Threads zu diesem Thema.
Meine Frage nun, ist es eigentlich angedacht, das man avrdude soweit
optimiert, das man diese IO-Adresse per Kommandozeile mitgeben könnte ?
Also so ähnlich wie es von Syntax bei einem USB-JTAG-ICE aussieht.
zB:
1
-P lpt2:ec00
Wobei hier das lpt2 nur anzeigt, dass es sich um einen Parallelport
handelt, die Nr. ist ja zweitrangig.
Wäre auf jeden Fall ein Feature-Request Wert, wenn ich mich zum Thema so
umsehe.
Ich weiss nicht, ob man mit Win32-API an diese Adresse herankommt. Da
bin ich noch am suchen.
Aber die Portadresse wird ja eigentlich vom BIOS verwaltet. Man kann
anscheinend andere fixe!!! Portadressen im BIOS (#1) abfragen, in denen
dann die eigentlichen Portadressen der Schnittstellen (#2) stehen.
http://logix4u.net/Legacy_Ports/Parallel_Port/How_to_read_Parallel_Serial_Port_address_from_BIOS.html
Mir ist nur noch nicht klar, ob es mit GIVEIO.SYS möglich ist, per _inp
die Adressen #1 zu lesen. Ich werde das heute abend mal testen.
Wenn es mit giveio.sys nicht funktioniert, ist möglicherweise Port I/O
(http://portio.sourceforge.net/) ein Weg, um die Hardwareadressen
herauszufinden.
> Besser fände ich es eigentlich noch, wenn man sich die tatsächliche> IO-Basisadresse irgendwie übers Win32-API beschaffen könnte.
Kann man, steht in der Registry.
Darinnen findet sich ein Eintrag namens "Configuration Data" im Format
"REG_FULL_RESOURCE_DESCRIPTOR", und in dem steht die Basisadresse des
Parallelports.
Einen Klartextnamen gibts im Eintrag "Identifier".
Die 8 im Registrykey dürfte annähernd zufällig sein, es sollten also
alle Subkeys von HKLM\...\..\MultifunctionAdapter untersucht werden,
dazu gibt es ja geeignete Enumerationsfunktionen.
OK, das Wissen von portio (und den dort angegebenen Referenzen) könnte
sich schon dafür eignen. Auf die uralte BIOS-Area würde ich nicht
zurück greifen, zumal diese gerade für Dinge wie die hier angsprochenen
PCI-Karten unbrauchbar sein wird.
Ist schon schade, dass man den Zirkus mit der direkten Port-EA überhaupt
braucht. Da liegen zwischen MS Windows und den aktuellen Unixen Welten
dazwischen -- um so verwunderlicher, da gerade die PC-Plattformen und
damit Windows-Programme historisch schon immer eine Neigung hatten, den
Parallelport für allgemeine Digital-EA zu benutzen und nicht nur zum
Drucken. Die Unixe können alle (also für die hier relevanten: Solaris,
Linux, FreeBSD) zwischen Druckbetrieb und digitaler EA sauber hin- und
her schalten, nur Windows kann das nicht.
Jetzt ist es interessant, was Tiny 80 auf seinem Rechner an dieser
Stelle findet. D.h. ob der Anschluss auf seiner PCI-LPT -Karte auf diese
Weise gefunden werden könnte.
regedit hilft uns nur nicht. ;-)
Es müsste sich schon jemand hinsetzen, und den Krams irgendwie
avrdude-mäßig als Code aufbereiten. Wenn ich die PortIO-Doku
richtig interpretieren, dann unterscheidet sich der Zirkus noch
dazu für die alten MS-DOS-basierten Systeme... da tendiere ich
aber dazu, diese dann einfach zu ignorieren und es für die bei
der jetzigen festen Adresszuordnung zu belassen.
Na dann: viel Spaß, Patches für ppiwin.c bitte über das Patch-System
von AVRDUDE einreichen...
Jörg Wunsch wrote:
> regedit hilft uns nur nicht. ;-)
Ist mir klar. Ich war ja noch nicht fertig ;-)
Zunächst finde ich es wichtig, herauszufinden, ob das Holen der Info aus
der Registry ein gangbarer Weg ist. Wenn ja kann man anfangen zu
programmieren.
> Es müsste sich schon jemand hinsetzen, und den Krams irgendwie> avrdude-mäßig als Code aufbereiten. Wenn ich die PortIO-Doku> richtig interpretieren, dann unterscheidet sich der Zirkus noch> dazu für die alten MS-DOS-basierten Systeme... da tendiere ich> aber dazu, diese dann einfach zu ignorieren und es für die bei> der jetzigen festen Adresszuordnung zu belassen.
MSDOS naja... Aber ich als Windows98-Fan möchte das auch noch auf einem
Windows98 System verifizieren.
> Na dann: viel Spaß, Patches für ppiwin.c bitte über das Patch-System> von AVRDUDE einreichen...
Stefan "stefb" B. wrote:
> MSDOS naja... Aber ich als Windows98-Fan möchte das auch noch auf einem> Windows98 System verifizieren.
Win98 ist MS-DOS... (mit "grafischem Betriebssystemaufsatz", oder
so ähnlich hieß das mal).
Na, dann guck mal, wenn du das alte Zeug noch hast, kannst du ja auch
rausfinden, ob dort tatsächlich die gleichen API-Funktionen und die
gleichen Registry-Pfade benutzt werden können. Wäre ja um so besser.
Hallo,
ist ja richtig was los hier. ;-)
Ich dachte mir nur, dass die Angabe der Adresse die einfachste
Möglichkeit wäre. Es muss ja nicht gleich eine High-Wollmilch-endVersion
werden, und bleibt evtl. flexibler in Sachen Windowsversionen.
Die Karte die hier eingebaut ist, ist schon älter, und gibt es so auch
nicht mehr, die wird auch nur bis Win2k unterstützt. siehe Nm9705 ->
http://www.moschip.com/html/download_drivers.html
Ich hab hier Win2k laufen,
an den oben erwähnten Stellen in der Registry kann ich nur den LPT1
finden, zu der Zusatzkarte findet sich dort nix.
Die Karte wird (unter COM und LPT) angezeigt mit diesem Namen:
"NetMos 9705 PCI Parallel Port"
Erstes auffinden hier (Treiberinfo):
alles was dadrunter kommt hab ich exportiert und ist im Anhang zu
finden.
In den Einträgen kommt die Adresse auch irgendwie vor: EC00, aber wie
man das dort rausliest ist noch etwas cryptisch, da zuviele 00en drumrum
sind.
Aber die Endadresse EC3F findet sich.
Wenn ich noch was ausprobiern soll, steh ich gern zur Verfügung.
Es wäre noch praktisch weitere Karten dieser Art zu haben, ob sich auch
alle nach diesem Schema verhalten.
Wie befürchtet scheitert die Registry-Methode beim /MSDOS mit
GUI-Aufsatz/.
Und für Tiny 80 mit der exotischen LPT-Karte scheint es auch nichts zu
bringen.
Insofern hat sich IMHO die Anpassung von AVRDUDE mit dem Suchen der Port
Baseaddress erledigt.
Vielleicht wäre ein individuell gepatchtes AVRDUDE für Tiny 80 oder eine
Detailanpassung über die Kommandozeil/Konfiguarationsfile eine
tauglicher Workaround.
Ich glaube, dann ist es das einfachste, dass man den Port-Parameter
,,magisch'' macht: entweder ist es lpt[1-3], dann wird die
Standardadresse intern ermittelt, ansonsten wird das Ganze als
Zahl interpretiert und direkt als Basisadresse benutzt.
Schade. Manchmal ist Windows schlicht ätzend. Alles so schön
konsistent. Da hat man schon eine Abbildung der Bus-Hierarchien
in der Registry, aber dann wird sie nichtmal konsistent benutzt.
Naja, man könnte ja auch einfach die nichtfunktionalen Windows-Versionen
endlich mal vergessen. Windows95 und seine Aufgüsse (98, Me) sind halt
ein Krampf an einer sehr dunklen Stelle und MS hat -endlich mal!- was
sinnvolles getan, als sie dieses Zeug abgeschafft haben.
Die letzte wenigstens erträglich stabile Pseudo-Windows-Version war wohl
98se, und das geht mit großen Schritten auf 10 Jahre Alter zu.
Unterstützt eine durchschnittliche Linux-Applikation bzw. ein
durchschnittlicher Linux-Treiber auch 10 Jahre alte Distributionen?
Rufus t. Firefly wrote:
> Unterstützt eine durchschnittliche Linux-Applikation bzw. ein> durchschnittlicher Linux-Treiber auch 10 Jahre alte Distributionen?
Weiß ich nicht, ich bin nur halbherzig (auf Arbeit, weil's da so
vorgeschrieben ist) Linuxianer, sonst mache ich FreeBSD. ;-) Mein
*BSD-Vorzeigebinary ist immer noch das hier:
1
% ls -l /usr/local/bin/utree
2
-rwxr-xr-x 1 bin bin 179639 Apr 30 1992 /usr/local/bin/utree*
Den Sourcecode habe ich wohl schon im Laufe der Jahre 1992 oder 1993
verlegt... das Binary läuft (*) immer noch, auch wenn ich es nicht
mehr wirklich benutze. Ich hebe es nur noch aus Nostalgiegründen
auf. ;-)
(*) termcap-Einträge durften damals nur maximal 1024 Bytes lang werden,
und da das seinerzeit alles statische Bibliotheken waren, ist diese
Restriktion hart ins Programm reincompiliert. Wenn man es heute noch
starten will, muss man daher einen Terminaltyp benutzen, dessen Eintrag
kurz genug ist, bspw. vt100. Der aktuelle xterm-Eintrag hingegen ist
länger und führt entsprechend zu einem coredump.
Das Beeindruckende daran ist, dass 386BSD (der Vorgänger von FreeBSD
und NetBSD) zum Zeitpunkt, da dieses Programm compiliert worden ist,
eigentlich nur eine völlig instabile "Bastlerware" der Version 0.0
war, die es gerade mal einen reichlichen Monat öffentlich auf FTP-
Servern gegeben hat.
Später gab es bei FreeBSD mal irgendwelche Umstellungen innerhalb
der Systembibliotheken, die tatsächlich Programme erzeugen konnten,
die danach nicht mehr lauffähig waren. Allerdings betrifft das m. W.
nach lediglich Programme, die zwischenzeitlich auf Entwicklungs-
versionen (direkt aus dem CVS gebaut) compiliert worden sind, während
sämtliche Binaries aus FreeBSD-Releases nach wie vor lauffähig sein
sollten, sofern man die zugehörigen shared libs noch mit installiert
hat (die ja gottlob unter Unix, anders als bei Windows, relativ
sauber versioniert worden sind, sodass man die alten Bibliotheken
parallel zu aktuellen Versionen mit installiert haben kann).
Hallo zusammen,
wollte mal nachfragen, ob sich ein avrdude-Insider diesem Thema
angenommen hat ?
Ich als Java-geschädigter muss erstmal Kernighan/Ritchie aus dem Regal
holen, um die fortgeschrittenen C-Basics aufzufrischen ;-)
Thread beobachten
Seitenaufteilung abschalten