Buongiorno a tutti,
ho ripreso ultimamente un progetto che avevo accantonato un po' di tempo fa. Consisteva in un 328 standalone (slave) che attiva degli SSR leggendo i dati da un altro 328 standalone (master) tramite porta seriale (una HW e l'altro SoftwareSerial).
Il funzionamento è abbastanza semplice e non implementa protocolli di ricezione particolari, in pratica lo SLAVE riceve 5 byte ogni 100ms che possono essere 0 (spento) oppure 255 (acceso), ad ogni byte corrisponde uno stato di un pin del 328 al quale sono collegati gli SSR.
Avevo un problema di byte "null" in più che ho risolto grazie alle preziose intuizioni di Leo72.
Ieri insieme ad un amico abbiamo deciso di provarli con dei fari da 1KW ciascuno... E funziona.... Tuttavia dopo un paio d'ore di funzionamento in modalità "fissa", ho riattivato la seriale e si è ripresentato il problema dei byte "null" in più (ovvero invece di andare HIGH il pin 13 è andato HIGH il pin 11).
Ho notato che la cassetta con gli SSR (con all'interno il 328 che funge da slave) si è surriscaldata tanto a causa del carico.
Inoltre il cavo dati della seriale è costituito da un cavo elettrico 4 x 1,5mm (TX, RX, 5V, GND) non schermato e non intrecciato lungo circa 1 metro.
Penso che sia un problema di interferenza di campi magnetici o di surriscaldamento...
Voi che ne pensate? Ho deciso comunque di impiegare l'RS485 e di implementare un protocollo ad hoc con checksum e utilizzare un cavo schermato... ma prima di farlo volevo avere la certezza di risolvere il problema.
Grazie per l'attenzione! 
BB
Bartleboom:
Il funzionamento è abbastanza semplice e non implementa protocolli di ricezione particolari, in pratica lo SLAVE riceve 5 byte ogni 100ms che possono essere 0 (spento) oppure 255 (acceso), ad ogni byte corrisponde uno stato di un pin del 328 al quale sono collegati gli SSR.
Quando devi trasmettere più informazioni composte da più di un singolo byte è sempre necessario usare un protocollo che consente di suddividere correttamente i vari pacchetti dati tra loro.
Nel tuo caso escludiamo pure problemi legati al surriscaldamento del processore perché se realmente supera la massima temperatura di funzionamento i problemi sono ben altri che interpretare male dei dati in arrivo sulla seriale.
Le soluzioni possibili sono due, o implementi un semplice protocollo dati per separare le sequenze di cinque byte, il tuo problema deriva sicuramente da una errata interpretazione dell'ordine di ricezione, oppure trasmetti solo un byte per volta che contiene lo stato dei vari pin abbinandoli ai singoli bit, ovvero con un solo byte puoi trasportare l'informazione relativa a otto pin.
Ciao Astrobeed,
innanzitutto grazie per la risposta. Il punto è capire da cosa dipenda l'errata interpretazione dell'ordine dei byte... Nel senso che non è una cosa che fa sempre... lo fa solo dopo un prolungato utilizzo con "elevati" carichi... Questa errata interpretazione potrebbe essere dovuta alla mancata schermatura del cavo dati? Utilizzando l'RS485 la situazione dovrebbe migliorare penso.
In pratica mi dici che quando sono disponibili 5 byte ovvero Serial.available() >=5 i byte accodati sono giusti solo l'ordine potrebbe essere sbagliato? Quindi non ci sono byte in più come magari pensavo io... Cmq dovrò attendere per fare un altro test :~
Bartleboom:
In pratica mi dici che quando sono disponibili 5 byte ovvero Serial.available() >=5 i byte accodati sono giusti solo l'ordine potrebbe essere sbagliato? Quindi non ci sono byte in più come magari pensavo io... Cmq dovrò attendere per fare un altro test :~
Se non hai un minimo di protocollo per separare i pacchetti nulla ti può garantire che i 5 byte che hai nel buffer sono nel giusto ordine e/o fanno tutti parte dello stesso pacchetto.
Un modo semplice, se vuoi mantenere la struttura a 5 byte, per implementare il protocollo è aggiungere un byte che fa da preambolo del pacchetto, p.e. il carattere '@', che usi per verificare/sincronizzare la trasmissione dei dati, a seconda di come gestisci la seriale o prima attendi il carattere '@' e poi ricevi 5 byte, verificando che l'ultimo non sia una '@', oppure quando leggi il buffer della seriale devi verificare che il primo byte è una '@', che i caratteri in attesa sono sei e che l'ultimo carattere non sia una '@', se queste condizioni non sono tutte verificate butti via la lettura perché non è valida.
Però dato che nel tuo caso basta un solo byte per inviare tutte le informazioni che ti servono non capisco perché vuoi usare una trasmissione multibyte visto che è inutile.
Scusami Astrobeed ma se nulla mi garantisce che i byte sono in ordine... pure se il primo byte è '@' cosa mi garantisce che gli altri siano nell'ordine corretto?? Forse dovrei utilizzare un checksum che mi dia comfort sia sull'ordine dei byte che sulla loro effettiva corrispondenza.
Tipo uno o due byte finali che siano la somma dei vari prodotti del valore int del byte e della sua posizione. Nel senso che se ho una sequenza {0, 0, 255, 255, 255 } allora un controllo dovrebbe essere 10 + 20 + 3255 + 4255 + 5*255. Questo potrebbe essere valido che ne pensi?
Poi se i conti non tornano devo dire al Master di reinviare lo stesso pacchetto?
L'idea di non utilizzare i bit anzichè i byte è perchè in futuro voglio utilizzare i valori intermedi tra 0 e 255 per variare l'intensità di luce...
Bartleboom:
Scusami Astrobeed ma se nulla mi garantisce che i byte sono in ordine... pure se il primo byte è '@' cosa mi garantisce che gli altri siano nell'ordine corretto??
Io ti ho suggerito una soluzione minimale, poi sta a te scegliere cosa vuoi fare, il discorso protocollo trasmissione è molto complesso ed esistono molte possibili soluzioni, si spazia dalle cose semplicissime e minimali fino ad arrivare a cose molto complesse e, quasi, a prova d'errore.
Ciò che sta dicendo Astrobeed, quando parla di "ordine", a mio modesto parere, è a che a volte basta un qualsiasi "disturbo" che provochi un H o un L istantaneo, per trasformare la tua sequenza in una sequenza diversa, e NON che si inverta da solo l'ordine di invio della tua sequenza; un protocollo semplice ma ben fatto (p.es. una stringa con carattere di inizio, numero di caratteri totali fisso e carattere finale) per mette al ricevente di verificare se la stringa è corretta (basta controllare quanti caratteri ci sono tra il carattere iniziale e finale) e di metterla in atto, diversamente (p.es. uno 0 o un 1 in più) la ignora e ne richiede il re-invio; ovvio che se nel tuo circuito si comincia a verificare il bordello totale il ricevente non eseguirà più nulla ma almeno non farà operazioni a caso.
Sto lavorando ad un progetto di trasmissione dati via RF, con dei moduli a 433MHz, noti per il casino immane che immettono sulle linee in assenza di comunicazione; lo stesso produttore prevede un filtro che li azzera ma che abbatte anche di molto la sensibilità, in alternativa consiglia di creare un protocollo di trasmissione efficiente per evitare che tali sequenze di 0-1 indesiderate possano essere inn qualche modo eseguite dal circuito ricevente (devo pilotare una serie di relé normali). Ciao.