marco.ben Inserito: 21 ottobre 2016 Segnala Share Inserito: 21 ottobre 2016 Buongiorno a tutti, abbiamo fatto progettare e realizzare un prototipo per un sistema embedded composto da un SBC (http://www.hce-engineering.it/a51-cortex-a5-536mhz/) e una scheda con un pò di I/O D/A e una porta RS 485. Il sistema operativo è un Linux Debian 8 per ARM. Abbiamo concordato che la porta RS 485 sarebbe stata utilizzata tramite http://libmodbus.org/ Sul primo prototipo che abbiamo provato però per poter far funzionare la comunicazione sulla 485 abbiamo dovuto usare la seguente procedura (ho dovuto modificare e ricompilare libmodbus): scrivere il carattere '1' in /sys/class/gpio/pioD16/value attendere un tempo X trasmettere sulla porta seriale scrivere il carattere '0' in /sys/class/gpio/pioD16/value attendere un tempo X attendere risposta e leggere dalla porta seriale Per abilitare la porta gpio nel sistema: echo 112 > /sys/class/gpio/export echo out > /sys/class/gpio/pioD16/direction Questa soluzione non permette di avere un comportamento deterministico del sistema. Variando il tempo di attesa X si ottengono diverse percentuali di errori sulla risposta. Abbiamo individuato in 1 ms per X l'impostazione che dà la minor percentuale di errori, che è comunque dell'1% Il fornitore ci dice che secondo loro è tutto corretto perché tramite minicom - abilitando il controllo di flusso - funziona nel modo corretto. La mia domanda per gli esperti del forum è: il modo descritto sopra è l'unico possibile per usare libmodbus con la RS 485? Come posso avere una comunicazione esente da errori in questa modalità? Il fornitore potrebbe sistemare questa situazione intervenendo sul firmware o sulla compilazione del kernel linux che ci consegna? Link al commento Condividi su altri siti More sharing options...
Livio Orsini Inserita: 22 ottobre 2016 Segnala Share Inserita: 22 ottobre 2016 Teoricamente gli errori di comunicazione possono sempre esserci, proprio per questo motivo si fanno controlli tipo checksum sul dato trasmesso. Quello che, dal mio punto di vista, è assurdo è che si ammetta una percentuale fissa di errori di comunicazione. L'errore deve essere un'eccezione non la regola. Ci mancherebbe altro. Un'apparato come quello che hai descritto non è degno nemmeno di amatore di media capacità, figuriamoci se si tratta di un'applicazione professionale. Link al commento Condividi su altri siti More sharing options...
Messaggi consigliati
Crea un account o accedi per commentare
Devi essere un utente per poter lasciare un commento
Crea un account
Registrati per un nuovo account nella nostra comunità. è facile!
Registra un nuovo accountAccedi
Hai già un account? Accedi qui.
Accedi ora