Go Down

Topic: Rete di arduini (Read 3 times) previous topic - next topic

leo72

Chi fa il master e chi lo slave devi deciderlo tramite codice.
Bisogna che memorizzi l'indirizzo dentro ai vari micro e poi dal master invii la richiesta allo slave, che deve rispondere occupando la linea.

Janos

Attenzione a chi vuol fare il multimaster: sulla 485 non è possibile perché se contemporaneamente 2 master decidessero di prendere possesso della linea ci possono essere problemi. Poiché il transceiver della 485 impone sia il livello logico alto che quello basso, se un master volesse scrivere 1 e l'altro 0 sulla linea ci sarebbe (idealmente) un corto-circuito. La twi, invece, impone solo il livello logico basso e quello alto è fatto da un pullup, quindi se due master vogliono scrivere contemporaneamente "vince" sempre quello che vuole scrivere lo 0 in quanto l'altro non impone l'1 ma lascerebbe la linea in modo che il pull-up tiri su la tensione.

Mio consiglio, poi fate come volete: il multi-master  è mooooooooooolto più complicato di quello che può semprare.

@leo72: cosa succede se contemporaneamente 2 arduino utilizzano la serial.write?

leo72

A livello elettrico non so, non so come lavora.
A livello logico succede che il secondo che decidesse di accedervi la troverebbe "occupata". Non è possibile per 2 trasmettitori impegnarla contemporaneamente.

niki77


se posso dire la mia basta una libreria con 4 funzioni:
init
send
read
available

si basano sulla seriale, in init si passano i valori di tx, rx, il pin necessario per le comunicazioni half duplex (commuta il max485 o equivalente da sender a recevier) e l'id di arduino.

poi la funzione send:
serial.write(idarduino);
serial.write(messaggio);
serial.write(255);

non serve molto, così si possono collegare fino a 254 arduini tutti insieme e non vi sono master o slave (sarebbero tutti master)

available equivale all'available della newsoftserial (ci basiamo su quella così è possibile la comunicazione su 3 pin qualsiasi) e read puoi mettere uno script tipo
Code: [Select]

void read() {
  char value[];
  while(myserial.available() > 0) {
    value += myserial.read();
  }
  // va messo un modo per togliere il primo carattere, tipo far shiftare l'array ed eliminare il byte di stop
  return value;
}


non sono un espertissimo ma non è fattibile?


Mi piace, e mi sembra un idea veloce ed interessante, come poi specificato successivamente ci sarebbe da gestire il controllo sulla linea, ovvero capire se la linea è già occupata in trasmissione da un altro nodo.
Non sò se questa cosa è implementata e come dal protocollo fisico.
Vi è una spiegazione scientifica a tutto.
La fede è solo quell'anello che si porta al dito dopo il matrimonio.

astroz78

Io, proprio in questo momento, sto ragionando e vorrei fare una "demo board" con 3/4 arduini connessi che si parlano tra di loro in 485...
...e vorrei fare un'architettura multi-master multi-slave...cioè non proprio...diciamo una sorta di!!!

E l'idea è quella di usare un sistema "simile" a quello usato nella rete token-ring!

Un nodo MASTER (uno solo...quindi tecnicamente è un'architettura mono-master)...dà un token al 1° slave che diventa "master" fin tanto che ne ha facoltà (ha qualcosa da dire o supera un tempo limite)...esso, finito di comunicare, restituisce il token al "master" che lo dà al 2° slave che diventa master...e così via! Così, ogni volta che un nodo diventa "master" può comunicare con chi gli pare e fare una comunicazione punto-punto o inviare un messaggio di broadcast (a tutti)...quando restituisce il token può stare solo in ascolto al massimo può "rispondere" se un "master" lo interpella chiedendogli qualcosa...

...chiaramente le complicazioni ci sono...vanno gestiti applicativamente molto bene i timeout...e i fault...se un nodo si blocca, se non restituisce il token, se non risponde x troppo tempo, etc...xkè il master in tal caso deve far morire quel token e immetterne in rete un altro...
OpenDomotica ...la domotica con Arduino - www.opendomotica.it

leo72

Secondo me una rete in cui molti dispositivi possono diventare master diventa problematica da gestire.
Essendo la comunicazione sostanzialmente seriale, quando un dispositivo diventa master e si blocca, blocca poi la connessione. Deve esistere un modo per sbloccare il tutto.

Si potrebbe prevedere un dispositivo "supermaster" che supervisiona la rete e con un filo extra gestisce i tempi dando un impulso ogni tot, impulso che deve essere intercettato da un interrupt in modo che sia indipendente dal normale codice dell'utente. Intercettato il segnale, l'applicativo deve liberare la rete. Se non lo fa, il supermaster invia un nuovo impulso ed il master, appena ricevuto, deve liberare a prescindere il bus (reset software?).
Solo a questo punto il supermaster invia l'ID del dispositivo che deve diventare master.

Cmq è tutto molto teorico e non so se realizzabile nella pratica.

astroz78

L'architettura che proponevo io è mono-master multi-slave...ma è multi-master multi-slave simulata...

Cioè il nodo master funge comunque da moderatore...il nodo slave diventa master nella stessa misura in cui in un mono-master multi-slave esso risponde al master...anche in quel caso se lo slave si incanta, si brucia, etc...e continua a impegnare il bus x ERRORE, il master non può fare niente per riprenderne il possesso...in quel caso c'è un fault e il nodo "problematico" và rimosso, ma questo, ripeto, accade comunque nella modalità mono-master multi-slave.

L'ipotesi del token che facevo io era quella di mandare in giro questo token a staffetta, dando diritto ad ognuno di parlare, ma non in risposta al master, bensì a chi gradisce...cioè diventa una connessione peer-to-peer per il tempo necessario...il master è comunque in ascolto essendo un bus condiviso e capisce quando il token gli viene restituito x poi darlo al successivo slave...

...certo se quei due parlano x mezzora il master non può far niente, ma nelle specifiche di questo mio protocollo ci deve essere un timeout di token...cioè tale token tu non puoi tenerlo x più di "x tempo"...se no diventa incandescente...e lo devi rimandare indietro...se  tu slave non rispetti i tempi, sei tu in errore...è alla pari di un nodo guasto...
OpenDomotica ...la domotica con Arduino - www.opendomotica.it

astroz78

Sto provando a scrivere un po' di codice...il problema poi è realizzarlo...cioè secondo me funziona come meccanismo, ma andarlo a realizzare e tararlo x bene xkè non ci siano effettivamente collisioni non sarà una passeggiata...
OpenDomotica ...la domotica con Arduino - www.opendomotica.it

leo72

Sì in questa maniera non c'è modo di risolvere il problema di un nodo "impazzito" che tiene occupato il bus.

astroz78

In nessuna maniera c'è modo di intervenire se un nodo impazzisce e occupa il bus abusivamente...
OpenDomotica ...la domotica con Arduino - www.opendomotica.it

leo72

C'è una maniera:
Quote
Se non lo fa, il supermaster invia un nuovo impulso ed il master, appena ricevuto, deve liberare a prescindere il bus (reset software?).


Se il normale sketch si pianta un interrupt dovrebbe funzionare comunque. Basta quindi un reset software e lo sblocchi.

veseo

Ciao,

io ho sviluppato un set di librerie che può fare al tuo caso. Di base sono ci sono due librerie:
- vNet, virtualizzazione del mezzo di comunicazione
- MaCaco, protocollo di comunicazione P2P

La prima libreria, vNet, è sostanzialmente una collezione di "driver" che permette di astrarre le applicazioni sovrastanti. In pratica utilizzando sempre gli stessi metodi è possibile comunicare attraverso diversi mezzi (per ora sono supportate le librerie Ethernet e Chibiduino). Inoltre sono fornite in automatico le funzionalità di routing e bridging.
Di conseguenza è possibile estendere il range di azione di dispositivi wireless utilizzando nodi ripetitori e legare reti diverse con dispositivi di bridge.
Il tutto è trasparente all'applicazione sovrastante, non richiede nessuna configurazione aggiuntiva. Per determinare gli instradamenti sono utilizzati indirizzi e subnetmask con principi del tutto simili al protocollo IP.

Le librerie alla base sono modificate per garantire il funzionamento in P2P completo, ad esempio la libreria Ethernet è stata modificata per utilizzare sempre e solo due socket (una in listen, l'altra in modalità client) e garantire accessi multipli.

La seconda libreria, MaCaCo, è sviluppata per lavorare sopra vNet ed è un protocollo in stile Modbus. Ha due grandi differenze con il Modbus, la prima è nel concetto di P2P e non master/slave; la seconda è nella possibilità di sottoscrivere i dati e ricevere le informazioni su eccezzione (cambio dati) e non in polling. Le modalità di polling e push dei dati sono comunque supportate.
Alla base di MaCaco c'è un array che funge da area di memoria condivisa con gli altri dispositivi.

A queste librerie si aggiunge un'ultima, Souliss, che usa le precedenti per creare una struttura di scambio adatta alle necessità di un sistema domotico.

Le librerie dovrebbero essere rilasciate per inizio Dicembre, attualmente vNet e MaCaco sono pronte e testate, ma ci sono ulteriori sviluppi che vorrei apportare (ad esempio il supporto per RFM22 in vNet).
Contestualmente vorrei anche realizzare una struttura analoga per Android, in modo da rendere un dispositivo Android un nodo della rete, in grado di leggere e scrivere dati su gli altri nodi (Arduino, o qualsiasi altra cosa in grado di far girare questo framework).

Per chi interessato ad utilizzarle (o a collaborare), posso fornire le librerie in anticipo alla loro pubblicazione.

Saluti,
Dario.
Souliss - Open-source Distributed Home Automation with Arduino and Android

http://www.souliss.net
Follow at @soulissteam

@veseotech

Testato

benvenuto veseo, grande ingresso.
grazie per la tua condivisione
- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

Janos

Benvenuto veseo. Sono curioso, come fai a rendere possibile il multi-master su una linea come la RS-485 dove i transceiver sono push-pull, ovvero si ha un'imposizione della tensione sia sul livello logico alto che su quello basso?

lesto

credo che la seriale funzionarebbe benissimo, basta solo creare un algoritmo per evitare la collisione (ovvero 2 o più host che scrivono in contemporanea)
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

Go Up