Newsgroup: it.comp.programmare.win32
Titolo: mappatura usb to parallel port

ciao,
ho acquistato una interfaccia usb to parallel port.
Purtroppo non pare mappata sulle solite locazioni 378h o analoghe (beh, e' 
USB...)
per cui non riesco a pilotarla da visual c.
Funziona correttamente con la stampante (che quindi usa delle primitive che 
funzionano!)
ma non con le istruzioni dirette a porta parallela.
(puntualizzo che la parallela normale da visual C la uso regolarmente, anche 
su XP)
Qualcuno sa se esiste uno standard per accedere a risorse del genere su 
porta USB?
grazie
ciao
GCL 

porta USB?
Dipende dai driver e dal chip usato dal convertitore.
Se la vuoi usare come interfaccia di I/O temo che non potrai...
Con Google trovi facilmente produttori di hardware simile che
distribuiscono gratuitamente un SDK per accedere a tutte le
risorse disponibili.

 risorse disponibili.
mi dai un'idea della parola chiave da cercare?
grazie
GCL 

mi dai un'idea della parola chiave da cercare?
+usb +parallel +converter
Evita i rivenditori, vai sul sito dei costruttori.

 ha scritto nel messaggio 
news:s1q9g2pm2e5c7cnqi...@4ax.com...


 per cui non riesco a pilotarla da visual c.
ma stai cercando di pilotarla direttamente da assembly? che sistema
operativo usi?
prova semplicemente ad aprirla con CreateFile, come si farebbe per
qualsiasi normale porta parallela: dovrebbe funzionare.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 qualsiasi normale porta parallela: dovrebbe funzionare.
con la seriale funziona ma la parallela non la ho mai usata cosi..
come faccio ad accedere ai 3 registri interni (STATUS, CONTROL e DATA)?
GCL 

 come faccio ad accedere ai 3 registri interni (STATUS, CONTROL e DATA)?
ah non lo so :P
io non so come funziona una porta parallela, so solo che ci puoi leggere e
scrivere dati :D
comunque cerca su MSDN, lì c'è tutto (come sempre ovviamente).


 ha scritto nel messaggio 
news:R8FMg.14426$6Z1....@tornado.fastwebnet.it...

Ciao,
utilizzare direttamente la parallela da VisualC (a meno di non utilizzare 
una libreria ed un driver dedicati) significa utilizzarla attraverso uno dei 
protocolli standard della parallela, ma non puoi accedere ai registri, ci 
puoi solo scrivere e (dipende dal protocollo usato) leggere.
Per accedere ai registri di una  parallela reale NON ci sono alternative, 
occorre passare attreaverso un driver o direttamente (tramite 
DeviceIoControl) o tramite una interfaccia (librerie, dll...).
Ci sono poi i convertitori USB che ti forniscono 8 oin di I/O (cerca ad 
esempio USBMOD4); ma ti ricordo una limitazione: passare da scrittura a 
lettura implica una attesa di 1 ms (imposta dalla USB che comunica appunto 
ogni ms), mentre con flussi monodirezionali puoi arrivare a trasmettere o 
ricevere fino a 1MB/s e più.
ciao
Denis TT


Quuanto segue riguarda la parallela reale e NON quella fornita da 
convertitori, quella fornita dai convertitori NON ha i registri interni.
Per quanto riguarda quella REALE, semplicemente NON PUOI accedere ai 
registri interni perchè il driver della parallela (quello fornito col 
sistema) NON ne fornisce l'accesso. L'unico modo per accedere ai registri è 
tramite un driver scitto ad hoc, che non è un trucchetto ma l'unico modo per 
accedere ai registri. Un driver che fornisca l'accesso ai registri di 
parallela DEVE lavorare a livello kernel, quindi è tutto regolare; 
ovviamente se un driver kernel è fatto male può piantare il sistema, ma sono 
sicuro che se ne possono trovare di buoni.
Ciao
Denis TT

 sicuro che se ne possono trovare di buoni.
ma non è mica quello l'unico problema; evidentemente non sai che Windows
associa informazioni di sicurezza anche alle periferiche.
un programma che si suppone debba essere in grado di lavorare tanto con
porte parallele reali quanto con porte emulate non può avere la necessità
stretta di lavorare con registri interni di una porta parallela reale,
perciò non deve usare un driver.
per gestire informazioni sulla porta che le Communications API non ti
permettono di gestire puoi inviarle questi IOCTL:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ParPorts_r/hh/ParPorts_r/cisspd_f7811703-9576-4b17-8d03-b78dbef59a9f.xml.asp?frame=true
funzionano indipendentemente da che la porta sia reale o emulata da un
convertitore.


 ha scritto nel messaggio 
news:ee8jm1$m43$1...@news.newsland.it...

Se però devi leggere/scrivere direttamente i registri della parallela reale, 
in questo caso neppure le Communications API  ti vengono in aiuto.
A me purtroppo è capitato un caso del genere e l'ho risolto usando un driver 
che implementava il protocollo (non standard) utilizzato dal dispositivo con 
il quale dovevo comunicare.
Se il driver lavora direttamente con i registri, non ha più a che fare con 
una periferica e scavalca i problemi di sicurezza, o per lo meno nel mio 
caso ha funzionato, non ho indagato oltre.
Ciao
Denis TT 

 caso ha funzionato, non ho indagato oltre.
credo che tu non abbia colto il senso dei miei precedenti discorsi: la
sicurezza *non è* un problema, perché se un amministratore di sistema ha
voluto stabilire che i processi che girano sotto un certo account *non
devono* avere accesso all'hardware, così dev'essere. il tuo driver invece
scavalca bellamente, perché accede all'hardware senza utilizzare il
sistema offerto dal sistema operativo, che sarebbe CreateFile e compagnia
e che è soggetto alle regole di sicurezza. e tra l'altro il mio discorso
mirava anche ad evidenziare come il tuo approccio costringa a disturbare
l'amministratore di sistema per effettuare l'installazione del software
(l'amministratore o comunque un utente con privilegi elevati).
come se non bastasse adesso mi vieni a dire che sei andato a smanettare
con specifiche non standard.
non ti sembra di aver ecceduto in quanto a porcate? :D
ora però cercherò anche di essere obiettivo e di osservare il lato
positivo del tuo approccio: l'unico vero caso in cui esso possa (o
addiruttra debba) essere applicato è il caso di un software di gestione
hardware relativo a quello specifico modello di porta parallela e
distribuito assieme ad essa; magari nel CD di installazione dei drivers
della scheda madre, come utility di gestione. e in effetti questo è
l'unico caso in cui si può presentare la necessità stretta di accedere ai
registri specifici della porta.
e dulcis in fundo aggiungiamo anche alcune possibili eventualità a sfondo
didattico/hobbystico.
ma in tutti i rimanenti casi, in particolare quando il software deve
essere distribuito, questo approccio non dovrebbe mai essere usato.


 ha scritto nel messaggio 
news:eea8hh$nps$1...@news.newsland.it...

Sono d'accordo, ha capito la tua posizione, ma non ho trovato alternative: 
il dispositivo collegato imponeva il protocollo, mica l'ho inventato io il 
protocollo! Me lo sono trovato e... ho scomodato un pò di amministratori. 
Anch'io avrei preferito un approccio più sensato!
Ciao
Denie TT