View Full Version : [c++] come gestire una porta seriale....
da un pò di tempo ho in mente di costruire un sistema di acquisizione dati tramite una porta seriale e di interfacciare un PIC con il Pc... Dato che conoscevo il basic ed il pascal ed avevo voglia di crescere ho deciso di implementare un programma in c++. Volevo realizzare qualcosa cross platform e pensai di usare WXdev-cpp con una libreria free la libwxctb, decisi inoltre di leggere un libro sul c++ [Horstmann] ma mi accorsi che c'era ben poco di quello che volevo trattare....
Qualcuno di voi ha fatto delle esperienze del genere?
Poi una considerazione o meglio uno sfogo, in effetti ho capito che, mentre negli anni 80-90 con un pò di inventiva riuscivi a fare tanto oggi non è più così. Per esempio secondo quanto ho letto, se nn ho capito male, per gestire una seriale in win32 con la benedizione M$ devo usare le API WIN32 :doh: :doh: ma può essere????? Ma a cosa servono i s.O. di ultima generazione se rendono così difficile gestire l'hW???
variabilepippo
08-11-2007, 15:44
Ma a cosa servono i s.O. di ultima generazione se rendono così difficile gestire l'hW???
In realtà i sistemi operativi di ultima generazione semplificano l'accesso all'hardware esponendo delle API standard, in tal modo evitano (o comunque cercano di limitare le possibilità) che un programmatore inesperto/sbadato/con cattive intenzioni/etc mandi in crash il sistema accedendo nel modo sbagliato a risorse fisiche. Chi ha usato sistemi privi di un HAL sa a cosa mi riferisco... :)
Se hai proprio bisogno/voglia di bypassare le funzioni dell'API ad alto livello messa a tua disposizione dall'OS puoi sempre implementare un bel device driver. Ci sono drivers (GiveIO, PortIO, etc) che consentono di accedere all'hardware in modo più diretto.
ma adesso nn vorrei sbagliare ma... cmq se non sbaglio, il vecchio QB apriva banalmente un flusso su porta aprendo un file di lettura-scrittura, cosa che mi sembra ragionata e compatibile con il concetto di stream (cout e cin). Il driver è una soluzione ma nn so se in effetti quanto è poi compatibile con un programma cross platform.. meglio la libreria libwxctb... Ma a proposito di crash, a me le API nn sembrano trasparenti e chi dice che siano affidabili e poi su Linux come lo ricompilo...devo mettere nelle mie macchine un pizzo per la M$ ?(ma sono in effetti delle macro??).
mad_hhatter
08-11-2007, 16:04
ma adesso nn vorrei sbagliare ma... cmq se non sbaglio, il vecchio QB apriva banalmente un flusso su porta aprendo un file di lettura-scrittura, cosa che mi sembra ragionata e compatibile con il concetto di stream (cout e cin). Il driver è una soluzione ma nn so se in effetti quanto è poi compatibile con un programma cross platform.. meglio la libreria libwxctb... Ma a proposito di crash, a me le API nn sembrano trasparenti e chi dice che siano affidabili e poi su Linux come lo ricompilo...devo mettere nelle mie macchine un pizzo per la M$ ?(ma sono in effetti delle macro??).
per interfacciarti all'hardware devi sempre passare per il s.o. (per i motivi che ti hanno già esposto)... quindi in ogni caso in windows fai una cosa e in linux ne fai un'altra...
poi con le api win32 può benissimo essere che ti diano in mano uno stream di ingresso e uno in uscita: tu gestisci i flussi, il s.o. si arrangia a dialogare con la porta seriale.
esiste persino una soluzione per java (se ti interessa la portabilità), ma ovviamente fa uso di JNI e di driver specifici per ciascun s.o. (attualmente il pacchetto javax.comm è alla versione 3, la quale supporta linux ma non windows... per quest'ultimo devi cercare la versione 2 (non sul sito Sun, ma nel sito di qualche università mi pare... cerca con google))
variabilepippo
08-11-2007, 16:07
da cancellare
variabilepippo
08-11-2007, 16:11
cmq se non sbaglio, il vecchio QB apriva banalmente un flusso su porta aprendo un file di lettura-scrittura
Quale "vecchio QB"? Quello per DOS? :rolleyes:
Il driver è una soluzione ma nn so se in effetti quanto è poi compatibile con un programma cross platform
Un driver è quanto di meno cross-platform esista, è legato a doppio nodo al sistema operativo e all'hardware specifico. Ovviamente se vuoi implementare un software multi-piattaforma dovrai utilizzare (o scrivere) delle librerie portabili: non esistono dei metodi "standard" per accedere all'hardware...
Ma a proposito di crash, a me le API nn sembrano trasparenti e chi dice che siano affidabili
Di sicuro sono molto più affidabili del codice che potrebbe scrivere un "casual programmer", poggiano su un paio di decenni abbondanti di utilizzo su vasta scala e sul lavoro di un numero imprecisato di sviluppatori professionisti. :)
Fanno esattamente ciò che è descritto nella relativa documentazione, basta studiarsela un po'.
e poi su Linux come lo ricompilo...devo mettere nelle mie macchine un pizzo per la M$ ?
Sei liberissimo di scegliere la tua piattaforma di sviluppo, ma se pretendi di usare codice non banale specifico per Linux su Windows (e viceversa) senza alcuna modifica allora forse stai sbagliando qualcosina.
Purtroppo (o per fortuna) con i sistemi operativi Windows attuali non è possibile accedere direttamente all'hardware...quindi su Windows o usi le API Win32 o usi una libreria che usa le API Win32...non ci sono alternative ;)
Un programma che accede direttamente all'hardware scritto per DOS o per i vecchi Windows da Windows 2000 in poi non funziona più...
conosci la libreria libwxctb, è una libreria per la gestione delle porte seriali crossplatform, vai a vedere su www.iftools.com. In effetti i casual programmer sono una versione free del professional programmer e spesso sono i primi a creare qualcosa di innovativo..;) ;) poi molti (come me) ritengono che il valore aggiunto del software sia nel codice che forma l'applicazione e non nei so che li devono far girare.. e il cross platform dovrebbe essere l'obiettivo di tutti :rolleyes: :rolleyes:
Non la conoscevo, ma se è cross platform dovrebbe fare al caso tuo. Mi immagino che la utilizzerai insieme alle wxWidgets ;)
Hai già fatto qualche prova ?
Working in slow progress.. cmq se funziona (e spero di si) realizzare un programma che gestisca un sistema embed dovrebbe essere un gioco da ragazzi. Nel senso che i Pic hanno una porta usb e che il driver microchip trasforma in una seriale ed una seriale vera , per cui sotto qualsiasi s.o (WINZOZ compreso) dovrebbe essere facile creare un sw crossplatform con questa libreria...
speriamo che funzioni..
mad_hhatter
08-11-2007, 16:55
Working in slow progress.. cmq se funziona (e spero di si) realizzare un programma che gestisca un sistema embed dovrebbe essere un gioco da ragazzi. Nel senso che i Pic hanno una porta usb e che il driver microchip trasforma in una seriale ed una seriale vera , per cui sotto qualsiasi s.o (WINZOZ compreso) dovrebbe essere facile creare un sw crossplatform con questa libreria...
speriamo che funzioni..
non QUALSIASI: solo quelli supportati (che, stando alla documentazione, sono linux e win32).
si solo linux e windows ma senza driver ed api ..... Mi chiedo se funzionerà....cmq sarebbe bello sapere se qualcuno è riuscito!
mad_hhatter
08-11-2007, 21:19
si solo linux e windows ma senza driver ed api ..... Mi chiedo se funzionerà....cmq sarebbe bello sapere se qualcuno è riuscito!
non e' possibile accedere all'hardware senza passare per il s.o. quindi le api le usano per forza
tomminno
08-11-2007, 22:33
Non la conoscevo, ma se è cross platform dovrebbe fare al caso tuo. Mi immagino che la utilizzerai insieme alle wxWidgets ;)
Hai già fatto qualche prova ?
In realtà il nome crea confusione, non capisco perchè abbiano chiamato tutte le classi con il prefisso wx, forse intendevano integrarla nella libreria, in realtà è completamente indipendente.
Ho avuto modo di usarla per delle prove a lavoro e fa il suo sporco lavoro wrappando tutto il casino che serve alle Win32 per realizzare una comunicazione seriale non bloccante.
da un pò di tempo ho in mente di costruire un sistema di acquisizione dati tramite una porta seriale e di interfacciare un PIC con il Pc... Dato che conoscevo il basic ed il pascal ed avevo voglia di crescere ho deciso di implementare un programma in c++. Volevo realizzare qualcosa cross platform e pensai di usare WXdev-cpp con una libreria free la libwxctb, decisi inoltre di leggere un libro sul c++ [Horstmann] ma mi accorsi che c'era ben poco di quello che volevo trattare....
Qualcuno di voi ha fatto delle esperienze del genere?
Poi una considerazione o meglio uno sfogo, in effetti ho capito che, mentre negli anni 80-90 con un pò di inventiva riuscivi a fare tanto oggi non è più così. Per esempio secondo quanto ho letto, se nn ho capito male, per gestire una seriale in win32 con la benedizione M$ devo usare le API WIN32 :doh: :doh: ma può essere????? Ma a cosa servono i s.O. di ultima generazione se rendono così difficile gestire l'hW???
con mfc & vs ci sono 3 funzioni da usare e sono le stesse per i file stream
createfile readfile writefile
come stream devi mettere la porta in questo modo:
"COM1:\0" ecc
poi ci sono i vari param tipo numero di caratteri letti e scritti overlap o meno ecc
per l'overlap oltre all'handle devi anche creare la funzione che gestisce l'overlap
per testare puoi usare come controparte hyperterminal settato ansi ecc
se è quello che ti interessava...
mi fai un taglia ed incolla di esempio di una comunivcazione su porta com1 a 2400 bps e fullduplex?
qui non posso perchè il codice ce l'ho su un altro pc e riguarda la comunicazione 115200 8N1 senza controllo di flusso
qui non ho neanche i segnalibri sottomano, lunedi' direi
cmq guardi sul tutorial microsoft trovi gli esempi con overlap e senza e i prototipi e parametri li trovi premendo f1 su visualstudio
per i parametri che dici c'e' la classe che gestisce l'handle della porta, basta semplicemente assegnare i parametri, una boiata davvero
più complicato a dirsi che a farsi: si complica leggermente la cosa con overlap
tu per non bloccante intendevi quello ???
perchp la readfile è effettivamente "bloccante" (blocca il controllo del codice) se non usi lìoverlap
tomminno
11-11-2007, 11:10
con mfc & vs ci sono 3 funzioni da usare e sono le stesse per i file stream
createfile readfile writefile
come stream devi mettere la porta in questo modo:
"COM1:\0" ecc
poi ci sono i vari param tipo numero di caratteri letti e scritti overlap o meno ecc
per l'overlap oltre all'handle devi anche creare la funzione che gestisce l'overlap
per testare puoi usare come controparte hyperterminal settato ansi ecc
se è quello che ti interessava...
Scusa ma se c'è già una libreria che gli consente di fare tutto questo semplicemente istanziando un oggetto e usando i metodi open/read/write e oltretutto funzionante anche su linux, non vedo perchè andarsi a sporcarsi le mani con le WIN32.
Ho provato ad usare sta benedetta libreria..... Ma nn riesco ad installarla su dev-cpp ... qualcuno può aiutarmi........???
:help: :help: :help: :help: :help:
variabilepippo
11-11-2007, 17:29
Ma nn riesco ad installarla su dev-cpp ... qualcuno può aiutarmi.
Premessa: Dev-C++ ormai può essere definito un "giocattolo", ti suggerisco di passare ad un ambiente di sviluppo più recente, meno buggato e soprattutto più professionale.
Cosa intendi con "non riesco ad installarla"? L'hai compilata con MinGW?
Se posso darti un ulteriore suggerimento: installa la nightly build di Code::Blocks, configura l'IDE per usare MinGW ed usa il CodeBlocks project file di libwxctb (http://www.iftools.com/download/ctb/libwxctb-0.8.cbp) per compilare la libreria ed il relativo programma dimostrativo.
io sto usando wxdeV-c++ che poi non è tanto male.... cmq io ho visto che esistono dei file .bkl che dovrebbero essere come delle macro per una utility che si chiama bakefile...
Cmq non ho nessun problema a cambiare IDE ovviamente deve essere cross platform! se installo code::block riesco a fare del crossplatform ? e poi tu hai provato con questa libreria su codeblock?
variabilepippo
11-11-2007, 17:58
se installo code::block riesco a fare del crossplatform ? e poi tu hai provato con questa libreria su codeblock?
wxDev-C++ è anche peggio di Dev-C++, se possibile! :)
Inoltre wxDev-C++ funziona esclusivamente su Windows mentre Code::Blocks supporta sia Windows, sia Linux. Per scrivere un'applicazione multi-piattaforma non è tanto importante l'editor utilizzato quanto il codice scritto.
Sì, ho provato la libreria in Code::Blocks: la libreria ed il programma dimostrativo compilano senza problemi.
procedo con l'installazione....
variabilepippo
11-11-2007, 18:29
procedo con l'installazione....
NON installare la versione 1.0RC ma la release più recente (http://forums.codeblocks.org/index.php/topic,7176.0.html). Volendo puoi installare il compilatore MinGW 4.2.1 (Technology Preview) al posto del "vecchio" 3.4.x.
ok... l'esempio funziona ma tranne che con la porta com26 :muro: :muro: :muro: che è quella he mi serve :muro: :muro: :muro: e che casino.... sai aiutarmi ?:help:
variabilepippo
11-11-2007, 18:53
l'esempio funziona ma tranne che con la porta com26
Quale errore ricevi?
error: 'wxCOM26' was not declared in this scope
Ma che significa... nell'esempio non posso scegliere la porta o sbaglio ?
tomminno
11-11-2007, 19:53
error: 'wxCOM26' was not declared in this scope
Ma che significa... nell'esempio non posso scegliere la porta o sbaglio ?
La libreria di suo include le costanti per gestire fino alla COM16.
Se guardi il file serport.h ti accorgi di come sono definite le costanti wxCOMXX, se vuoi la com26 dovrai aggiungere.
/*per linux*/
#define wxCOM26 "/dev/ttyS25"
/*per Windows*/
#define wxCOM26 "\\\\.\\com26"
funziona grazie... adesso c'è da studiare la doc :read:
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.