Ho la necessità di inviare un byte contemporaneamente su 8 porte seriali (reali o virtuali), allo scopo di sincronizzare altrettanti dispositivi.
Sapete di qualcosa che mi può consentire di farlo? Avevo pensato a un convertitore USB/multi-seriale della Moxa, ma ho chiesto e mi hanno detto che questa funzionalità non è presente.
Mi andrebbe bene anche inviare il byte a intervalli di tempo noti, ma dovrebbero essere noti con una precisione notevole (diciamo al us).
uhm... ti stai riferendo a un pc, giusto? Se ti serve un'accuratezza sul sincronismo dell'ordine dei us ci fai poco. L'invio alle porte seriali lo dovresti fare con istruzioni successive (invii alla prima, poi alla seconda ecc) e quindi non saranno contemporanee.
Nemmeno la ripetizione a tempi regolari è possibile per via dell'incertezza temporale con cui il s.o. evade le richieste del tuo programma. Per lo meno in ambiente windows.
Per un problema simile avevo risolto in maniera hw. Il pc invia il pacchetto di sincronismo su *una* seriale. A quel punto tramite una schedina dividi la linea in 8 (usando i normali convertitori tipo MAX232 e simili).
Già starai dicendo che poi però le seriali ti servono collegate tutte e
8 al pc... beh, volendo basta prevedere uno switch (elettronico) che permetta di instradare diversamente i dati:
il pc emette un pacchetto di pre-sincronismo
le schedine commutano sul canale "broadcast"
il pc emette il pacchetto di sincronismo
le schedine riabilitano la comunicazione indipendente
Questo assumento che non hai a disposizione altri pin sulle periferiche utilizzabili per sincronizzarle.
Il giorno Wed, 27 Jan 2010 10:49:02 +0100, "stinf" ha scritto:
Puoi mettere in parallelo gli RX aa un unico TX o devi rispettare un protocollo?
A che velocità e distanza devi lavorare?
Il driver RS232 dovrebbe farcela a gestire una comunicazione non troppo lontano o non troppo veloce anche con 8 ricevitori attaccati, mal che vada metti un buffer, tipo una coppia PNP-NPN come inseguitori.
Con windows e la sua gestione dei tasks la vedo durissima.
Puoi usare una seriale per l'impiego specifico, in OR con le altre 8 indipendenti (totale: 9 seriali). Ovviamente dovrai convertire le RS232 in TTL, fare l'OR con quella "broadcast" e riconvertire i livelli. Questo solo per la linea TX di ogni seriale, ovviamente.
Innanzitutto grazie a tutti e tre per le risposte. Mi rendo conto di non essere stato chiarissimo. Le seriali sono 485 half duplex a 57600 bps, eventualmente convertite in 232 o USB. Il segnale di sincronia deve far partire l'acquisizione da parte dei sensori a bordo dei dispositivi. Ciò significa che appena riceveranno il segnale le schede cominceranno a inviare dati sulla seriale stessa; questi dati dovranno naturalmente essere prelevati e salvati dal pc che gestisce il tutto. Questa è anche la ragione per cui non collego tutte le seriali in un unico bus 485: non sarei in grado di gestire le collisioni. L'idea che mi ero fatto era di trovare un convertitore tipo quello della Moxa (USB -> 8xRS485) che avesse in hardware la possibilità di fare questa operazione, magari mediante un semplice comando al driver. A quanto pare, però, questo non sarà possibile.
So bene che il S.O. rappresenta un ostacolo non da poco, però ho il problema di dover risolvere la questione in tempi brevi, e questa (se fosse stata possibile) mi era sembrata la via più rapida.
Dai vostri suggerimenti mi è però venuta un'idea: se montassi 8 convertitori
232-485 e mettessi i TX in parallelo e gli RX separati, potrei riuscire nell'impresa? Chiaramente dovrei prevedere 8 seriali 232 sul pc con unicamente la parte RX per ricevere i dati, più una ulteriore seriale per mandare il pacchetto broadcast (come suggerito da Piccio, con in più la parte di conversione).
Il giorno Wed, 27 Jan 2010 13:00:40 +0100, "stinf" ha scritto:
Un po' dispendiosa come idea ma può funzionare, le seriali normalmente hanno una fifo all'interno che tiene fino a 16 caratteri, quindi le puoi leggere anche con un certo ritardo. Mi sembra che anche le schede multiseriali avessero la fifo, ma non sono sicurissimo, ne ho usate ma è stato tempo fa.
Se dici che non puoi gestire le collisioni in RS485, ma in un sistema master-slave come il tuo è relativamente semplice, mettere tante porte è l'unica soluzione.
se si tratta di un PC con porte seriali e sistema operativo, quanto puo' =
impiegare tra la gestione della 1=B0 seriale e la gestione dell' ultima ?
anche se le UART hanno un clock in comune, hanno generatori di baudrate indipendenti; lavorando agganciate a questa loro base dei tempi, anche con una gestione perfettamente contemporanea, potrebbero generare i loro segnali seriali in modo non contemporaneo. potresti forse usare i segnali di handshake, se reagiscono subito.
non vedo altro modo che non sia quello che ti hanno gia' suggerito.
Sicuramente è un po' macchinosa, tuttavia ho già i convertitori, quindi dovrei comprare solo il convertitore USB/multiseriale.
Quello che vorrei comprare ha 128 byte per ciascuna seriale...
Beh, la complicazione è nel firmware dei dispositivi che acquisiscono e inviano, e che invece dovrebbero gestire la collisione nel caso in cui avvenga.
Comunque, mi sa che farò qualche prova con questo sistema. Grazie
Esatto, è così. La sincronizzazione tra i sensori viene gestita mediante timestamp, e comunque i singoli clock sono sufficientemente precisi per lo scopo.
No, non ho queste esigenze. Per quanto mi riguarda, il segnale di avvio può anche essere inviato fisicamente ai sensori mezz'ora dopo averglielo detto, l'importante è che arrivi insieme a tutti i sensori.
Il giorno Wed, 27 Jan 2010 17:30:08 +0100, "stinf" ha scritto:
In un sistema master-slave non si devono gestire le collisioni come in un multimaster, in quel caso ti consiglierei il CAN.
Il protocollo è abbastanza semplice. Il master (in questo caso il PC) chiama una periferica e questa risponde, la presenza di un byte di CRC in fondo è a garanzia dell'integrità della stringa trasmessa, poi segue un byte di ACK o NACK a seconda dei casi.
In caso di collisioni (molto remoto) si deve solo gestire un errore di CRC, e il master rinnova la richiesta, così come nel caso la periferica non risponda dopo un tempo massimo.
"stinf" ha scritto nel messaggio news:hjp25b$g7v$ snipped-for-privacy@news.task.gda.pl...
Sei per forza legato a RS485 o RS232 ?
Se potessi utilizzare il CAN, avresti :
-protocollo realtime
-possibilità di messaggi broadcast
-possibilità di impostazioni di filtri sui messaggi (anche se tutte le periferiche sono collegate in parallelo,solo il pc processa di fatto i messaggi)
-velocità nettamente superiori e controllo automatico delle collisioni
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.