Rete di arduini

Devo creare una rete di arduini in grado di comunicare tra di loro, ma vorrei evitare la classica topologia master - slave.
Da dove posso cominciare a documentarmi?

Qui si chiedeva uan cosa simile a quella a questa
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1225573352
se poi indichi quale tipologia vuoi creare e' piu' facile. Considerando che sostanzialmente anche quasi tutta internet lavora su un presupposto di server-client, forse vuoi fare una rete distribuita?
F

Un'idea potrebbe essere la TWI (nota anche con il nome di I2C) ma non è indicata per grandi distanze. Di solito si utilizza per far comunicare integrati che stanno sulla stessa scheda.

Il TWI prevede anche il multi-master e, per come è fatto, evita automaticamente che più master possano entrare in collisione.

ma una bella idea non sarebbe fare una bella libreria che crei un protocollo su rs485???

Non sarebbe male infatti sfruttare il 485.
Sennò una rete CAN...

superlol:
ma una bella idea non sarebbe fare una bella libreria che crei un protocollo su rs485???

Esiste già:
https://sites.google.com/site/jpmzometa/arduino-mbrt

E prevede anche che un pin venga preposto come abilitazione del trasmettitore nel caso si utilizzi una 485 half-duplex. Funziona, la sto usando...

Però non prevede la possibilità di un multi-master, deve esserci un master e più slave.

Sarebbe però da implementare una libreria semplice come la seriale normale ma che funzioni come la I2C in modo da collegare più dispositivi sulla stessa linea...

Se avete voglia di darmi una mano... io proverei anche a scriverla una libreria ma necessito di aiuto anche perchè non l'ho mai fatto...

scusa ma piu' che una libreria tu vorresti creare proprio un nuovo protocollo ?

Testato:
scusa ma piu' che una libreria tu vorresti creare proprio un nuovo protocollo ?

Più o meno, nel senso, basarsi su qualche standard di comunicazione che già esiste per semplicità, per gli integrati che possono servire etc.. e scrivere un protocollo che semplifichi all'osso il tutto...

Prova a dare un'occhiata al link che ti ho pubblicato. Più semplice di quello non c'è, ci sono due funzioni: una per la configurazione iniziale e l'altra da eseguire ogni ciclo per aggiornare i dati.

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

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?

Scusate, la discussione ha preso una via autonoma. Volevo fare una banale domanda:
l' rs485 è uno standard per quanto riguarda solo l'hardware? supponiamo che mi adatti ad una struttura master-slave, qual'è il metodo più veloce ed affidabile per implementarlo?

@luk:
non hai detto su che distanze devono comunicare.
Come ti hanno specificato, l'I2C è un ottimo standard che già gestisce di suo la problematica master/slave ma lavora su piccole distanze (cm).
Se devi andare oltre allora usa l'RS485, che copre distanze molto lunghe (fino al Km).

@tutti:
a me pare vogliate reinventare la ruota :wink:
Scusate, ma l'RS485 apre una normalissima connessione su 2 fili, una seriale bidirezionale. Bastano le comunissime librerie Serial o NewSoftSerial per poter dialogare. Il protocollo dovrà gestire al max solo il pin per attivare il chip su ricezione o trasmissione (slave o master).
Perché diventare grulli per fare ciò che già c'è? XD

leo72:
@luk:
non hai detto su che distanze devono comunicare.
Come ti hanno specificato, l'I2C è un ottimo standard che già gestisce di suo la problematica master/slave ma lavora su piccole distanze (cm).
Se devi andare oltre allora usa l'RS485, che copre distanze molto lunghe (fino al Km).

@tutti:
a me pare vogliate reinventare la ruota :wink:
Scusate, ma l'RS485 apre una normalissima connessione su 2 fili, una seriale bidirezionale. Bastano le comunissime librerie Serial o NewSoftSerial per poter dialogare. Il protocollo dovrà gestire al max solo il pin per attivare il chip su ricezione o trasmissione (slave o master).
Perché diventare grulli per fare ciò che già c'è? XD

rimane che domani provo a mettermi dietro e creare la libreria, nonostante non abbia tempo per provarla XD (e poi mi si è pure bruciato un arduino quindi non ho un convertitore usb-rs232 =( )

Mi servono alcune 100naia di metri quindi rs485.
Ma posso stabilire con quale arduino comunicare? cioè tramite un indirizzo o qualcosa del genere?
Cosa ne pensate dell'arduino con la ethernet?
Devo fare un lavoro per un piccolo albergo.

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.

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?

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.

superlol:
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

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.

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...