Implementazione di un protocollo di comunicazione seriale

Question

Implementazione di un protocollo di comunicazione seriale

#1 da (1 voti)
#2 da (0 voti)

1

Ho bisogno di implementare un protocollo seriale per comunicare con un dispositivo utilizzando .NET (C #). Questa implementazione dovrebbe essere una libreria (.dll) da utilizzare in diversi progetti.

Ho la scheda tecnica che descrive il protocollo (baudrate, bit di stop, protocollo dei messaggi, comandi, ecc.) e so che ho bisogno di usare SerialPort di classe da System.IO.Ports namespace.

Ma ho qualche dubbio su come strutturare / organizzare il codice.

Ecco alcune domande:

Dovrei preoccuparmi della gestione dei thread o questo aspetto dovrebbe essere gestito da come viene utilizzata la libreria?
Posso gestire i dati ricevuti / inviati usando le stringhe o dovrei usare i byte?
I comandi e i contenuti fissi devono essere memorizzati utilizzando enums , constants o qualcos'altro?

Forse quelle domande potrebbero essere soggettive, ma mi piacerebbe avere un feedback da qualcuno con più esperienza di me.

Se qualcuno ha alcuni esempi, consigli, migliori pratiche, ecc. su questo argomento, sarò molto grato.

.net serialization

posta amp 28.09.2013 - 17:23

fonte

2 risposte

Leggi altre domande sui tag .net serialization

Come memorizzare in modo sicuro le credenziali dell'utente da un sito Web esterno Attività Architettura consumer / processore

score 1 · Answer 1

Praticamente tutte le tue scelte saranno guidate dal dispositivo stesso e dal traffico richiesto per utilizzare il dispositivo. Il tuo progetto sarà, necessariamente, guidato da ciò che è il dispositivo, da come funziona, da come vuoi che gli sviluppatori interagiscano con esso e da come gli utenti vogliono usare il dispositivo.

1) La questione della gestione dei thread è la stessa ovunque: usa un thread separato per impedire che altre cose si blocchino se questo sarà un problema. Ovviamente, questo non risolve il problema, ma modifica il problema dal blocco alla concorrenza / sincronizzazione. Ma questo è un problema diverso. A parità di altre condizioni, un thread separato per letture e scritture semplifica notevolmente il modo in cui si disgiunge l'IO da come si elabora l'IO.

2) Dipende interamente da ciò che il dispositivo invia / riceve, sia a livello basso che a livello di progettazione.

3) I comandi, le costanti fisse o altri aspetti potrebbero essere soggetti a modifiche? Se il dispositivo è un lavoro in corso, lo farà sicuramente. L'impianto di maggior successo che abbia mai fatto è stato quello di creare l'IO come livello di lettura / scrittura, collegato a un livello di interprete che in realtà legge la grammatica da una risorsa, completata da un livello API per l'utilizzo da parte delle applicazioni. Era per un dispositivo che era in sviluppo da molto tempo e il set di comandi cambiava di frequente; quel design ha permesso di usare lo stesso codice per più dispositivi. Che funzioni o meno per te dipende, ancora, dal dispositivo.

score 0 · Answer 2

Dipende. Se il dispositivo può inviare messaggi in modo asincrono, è necessario disporre di thread separati per l'invio e la ricezione; se parla solo quando si parla, si dovrebbe usare un singolo thread per semplicità.
Dipende dal tipo di informazioni che devi inviare e ricevere, ma in genere devi usare i byte per consentire i codici di controllo non ASCII.
Utilizza le costanti di tipo char unsigned.