Leggere resistenza tramite porta seriale

[cicciopasticcio1]

Ciao a tutti,

ho a disposizione due circuiti che possono avere i seguenti stati logici: aperto (resistenza infinita) e chiuso (resistenza che non supera i 300-400 ohm).

Ogni tot tempo devo controllare entrambi i circuiti e registrare sul pc lo stato di questi due circuiti. Secondo voi posso farlo direttamente tramite porta seriale utilizzando i giusti pin? ( Ho visto progetti che accendevano led applicati direttamente all'uscita della porta seriale, il programma nel mio caso dovrebbe fare qualcosa di molto simile, ma verificando che la corrente che transita superi un certo valore).

So che potrei comprare un arduino ma vorrei evitare, anche perchè dovrei finirlo più velocemente possibile.

Ringrazio tutti quelli che si interesseranno della questione! :D

[sottovento]

La tua idea e' quella di collegare i due circuiti a due segnali di handshake, tipo RI/CTS (e al pin 7, ovviamente)?
Non e' male, dovrebbe funzionare. Non so che ambiente usi ma normalmente hai a disposizione delle primitive per leggere lo stato di questi segnali.


Ciao a tutti,

ho a disposizione due circuiti che possono avere i seguenti stati logici: aperto (resistenza infinita) e chiuso (resistenza che non supera i 300-400 ohm).

Ogni tot tempo devo controllare entrambi i circuiti e registrare sul pc lo stato di questi due circuiti. Secondo voi posso farlo direttamente tramite porta seriale utilizzando i giusti pin? ( Ho visto progetti che accendevano led applicati direttamente all'uscita della porta seriale, il programma nel mio caso dovrebbe fare qualcosa di molto simile, ma verificando che la corrente che transita superi un certo valore).

So che potrei comprare un arduino ma vorrei evitare, anche perchè dovrei finirlo più velocemente possibile.

Ringrazio tutti quelli che si interesseranno della questione! :D

[cicciopasticcio1]

La tua idea e' quella di collegare i due circuiti a due segnali di handshake, tipo RI/CTS (e al pin 7, ovviamente)?
Non e' male, dovrebbe funzionare. Non so che ambiente usi ma normalmente hai a disposizione delle primitive per leggere lo stato di questi segnali.

Ciao, ho cercato in questi giorni ed ho trovato e testato proprio la soluzione da te suggerita, e funziona non bene, ma benissimo!

Riesco a gestire ben 5 entrate che possono essere gestite in modo passivo da dei semplici interruttori. Questi sono i rispettivi pin che si possono utilizzare a tal scopo:

CTS
DSR
CD
Ring
Break


In questo modo posso collegare un qualsiasi sensore elementare (anche il sensore di movimento di un allarme, immagino) direttamente alla porta seriale a costo zero (o meglio, al costo di un adattatore USB-seriale, ovvero 3-4 euro).

Per completezza e per chi leggesse segnalo che il framework .NET permette di ricevere gli eventi generati dal cambiamento dei pin sopra elencati scrivendo poche righe di codice.

Alla prossima :D

[sottovento]

Per completezza e per chi leggesse segnalo che il framework .NET permette di ricevere gli eventi generati dal cambiamento dei pin sopra elencati scrivendo poche righe di codice.

Alla prossima :D

Complimenti!! Hai avuto davvero una bella idea.
Potresti scrivere un paio di righe sulla soluzione? Quali sono le primitive da chiamare in .NET per ottenere gli eventi?

ciao

[cicciopasticcio1]

Complimenti!! Hai avuto davvero una bella idea.
Potresti scrivere un paio di righe sulla soluzione? Quali sono le primitive da chiamare in .NET per ottenere gli eventi?

ciao
Certo

L'evento PinChanged http://msdn.microsoft.com/it-it/library/system.io.ports.serialport.pinchanged(v=vs.110).aspx è il cardine del tutto. Dopo aver connesso l'oggetto SerialPort con .open(), ogni cambiamento di stato dei vari pin è notificato attraverso questo evento.

L'unica cosa in cui ho trovato "problemi" è che è possibile accedere sempre e comunque allo stato di ogni pin (Break, CDChanged, CtsChanged, DsrChanged) tranne il Ring, non so per qualche strano motivo. Lo stato di questo pin non è direttamente accessibile se non esclusivamente attraverso l'evento PinChanged.

L'oggetto che ho attaccato all'altro capo della porta seriale è un pluviometro basculante, e funziona che è una meraviglia :D

[sottovento]

Grande!!
Qui
http://stackoverflow.com/questions/11621509/why-doesnt-the-serialport-class-have-an-riholding-property
provano a dare una spiegazione della differenza di trattamento del Ring Indicator rispetto agli altri segnali. Onestamente non e' molto convincente...

A proposito: scusami se sono pedante, ma immagino che abbia settato la seriale prima di fare i tuoi test. Corretto?
La comunicazione seriale in generale non ha bisogno di questi segnali addizionali per poter comunicare, in teoria basterebbe un filo (e la massa).
Questi segnali addizionali vengono detti di hardware hanshake e permettono di informare la controparte se si e' pronti a spedire/ricevere e di controllare il modem.
Via software e' possibile abilitarli/disabilitarli. Potrei per esempio disabilitarli nel caso il DCE non e' in grado di gestirli (spesso pero' si fanno i cavallotti).
Tutta questa spataffiata per chiedere se sei sicuro di aver abilitato l'hardware handshake nel tuo software o se ti sei affidato ai valori di default, i quali potrebbero essere diversi da installazione a installazione...



Certo

L'evento PinChanged http://msdn.microsoft.com/it-it/library/system.io.ports.serialport.pinchanged(v=vs.110).aspx è il cardine del tutto. Dopo aver connesso l'oggetto SerialPort con .open(), ogni cambiamento di stato dei vari pin è notificato attraverso questo evento.

L'unica cosa in cui ho trovato "problemi" è che è possibile accedere sempre e comunque allo stato di ogni pin (Break, CDChanged, CtsChanged, DsrChanged) tranne il Ring, non so per qualche strano motivo. Lo stato di questo pin non è direttamente accessibile se non esclusivamente attraverso l'evento PinChanged.

L'oggetto che ho attaccato all'altro capo della porta seriale è un pluviometro basculante, e funziona che è una meraviglia :D

[cicciopasticcio1]

Grande!!
Qui
http://stackoverflow.com/questions/11621509/why-doesnt-the-serialport-class-have-an-riholding-property
provano a dare una spiegazione della differenza di trattamento del Ring Indicator rispetto agli altri segnali. Onestamente non e' molto convincente...

A proposito: scusami se sono pedante, ma immagino che abbia settato la seriale prima di fare i tuoi test. Corretto?
La comunicazione seriale in generale non ha bisogno di questi segnali addizionali per poter comunicare, in teoria basterebbe un filo (e la massa).
Questi segnali addizionali vengono detti di hardware hanshake e permettono di informare la controparte se si e' pronti a spedire/ricevere e di controllare il modem.
Via software e' possibile abilitarli/disabilitarli. Potrei per esempio disabilitarli nel caso il DCE non e' in grado di gestirli (spesso pero' si fanno i cavallotti).
Tutta questa spataffiata per chiedere se sei sicuro di aver abilitato l'hardware handshake nel tuo software o se ti sei affidato ai valori di default, i quali potrebbero essere diversi da installazione a installazione...
Si, avevo già letto quella domanda di stackoverflow.

Il mio software è semplicissimo, tutto è relativo a valori di default dell'oggetto SerialPort e l'unica operazione che faccio prima di ricevere gli eventi è SerialPort.open(). Nient'altro, non ho abilitato niente! Mi sono meravigliato che fosse così semplice.

Probabilmente con altri cavi USB-serial e altri driver la situazione si potrebbe complicare.