Come trovare la linea UART è gratuita per l'invio di dati

Ho diverse schede che comunicano insieme a Rs485. Hanno ATMegamicrocontrollori di serie come atmega168po atmega8. Ogni scheda è libera di inviare dati in qualsiasi momento e ho delle limitazioni che portano a non posso usare Modbus . Il numero di schede può variare da 5 a 10.

Il mio problema è: come può una scheda scoprire se la linea UART è libera di inviare dati e se rileva che il bus è occupato, attendere che il bus sia libero e quindi inviare i propri dati?

C'è un flag o un registro speciale che potrebbe cambiarlo automaticamente o manualmente e lasciare che l'altra scheda trovi che la linea è occupata ?

Benvenuti nella sfida più grande con i sistemi di comunicazione half-duplex.

RS-485 non è un protocollo, è uno standard che definisce le proprietà elettriche di un collegamento differenziale half-duplex (*). Non c'è nulla nelle specifiche su come i dati devono essere inviati su quel link, o di fatto su come viene usato il link.

Poiché tali ricetrasmettitori RS-485 non hanno alcun segnale / flag "linea occupata" automatica, né i microcontrollori che hanno driver RS-485 incorporati, né quelli che utilizzano un core UART collegato a un ricetrasmettitore esterno.

Tutta l'implementazione del controllo del flusso e del controllo della direzione è lasciata a qualunque protocollo si usi. Esistono diversi protocolli ben noti che utilizzano driver RS-485, come Modbus. Puoi anche implementare qualunque protocollo tu possa pensare.

Per aiutarti, ecco alcune idee per i protocolli:

1. Hai un protocollo tipo master-slave. In questo c'è un nodo master che coordina il bus e nodi slave che hanno ciascuno un identificatore univoco.

   Ai nodi slave non è consentito inviare alcun dato fino a quando il nodo master non invia specificamente i comandi a loro indirizzati. Una volta indirizzato uno slave, può quindi rispondere a qualsiasi comando in un modo predefinito, ad esempio un pacchetto di risposta a lunghezza fissa.

   In questo caso eviti i problemi di più dispositivi che vogliono parlare allo stesso tempo perché il master è lì per coordinare tutto.

2. È possibile utilizzare una qualche forma di pianificazione in base alla quale ogni dispositivo sul bus ha uno slot fisso in cui inviare i dati a qualsiasi altro dispositivo. Una volta esaurito il suo slot, deve interrompere l'invio e consentire al dispositivo successivo di parlare.

   La programmazione potrebbe essere effettuata dai dispositivi stessi senza coordinamento esterno. Il primo dispositivo parla, quindi invia un messaggio dicendo che è stato fatto. Il prossimo dispositivo (ad es. Quello con il prossimo ID superiore) saprebbe quindi che potrebbe andare. Nel caso in cui un dispositivo non stia rispondendo, potresti avere un po 'di timeout per cui ogni dispositivo successivo nella pianificazione sarebbe in grado di dire - beh, non ho sentito il dispositivo prima di me per un po', quindi deve essere il mio turno.

(*) Credo che definisca anche una versione full duplex utilizzando due collegamenti differenziali.

È molto simile alla comunicazione radio dell'esercito o della polizia. È richiesto un protocollo Lo schiavo principale è facile e buono per la maggior parte dei casi. Ma un'altra opzione è farlo come fanno gli umani:

1. Ascolta.
2. Se qualcuno parla, aspetta.
3. Se pensi che nessuno parli, puoi parlare.
4. Attendi conferma.
5. Se non viene ricevuta alcuna conferma, parlare di nuovo.
6. Se si desidera trasmettere, chiedere a tutte le stazioni di confermare l'ascolto.
7. Se vuoi parlare con qualcuno che non ti sente, chiedi se c'è qualcun altro che può inoltrare.

E così via. Potrebbe essere molto interessante da implementare. In bocca al lupo!

Ecco un paio di possibilità per risolvere il tuo dilemma.

1. Implementare un sistema di passaggio token. Quando un dispositivo ha il token, è consentito trasmettere per un periodo di tempo limitato. Passa quindi il token al dispositivo successivo. Devono essere previste disposizioni per nodi mancanti che non possono ricevere e passare il token.
2. Guarda la linea di ricezione. Se è occupato, genera un ritardo casuale e riprova. Il ritardo casuale aiuta a garantire che nessun nodo possa monopolizzare le finestre di trasmissione. Le collisioni possono ancora verificarsi ma una funzione di somma di controllo può determinare se il pacchetto ricevuto è intatto. Se non è intatto, il destinatario può richiedere una ritrasmissione.

Come può una scheda scoprire se la linea UART è libera di inviare dati,

la risposta generale è che senza un qualche tipo di protocollo, non può farlo in modo affidabile. di solito fai affidamento su un controller o un arbitro per vedere se una linea è occupata o meno. Uno semplice sarebbe un pin OD che tira giù una linea dell'indicatore prima della trasmissione e rilasciandola in seguito. Leggendo quella linea un trasmettitore può determinare se il bus è disponibile o meno.

un sistema meno affidabile ma più semplice è quello di integrare la tensione del bus (ad esempio tramite una rete ar / c).

e se rileva che il bus è occupato, attendere fino a quando il bus è libero e quindi inviare i propri dati?

l'approccio generale è di attendere un periodo di tempo casuale e riprovare.

Risolvo questo problema con i miei progetti come in questo modo:

invece usando 2 pin per le comunicazioni, io uso 3 pin. A breve distanza funziona. Il terzo pin è l'indicatore di linea occupata. Questo perno è estratto dal lato principale. Quando qualcuno (MCU o altro) vuole parlare:

• controlla questo stato del pin (INPUT).
• se il pin è ALTO, allora lo rende basso (OUTPUT)
• e parla.
• Quando il messaggio viene trasferito rilascia il pin (INPUT) (alta impedenza), quindi il pin diventa alto.
• Se il pin è basso, attende qualche istante, quindi torna a controllare il ciclo del pin.

Questa è un'implementazione della risposta di Gregory Kornblum.

È possibile utilizzare lo stack di protocollo BACnet open source per la comunicazione di microcontrollori su RS485 se non si desidera utilizzare modbus. In sostanza, passa semplicemente un token in giro che indica a ciascun dispositivo quando può inviare, in modo simile alla topologia token-ring e Ethernet. Ecco un paio di link per iniziare:

http://www.chipkin.com/bacnet-mstp-installation-rs485-and-cables/ http://bacnet.sourceforge.net/

Controllo del flusso del software

Sia il controllo del flusso software che hardware richiedono software per eseguire l'attività di handshaking. Ciò rende il termine controllo del flusso del software in qualche modo fuorviante. Ciò che si intende è che con il controllo del flusso hardware, nel cavo di comunicazione sono presenti linee aggiuntive che segnalano le condizioni di handshaking. Con il controllo del flusso software, noto anche con il nome di controllo del flusso XON-XOFF, i byte vengono inviati al mittente utilizzando le linee di comunicazione standard.

L'uso del controllo del flusso hardware implica che devono essere presenti più linee tra il mittente e il destinatario, portando a un cavo più spesso e più costoso. Pertanto, il controllo del flusso del software è una buona alternativa se non è necessario per ottenere le massime prestazioni nelle comunicazioni. Il controllo del flusso software utilizza il canale dati tra i due dispositivi, riducendo la larghezza di banda. La riduzione della larghezza di banda nella maggior parte dei casi, tuttavia, non è così sorprendente che è un motivo per non usarlo.

Nel set di caratteri ASCII sono stati predefiniti due byte da utilizzare con il controllo del flusso del software. Questi byte sono chiamati XOFF e XON, perché possono interrompere e riavviare la trasmissione. Il valore in byte di XOFF è 19, può essere simulato premendo Ctrl-S sulla tastiera. A XON è assegnato il valore 17 che equivale a Ctrl-Q.

L'uso del controllo del flusso del software è semplice. Se l'invio di caratteri deve essere posticipato, il carattere XOFF viene inviato sulla linea, per riavviare nuovamente la comunicazione viene utilizzato XON. L'invio del carattere XOFF interrompe la comunicazione solo nella direzione del dispositivo che ha emesso XOFF.

Questo metodo presenta alcuni svantaggi. Ne è già stato discusso uno: l'utilizzo dei byte sul canale di comunicazione occupa una certa larghezza di banda. Un altro motivo è più grave.

L'handshaking viene utilizzato principalmente per impedire un sovraccarico del buffer del ricevitore, il buffer in memoria utilizzato per memorizzare i byte ricevuti di recente. Se si verifica un sovraccarico, ciò influisce sul modo in cui vengono gestiti i nuovi caratteri sul canale di comunicazione. Nel peggiore dei casi in cui il software è stato progettato male, questi personaggi vengono eliminati senza controllarli. Se un tale personaggio è XOFF o XON, il flusso di comunicazione può essere gravemente danneggiato. Il mittente fornirà continuamente nuove informazioni in caso di smarrimento di XOFF o non invierà mai nuove informazioni in assenza di XON.

Questo vale anche per le linee di comunicazione in cui la qualità del segnale è scarsa. Cosa succede se il messaggio XOFF o XON non viene ricevuto chiaramente a causa del rumore sulla linea? È inoltre necessaria una precauzione speciale affinché le informazioni inviate non contengano i caratteri XON o XOFF come byte di informazioni.

Pertanto, la comunicazione seriale mediante il controllo del flusso software è accettabile solo quando le velocità di comunicazione non sono troppo elevate e la probabilità che si verifichino sovraccarichi del buffer o danni ai dati è minima.

CSMA ad alta velocità

Per l'alta velocità come il senso portante CSMA Ethernet , l'accesso multiplo, il rilevamento / evitamento delle collisioni, con timer di backoff casuali sono stati analizzati per thruput di probabilità stocastica per l'ottimizzazione.