[c++] come gestire una porta seriale....

[norih43]

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 ma può essere????? Ma a cosa servono i s.O. di ultima generazione se rendono così difficile gestire l'hW???

[variabilepippo]

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.

[norih43]

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]

Originariamente inviato da norih43

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]

da cancellare

[variabilepippo]

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?

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.

[cionci]

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ù...

[norih43]

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

[cionci]

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 ?

[norih43]

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]

Originariamente inviato da norih43

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).

[norih43]

si solo linux e windows ma senza driver ed api ..... Mi chiedo se funzionerà....cmq sarebbe bello sapere se qualcuno è riuscito!

[mad_hhatter]

Originariamente inviato da norih43

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]

Originariamente inviato da cionci

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.

[Stev-O]

Originariamente inviato da norih43

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 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...

[norih43]

mi fai un taglia ed incolla di esempio di una comunivcazione su porta com1 a 2400 bps e fullduplex?

[Stev-O]

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]

Originariamente inviato da Stev-O

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.

[norih43]

Ho provato ad usare sta benedetta libreria..... Ma nn riesco ad installarla su dev-cpp ... qualcuno può aiutarmi........???

[variabilepippo]

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 per compilare la libreria ed il relativo programma dimostrativo.