USB-Schnittstelle anprogrammieren

Ist Dein Rechner ein Desktop? Wenn ja, schraube ihn auf und schau nach, 
was für Steckplätze (PCI oder PCIe) noch frei sind. Dann kaufst Du 
passend dazu eine dazu passende Schnittstellenkarte mit der benötigten 
Anzahl an seriellen und parallelen Anschlüssen. Die sollten sich wie 
Onboard-Ports verhalten, im Gegensatz zu USB-Adaptern, die immer wieder 
mal Probleme machen.

Das Teil hier hat beispielsweise 4 serielle Ports und ist für 
PCIe-Slots:

http://www.reichelt.de/Controller-parallel-seriell/EXSYS-EX-44094/3//index.html?ACTION=3&GROUPID=3838&ARTICLE=69675&SHOW=1&START=0&OFFSET=500&;

fchk

Gerhardt Specht schrieb:
> Gibt es einen seriellen Adapter, der unter WIn7-64bit ohne
> Probleme läuft und sich wie gewohnt mit Assembler oder in C ansprechen
> lässt, ohne rumzuzicken?

C ja, aber nur wenn du über die Windows Funktionen mit CreateFile(), 
ReadFile(), WriteFile() gehst. Alles was direkt auf die Port-Adressen 
zugreift geht schon längst niht mehr. Mit viel Gefrickel über DLPOrtIO 
evtl. auf echten seriellen oder parallelen Schnittstellen, aber auf USB 
nicht mehr.

Mit sauber für Windows programmierter Software laufen die USB-COM 
Adapter problemlos. Mit Software, die sich schon immer an den 
OS-Funktionen vorbei gemogelt hat, nicht.

oh weh schrieb:
> Aber die Handshakeleitungen (RTS etc.) werden arg langsam.

Wenn man die mit SetCommState anspricht ja. Mit HW-Handshake alles kein 
Problem.

oh weh schrieb:
> An solche Anwendungen hat Microsoft nicht gedacht, weil das
> Nischenanwendungen sind.

Also erstens mal liegt die Beschränkung bei den USB Wandlern nicht an 
MS, denn die haben USB nicht erfunden. USB ist paketorientiert und lässt 
daher keine schnellen Einzelbit-Änderungen zu.

Zweitens ist es sicher nicht Aufgabe eine Betriebssystemherstellers, 
Anwendungen zu unterstützen, die schon bei ihrer Entwicklung absichtlich 
damals schon etablierte Standards verletzen.

Das Gemecker über MS in solchen Punkten ist manchmal unerträglich.