USB -> AVR -> Parallelport, geht das?

Dormann schrieb:
> Da fällt mir grade was ein:
>
> kann man nicht einfach den Rechner irgendwie im "Dos-Modus" booten?
> [...]

Klaro. Im Zweifelsfalle mit einer Bootdisk.

http://www.bootdisk.com/

Volker

uwe schrieb:
> Nur wenn man sich einen eigenen Treiber für XP schreibt (in beiden
> Fällen).
> Da wirst du dir wohl eigenen Treiber für schreiben müßen
> (höchstwarscheinlich Kernel) da Windows keine direkten Hardwarezugriffe
> mehr so einfach unterstützt. Windows behandelt den Parallelport nur noch
> als Drucker -> Das heißt du kannst ne Datei hinschicken über den
> entsprechenden Druckertreiber.
> Es gibt jedoch Tools die als Notlösung funktionieren (wie z.B. GiveIO)
> und deiner Software den entsprechenden IO Privileg Level verpassen.

Blödsinn. Der Druckerport lässt sich selbst unter Win7 direkt 
ansprechen. Hier Code: http://www.codeproject.com/KB/cs/csppleds.aspx

Stefan Noack schrieb:
> [...]
> Blödsinn. Der Druckerport lässt sich selbst unter Win7 direkt
> ansprechen. Hier Code: http://www.codeproject.com/KB/cs/csppleds.aspx

Wenn Du mal genau hinliest, steht da dass es eben nicht geht:

"When I was using Windows 98 I could reach the ports with a function 
which is "outportb". When I upgraded to Windows 2000 this failed because 
of its kernel. You can not reach the ports directly in NT, 2000 and XP 
because of their kernel and their printer drivers."

Der Autor benutzt einen frei erhaeltlichen Treiber (inpout32.dll), der 
inportb und outportb zur Verfuegung stellt. Das bringt einem freilich 
nichts bei bereits fertig compilierten Programmen...

Volker

Volker Schulz schrieb:
> Stefan Noack schrieb:
>> [...]
>> Blödsinn. Der Druckerport lässt sich selbst unter Win7 direkt
>> ansprechen. Hier Code: http://www.codeproject.com/KB/cs/csppleds.aspx
>
> Wenn Du mal genau hinliest, steht da dass es eben nicht geht:
>
> "When I was using Windows 98 I could reach the ports with a function
> which is "outportb". When I upgraded to Windows 2000 this failed because
> of its kernel. You can not reach the ports directly in NT, 2000 and XP
> because of their kernel and their printer drivers."
>
> Der Autor benutzt einen frei erhaeltlichen Treiber (inpout32.dll), der
> inportb und outportb zur Verfuegung stellt. Das bringt einem freilich
> nichts bei bereits fertig compilierten Programmen...
>
> Volker

Hm.. Stimmt. Diese Funktion gibt es im Kernel nicht mehr. Andererseits 
kann man auch einfach ein Handle mit der entsprechenden adresse (0x378) 
erstellen und munter Daten reinschreiben -- entsprechende Privilegien 
vorausgesetzt... (nichts anders macht wahrscheinlich die inpout32.dll)

Oder man benutzt "CreateFileA" aus kernel32.dll, um die Datei "LPT1:" zu 
öffnen. Das klappt lustigerweise auch. Man kann dann dort reinschreiben 
und die Bytes landen 1:1 am Parallelport. Allerdings hat man da keinen 
direkten Zugriff auf die Steuerleitungen.

Aber egal. Der Threadersteller bootet jetzt einfach sein DOS und gut ist 
:D

Stefan Noack schrieb:
> Hm.. Stimmt. Diese Funktion gibt es im Kernel nicht mehr. Andererseits
> kann man auch einfach ein Handle mit der entsprechenden adresse (0x378)
> erstellen und munter Daten reinschreiben -- entsprechende Privilegien
> vorausgesetzt... (nichts anders macht wahrscheinlich die inpout32.dll)

Davon gehe ich mal aus. Device Driver laufen im Kernel Mode und duerfen 
deshalb... ;)

> Oder man benutzt "CreateFileA" aus kernel32.dll, um die Datei "LPT1:" zu
> öffnen. Das klappt lustigerweise auch. Man kann dann dort reinschreiben
> und die Bytes landen 1:1 am Parallelport. Allerdings hat man da keinen
> direkten Zugriff auf die Steuerleitungen.

Und bekommt im Zweifelsfall auch Timingprobleme. Aber unter DOS sollte 
das ja dann stabil laufen... ;)

Volker