seriale con due arduini e PJON...

ciao a tutti.
Navigando tra i vari topic, non sono riuscito a trovare nulla che faccia al mio caso.
Mi spiego:ho necessità di far comunicare due arduini a distanza di 10mt uno dall'altro, uno gestisce un display ed un encoder mentre l'altro dei relè,ventilatori ed acquisisce dati da sei sonde di temperatura.
Il sistema dovrebbe essere multimaster, o qualcosa del genere, nel senso che sia uno che l'altro inviano e ricevono dati; lato display riceve i dati della temperatura ed invia i comandi a ventole e relè, lato "attuatori" rivece i dati per accendere/spegnere relè e ventole ed invia i dati della temperatura.
Purtroppo ho trovato tantissima roba ma nulla che faccia per me.
Chi può aiutarmi ed indirizzarmi su una soluzione ottimale??
Non sono molto ferrato sulle seriali.
Lato attuatori le sonde di temperatura userò delle DS18b20 in one wire.
Avevo pensato anche ad una connessione bluetooth, o utilizzando i nodemcu, ma non sono molto bravo su questo campo....valuterei anche questa strada...
grazie a chiunque voglia aiutarmi..

Salve,
Non ho ben compreso dove é il suo problema. É nel fare il programma in generale? É nel gestire la Seriale? O é nel far passare un comando tra due Arduino distanti 10 metri?

Io ti direi di spezzare la cosa in varii tronconi. Comincia col far andare tutto in un arduino solo. Poi prova la trasmissione tra due macchine, ma senza scopo definito,solo accendere e spegnere lucine a comando. Vedrai che poi ti verrà naturale proseguire

ciao manolomao,

direi che c’è un po’ di confusione…o meglio…se non è chiaro a te cosa e come vuoi realizzare il tutto difficilmente riuscirai ad avere risposte “decenti”.
secondo me dovresti:

  • capire/decidere cosa fa ogni arduino
  • capire/decidere come realizzare la connessione tra i due (tramite fili cablati, rete, etere) perchè in base al modo si possono attuare diverse soluzioni.

Silente, le idee su cosa devono fare i due arduini le ho ben chiare, su come colegarli quasi, il come gestire la comunicazione nessuna...
Orso 2001, il tuo approcio mi piace molto, diciamo che quello che devono fare i due arduini non è un problema, lo so fare...e fin li è ok...poi sono a distanza di 10 metri e qui iniziano i problemi (non ho mai masticato di comunicazioni seriali)...
Quindi pensavo di collegare i due arduini vicini, creando su entrambi una seriale virtuale (ho visto la libreria) in modo da tenere libera la seriale per il debug; il problema sorge ora: come li faccio parlare?
Come faccio a non creare conflitti tra chi chiama e chi risponde (visto che entrambi lo devono fare??)..
Sono davvero ignorante in materia di comunicazione...
Grazie

Per raggiungere quella distanza potresti utilizzare la comunicazione RS485 e per far parlare i due Arduino puoi guardare la libreria PJON che ha un sacco di configurazioni ed esempi da cui partire.
Gli adattatori RS485 ne trovi molti su vari site e ti semplificano la vita

Ok, via seriale software, per cominciare tieni i due arduino vicini tra loro, incrocia rx con tx, magari incrementa una resistenza da 1k, per visitare corti
Inizializzi la libreria, e nella loop se hai serial.available copi sulla software, e vice versa. Poi apri due serial monitor sui due arduino e vedrai che quello che scrivi in uno te lo ritrovi nell'altro.
Quando sei arrivato qui si va avanti, non è difficile

ciao...
@fabpoli...un giorno o l'altro devo decidermi a dare un'occhiata a questa PJON... :smiley:

per quanto riguarda come gestire lo scambio dati...una RS485 potrebbe essere una soluzione buona se decidi di cablare.
Se opti per questa opzione, indipendentemente dal protocollo che userai, potrei suggerire di instaurare uno scambio tra Master/Slave...dove se il master vuole sapere qualche cosa interroga direttamente o scrive direttamente lo slave...se lo slave vuole comunicare qualche cosa al master imposta ad HIGH un PIN, che sarà cablato al master, il master si accorge che lo slave ha qualche cosa da passargli e lo interroga.
così riduci al minimo il lavoro della seriale...comunichi solo se c'è qualche cosa da scambiare e non in continuazione...e soprattutto gestisci le precedenze sulla comunicazione.
per quanto riguarda i protocolli...io mi sento un po' più ferrato sul ModBus RTU...

Mi sono otto lo sfizio di fare una ricerca.
Comunicazione seria la 2 (oppure due) arduino
Si trova tutto, con dovizia di particolari

Mi sono otto lo sfizio di fare una ricerca.
Comunicazione seria la 2 (oppure due) arduino
Si trova tutto, con dovizia di particolari

bhe si di esempi ne trovi una valangata...per ogni tipo di protocollo e modo usato per connettere 2 o più arduino...

Il problema maggiore lo vedo nel non sapere (noi) esattamente come vengono gestiti i tempi (si parla di sonde 1wire ecc), soprattutto nell'ipotesi di software serial. E qualche problema potrebbe nascere anche dalle alimentazioni. Telealimentazione? Masse in comune? Isolamento ottico tra le due "stazioni"?

io mi sono fatto idea: che lui voglia una postazione di comando in salotto o in altro posto comodo per comandare alcune cose in cantina o simili.
da mia esperienza queste cose funzionano meglio se si mette "l'intelligenza" il più possibile tutta da un lato:
magari da quello "senza" il display. quindi torno a proporre: fai funzionare quello che deve funzionare (ipotizzo alcuni termostati) senza la comunicazione, poi si aggiunge la comunicazione che preferisci, io voto per software serial, ma c'è margine

Ciao tutti, onde fugare ogni dubbio vedo di charire meglio il progetto...
Devo comandare a distanza di circa 10 mt sei carichi i quali devono essere raffreddati con delle ventole al raggiungimento di una determinata temperatura ed azionare altri due relè con tempistiche di tre secondi uno dall'altro (questa parte la chiamerò per convenzione "l'intelligenza"); dall'altro lato (e lo chiamerò "telecomando") un display LCD 20*4 visualizzerà, in maniera alternata, lo stato dei relè e la temperatura di ogni singolo carico. L'attivazione o disattivazione dei relè la eseguo (dal "telecomando") con un encoder rotativo all'interno di un menù.
Questo è il quadro del progetto.
Ora, dal lato "intelligenza" userò un arduino uno (o mini) con dei moduli d'espansione I2C (6 relè + 6 ventole + altri 2relè + onewire + seriale....), non volendo usare il mega; lo stesso dal lato "telecomando" userò arduino uno (o mini) con un display I2C.
L'alimentazione sarà dal lato "intelligenza" e comunque dal punto di vista hardware non mi preoccupo, ho buone conoscenze di elettronica...; il mio problema è dal punto di vista software, come farli parlare...
Avevo pensato di fare tutto senza fili, usando una batteria al litio ricaricabile nel telecomando (dosando la retroilluminazione del display), ma non ho dimistichezza con i sistemi wireless (non ho mai affrontato un progetto così).
Quindi la mia seconda idea era di farli parlare, i due sistemi, via seriale (anche qui sarebbe la prima volta che affronto un problema del genere , ma mi sembra più fattibile)...
La comunicazione deve essere (credo) multimaster, nel senso che entrambi mandano e ricevono dati (mentre se non ho capito male, nella comunicazione master-slave il master manda dati e lo slave riceve ed esegue...)
Ecco il perchè del mio post, chiedevo un aiuto per capire come muovermi nel "mondo" della comunicazione seriale tra due arduini...
Un ultima cosa che chiedo a Fabpolli...molto interessante la PJON, ho letto ieri velocemente, nel w-end vedo di studiarmela meglio, ma è possibile farla con una seriale tipo RS422 al posto della RS485??
Ti spiego il perchè: la 422 mi sembra immune dai disturbi rispetto alla 485 (e nell'ambiente dove lavorerà il sistema ci sono molti disturbi) ed inoltre ho facilità di reperirla in casa :stuck_out_tongue:
Grazie a tutti che mi aiutate...

manolomao:
...
La comunicazione deve essere (credo) multimaster, nel senso che entrambi mandano e ricevono dati (mentre se non ho capito male, nella comunicazione master-slave il master manda dati e lo slave riceve ed esegue...)

NO, una configurazione master/slave vuole solo che solo il master possa prendere l'iniziativa e che gli slave rispondano. In pratica è il master che decide con chi parlare, dopo di che il colloquio è comunque bidirezionale.

In un architettura multimaster tutti possono prendere l'iniziativa di parlare senza che ci sia uno a ... "dirigere l'orchestra". Tale architettura, per ovvie ragioni, è molto più complessa da implementare.

manolomao:
...
Ti spiego il perchè: la 422 mi sembra immune dai disturbi rispetto alla 485

NO, forse ti stai confondendo con la RS232.
La RS485 è in realtà un evoluzione della RS422. Mentre la RS422 è essenzialmente una Single ended multi-drop, in cui puoi avere 1 trasmettitore e sino a 10 ricevitori, la RS485 è una Multi-drop in cui puoi avere sino a 32 trasmettitori e ricevitori. Distanze, velocità ed immunità al rumore ... sono praticamnete uguali.

La configurazione adatta alla tua eseginza credo sia proprio una master/slave con connessioni in RS485 ... e la PJON ti può aiutare moltissimo eliminandoti tutta la gravosità della gestione del colloquio.

Guglielmo

Grazie Guglielmo, quindi se ho capito bene...configurazione master/slave, master posso considerare il "telecomando" slave " intelligenza", al master faccio "chiedere" i dati che lo slave deve dare (dati temperatura),al master faccio inviare i dati che lo slave deve attuare...giusto o sbaglio??
Grazie per il chiarimento della differenza tra RS422 e RS485, in realtà ho dei MAX488 a disposizione e leggendo il data sheet mi sembra che questo integrato sia utilizzabile sia per RS422 che per RS485...o mi sbaglio??

Tranquillo. devi tirar su solo un semplice protocollo di comunicazione in base alle tue esigenze... Tipico step quando si iniziano ad avvicinare i primi progetti che coinvolgono più cervelli.

manolomao:
Grazie Guglielmo, quindi se ho capito bene...configurazione master/slave, master posso considerare il "telecomando" slave " intelligenza", al master faccio "chiedere" i dati che lo slave deve dare (dati temperatura),al master faccio inviare i dati che lo slave deve attuare...giusto o sbaglio??

Esatto, il master inizia il colloquio e, in detto colloquio, può sia inviare odini ad uno slave, che chiedere allo slave l'invio di dati.

E' la tecnica del "polling" ... il master fa il "poll" dei vari slave ed, a turno, gli invia i comandi e recupera le infomazioni.

Guglielmo

miky_police:
Tranquillo. devi tirar su solo un semplice protocollo di comunicazione in base alle tue esigenze... Tipico step quando si iniziano ad avvicinare i primi progetti che coinvolgono più cervelli.

Fortunatamente lui NON deve mettere in piedi nessun protocollo, ci pensa già la libreria PJON che gli è stata, da vari di noi, già suggerita.

Guglielmo

manolomao:
Grazie per il chiarimento della differenza tra RS422 e RS485, in realtà ho dei MAX488 a disposizione e leggendo il data sheet mi sembra che questo integrato sia utilizzabile sia per RS422 che per RS485...o mi sbaglio??

Si, come ben descritto nel datasheet del MAX488, esso può fare da Transceiver RS-485/RS-422.

In particolare, il 488 richiede due coppie twistate e permette di lavorare in Full-Duplex ...


Guglielmo

Senza usare librerie o altro io consiglierei:
1)Usi un sistema di comunicazione senza fili (rete locale, radio, bluetooth...) scopo:evitare strepiti da parte di mogli isteriche intente a pulire case nelle quali girano fili
2)Faccia si che tra Arduino e il mezzo di comunicazione ci sia una comunicazione seriale. Scopo: facile e comoda
3) Prima di fare il progetto per intero ne provi ciascuna parte separatamente (sensori, attuatori, comunicazione, ricezione) sfruttando un pc. Scopo: facilità di riconoscere e correggere gli errori
4) Una volta testate tutte le parti faccia si che si possano parlare tra di loro senza grandi modifiche del codice. Scopo:gli errori risolti risolti restano.
5) Faccia si che sia SEMPRE e SOLO uno dei due Arduino a fare domande e che l'altro non faccia altro che rispondere ad esse. Scopo: si evitano un po di problemi
6) Costruisca un protocollo con inizio e terminatore per rendere valida ogni informazione. Scopo: la cosa rende immune da molti disturbi. Scopo secondario (perché non usare una libreria?): più divertente ed istruttivo
7) Trasmetta caratteri normali e i numeri in cifre, anche se aumentano i bytes trasmessi si riducono possibilità, quindi disturbi