Newsgroup: it.comp.programmare.win32
Titolo: Come realizzare device driver tipo 'porta seriale' ?

Per un sensore da me realizzato, che 'parla' col mondo esterno via tcp/ip, 
avrei bisogno di scriver un driver da installare in ambiente windows (da xp 
in poi) che mi permetta di 'vedere' il sensore come na porta seriale
In sostanza attualmente ho questo scatolotto che misura diciamo una 
temperatura e la cui elettronica integra un web server che risponde alle 
interrogazioni impartite dal computer
Dispongo inoltre di un software commerciale che 'parla' con l'esterno 
solamente tramite porta seriale ed al quale vorrei collegare il mio sensore, 
quindi avrei bisogno di realizzare un device driver che mi permetta di 
connettere il mio sensore ad una com virtuale
Un po' quello che si fa qando si collegano quei convertitori usb-rs232
Da dove posso iniziare (a parte strapparmi i capelli per la malsana idea) ?
RobertoA


Personalmente ti sconsiglio di crearti un driver se non hai esigenze 
particolari. Due dei tanti problemi:
- se c'è un bug nel driver hai un BSOD (a meno che non scrivi un driver 
in usermode)
- se il driver è kernel mode devi firmarlo con un certificato digitale 
per la piattaforma x64
Se non hai bisogno di velocità pazzesche, ti conviene mettere un 
transciever USB to serial e gestire tutto con una COM virtuale.
Io personalmente uso il classico FT232:
http://www.ftdichip.com/Products/ICs/FT232R.htm
In pratica pluggo il mio device USB su un PC, Windows Update 
automaticamente scarica e installa il driver, e sul device manager 
ottieni una nuova porta COM(x)
Quel chip prevede addirittura delle I/O su cui puoi già fare alcune 
cose. Personalmente lo uso con la seriale del PIC a 115K e va che è una 
meraviglia.
Se ti serve un hardware più complesso puoi optare per il MicroFramework 
con una scheda semipronta a partire dai 35 Eur in su (
tinyclr.com
 ==> 
GHI o Netduino sono le più famose).
Su MicroFramework hai USB client e host, una marea di interfacce, 
TCP/IP (compreso WiFi, WCF, etc.), totale controllo delle I/O ma non 
hai il realtime. La comodità è che lo programmi in C# con VS.net
Se poi vuoi rendere facile l'uso da applicazioni che girano da Win7 in 
su, puoi scriverti (in aggiunta a quanto detto sopra) un driver 
user-mode che trasforma la tua periferica (sia che vada sulla seriale 
che con un tuo driver) in un "Sensore".
Le Sensor API sono nuove di Win7 e su questo si può parlare per 
giornate :)
Ti ho fatto più confusione? :)
-- 
Raffaele Rialdi  
http://www.iamraf.net
Weblog: 
http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile 
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - 
http://www.ugidotnet.org/


I miei 2 cents:
ti procuri com0com 
http://com0com.sourceforge.net/
 che ti permette di 
realizzare un "null modem" virtuale. Praticamente ti crea una coppia di 
com virtuali collegate tra loro.
A questo punto ti scrivi un "driver" in user mode che parla con il tuo 
dispositivo e una delle due seriali virtuali, e dall'altra parte ti 
rimane una seriale per il sw commerciale.
In pratica:
DEVICE  <-TCP/IP-> Tuo "driver" <-> VirtualPort0 <-> Com0Com <-> 
VirtualPort1 <-> SW commerciale
HTH

Invece di farsi tanti problemi di drivers, che un costo di sviluppo c'è 
l'hanno, perchè non pensare ad una soluzione hardware già fatta?
http://www.qfp.it/et-box.php
ciao.
Giuliano.
Il 31/03/2011 17.06, RobertoA ha scritto:


 ha scritto nel messaggio 
news:mn.fc127db33...@n0spamvevy.com...

Ti ringrazio per la risposta, ma con un usb-rs232 non arrivo da nessuna 
parte
Forse mi sono spiegato male, il mio dispositivo e' gia' attivo, connettibile 
via ethernet ed interrogabile come un web server qualsiasi, fa conto che sia 
una come un'Arduino con lo shield ethernet
Questo da un lato 'campo'
Dall'altro lato c'e' un software commerciale, diciamo LabView tanto per 
capirci, che e' predisposto per comunicare con periferiche sulle porte 
seriali
Questo dal lato 'ufficio'
Quindi dal campo all'ufficio gia' ci arrivo sia come hardware che come 
software, il problema sono le due 'lingue' diverse che parlano il sensore ed 
il programma che deve usarne i dati
Sul lato 'ufficio' DEVO avere una porta seriale tipo rs232 perche' 
altrimenti il software non riesco a sfruttarlo
Per questo cercavo il modo di realizzare un driver tipo quello che 
forniscono con i chip ftdi
Finora, l'unico modo di far funzionare il tutto e' di realizzare una basetta 
ethernet-rs232 in modo che i comandi spediti dal programma vengano tradotti 
in comandi su tcp/ip ed i risultati che dal web server arriveranno verranno 
riconvertiti in byte sulla rs232 e 'visti' dal programma che li elaborara'
Non avendo mai messo in piedi un driver per periferica mi attirerebbe 
tentare questa possibilita' piuttosto che andare giu' di basetta
Ma non so esattamente da dove cominciare
Ciao
RobertoA


Miiiiii che progettino
Questo E' un driver tipo quello che servirebbe a me, nel senso che ci sono 
pure i sorgenti
Sara' una bella battaglia, ma almeno c'ho qualcosa da seguire
Grazie mille
RobertoA

 ha scritto nel messaggio 
news:in41ae$lod$1...@speranza.aioe.org...


 Ma non so esattamente da dove cominciare
Ok, tutto più chiaro. Il consiglio di GM mi sembra l'unica soluzione 
solo-software non complessa.
Non l'ho mai usata e non so se funzioni nel tuo caso.
Rimane valida la soluzione microframework con netduino/GHI o se 
preferisci altro sistema analogo.
Non hai bisogno di basetta, ti basta metterci un device "as is" che 
abbia ethernet e seriale.
Se usi microframework il bridge lo fai con C# evitandoti i grattacapi 
del driver virtuale-seriale.
Altrimenti puoi partire dai sorgenti di com0com e vedere com'è fatto il 
loro driver.



Ma scusa, hai un sensore che dialoga con TCP/IP ed ha un webserver che 
gira sopra, non ha una porta ethernet?
Se pure volessi far veicolare i dati attraverso una seriale (lavoro 
immenso nonchè inutile), non vedo perchè hai bisogno per forza di un driver.


Aspetta, forse la versione com0com non l'ho spiegata bene:
com0com lo installi e lo configuri in modo che crei una coppia di com 
(chiamiamole com3 e com4) che internamente sono collegate fra loro in 
modo da creare un null-modem virtuale. Questo è banale: basta installare 
com0com e configurare due parametri (c'è pure un tool a finestra per farlo)
A questo punto due programmi qualsiasi *in user space* (non driver) 
possono aprire com3 e com4. Quello che il programmaA scrive su com3, il 
programmaB lo legge da com4 e viceversa.
A questo punto devi solo scrivere un bridge col linguaggio che ti pare 
(anche C#) che converte dal TCP/IP del device verso una delle due com.
Il programma commerciale lo attacchi all'altra com.
Fine. Nessun sorgente da studiare. Nessun driver da scrivere.

 Fine. Nessun sorgente da studiare. Nessun driver da scrivere.
Si, chiarissimo, infatti dicevo "non complessa" e sulla pagina di 
progetto di com0com c'è anche la parte com2tcp pronta.
C'è solo da capire se il flusso di dati è abbastanza 'pulito' da filare 
tutto liscio o se c'è da smanettare con setting specifici della 
seriale.
Nel peggiore dei casi un device microframework esterno può emulare in 
modo ancora più trasparente il device e il costo in termini di codice è 
veramente minimale.



Si, ora e' piu' chiaro e credo anche facilmente approcciabile
Grazie
RobertoA

 veramente minimale.
Ti piacciono questi micro-cosi ehhh
In effetti sono dei piccoli capolavori, costano poco e pure facili da 
utilizzare 

 utilizzare
Ebbene si, lo confesso :)
