comunicazione multipla arduino (1 master, n slave)

Vorrei sviluppare una rete master / slave composta da:

• 1 master Arduino che legge i sensori e genera profili di rampe di velocità in base ai segnali del sensore e quindi invia tali rampe agli slave

• 3 (o più) slave Arduino che controllano la velocità dei servomotori 12V seguendo le rampe inviate dal master

Qual è un buon protocollo di comunicazione per raggiungere questo obiettivo? Seriale (SPI)? I2C? Qualcos'altro? Se è seriale, il nuovo Arduino Leonardo è una buona scelta? Quali problemi dovrei considerare nella scelta di un protocollo?

Sto immaginando qualcosa di simile:

Maestro:

void loop() {
    update_ramps()
    for(int i=0; i< num_slaves; i++) {
        send_to_all(i, ramps[i]);
    }
}

Slave 1:

const int id = 1;
int recived_id, recived_value;
void loop() {
    read_data();
    if(recived_id == id) { 
        do_motor_step(recived_value);
    }
}

E comunicazione seriale in cui RX / TX dal master viene inviato a tutti gli slave.

Sembra una soluzione ragionevole?

A quanto ho capito, vuoi inviare dati diversi a ciascuno degli slave, ma gli slave non devono restituire i dati.

I2C è un bus indirizzato, quindi se si assegna un indirizzo I2C diverso a ciascuno degli slave, saranno necessari solo due fili per inviare i dati. Se necessario, puoi richiedere anche i dati. Gli AVR di Arduino hanno un bus seriale compatibile I2C. E puoi estendere a più di 3 slave senza hardware aggiuntivo, fino a un massimo di 127.

Gli UART non hanno indirizzi, quindi avresti bisogno di 3 UART (che l'AVR non ha), o aggiungere una logica esterna per passare da una linea UART (che costa denaro). Ogni slave aggiuntivo comporta un costo aggiuntivo. Non consigliato.
modifica
Come dice Chris, puoi usare UART per creare un bus multidrop. E poi dovrai aggiungere l'indirizzamento, che fa funzionare il tuo UART un po 'come I2C, ma poi asincrono e senza hardware di corrispondenza degli indirizzi come ha I2C. Quindi non è ancora un vantaggio. fine della modifica

SPI utilizza anche linee condivise per i dati: un singolo MOSI e le linee MISO connesse. Per indirizzare singolarmente ogni slave è necessaria una linea SS (Slave Select) per slave. Quindi sono almeno 5 I / O: MOSI, SCK, 3$\times$SS e MISO se si desidera leggere anche i dati dagli slave. Ogni slave aggiuntivo aggiunge 1 pin I / O sul master.

Penso che l'I2C sia la soluzione migliore, che richiede il minor numero di fili. Il protocollo è un po 'più complesso di UART o SPI, ma poiché l'AVR ha l'hardware per esso, dovrebbe essere facile da usare.

Suppongo che per seriale intendi UART? Si noti che UART, SPI, I2C sono tutti protocolli seriali.

SPI o I2C andrebbero bene per questo in quanto entrambi usano l'architettura master / slave.
Senza terra, per 3 slave, SPI richiederebbe 6 pin (MOSI, MISO, CLK + 3 pin SS) e I2C solo due (SDA e SCK)
probabilmente sceglierei I2C, supponendo che non sia necessario un trasferimento di dati molto elevato frequenze (<400kHz)

Più slave aggiungi, più SPI è conveniente, poiché hai bisogno di un'altra SS (selezione slave) per ogni nuovo slave. Con I2C, questo non è un problema in quanto l'indirizzamento fa parte del protocollo, quindi sono ancora necessarie solo le 2 linee (più terra).

Per Arduino, ci dovrebbero essere un intero esercito di tutorial con librerie I2C / SPI e codice di esempio là fuori per entrambi i punti precedenti, il che dovrebbe rendere abbastanza semplice iniziare e funzionare.

Dovrebbero anche essere possibili schemi di segnalazione asincrona condivisi simili a RS485.

Se non stai utilizzando driver / ricevitori di linea (solo i pin ATMEGA nudi) devi rendere UART TX un input quando non è il tuo turno di parlare. Se si utilizzano i driver di linea, è necessario utilizzare un pin aggiuntivo per controllare l'abilitazione tristate sul driver di linea quando non è il tuo turno di parlare.

Inoltre, tieni presente che non puoi semplicemente tristare il trasmettitore quando l'ultimo byte viene accettato nel registro di trasmissione (il punto in cui potresti inviare un altro carattere), invece, devi assicurarti di mantenere il trasmettitore o il driver di linea abilitato fino a quando la parola è stata completamente spostato fuori.

Negli schemi in cui si trasmette e si riceve sullo stesso filo (o coppia differenziale) tenere conto del fatto che si sentiranno le proprie trasmissioni.

Nel caso speciale che si desidera connettere tramite UART , è possibile utilizzare UART RS485 MODBUS . Questo è un protocollo di comunicazione con indirizzi software, funzione, checksum.

PENSO : è più affidabile di I²C o SPI grazie a RS-485 e utilizza meno fili di SPI.

NOTA: può essere implementato come standard, con alcune librerie ma può essere costoso in quanto è necessario un modulo RS485 per ogni slave e uno per il master, MA è compatibile con una rete esistente. Ma puoi farlo meno costoso utilizzando componenti legacy e creando il tuo dispositivo. Il MAX 485 potrebbe essere il componente di base per realizzare un bus Hardware 485 o utilizzando un software RS485

La soluzione più semplice ai requisiti specifici sarebbe un trasmettitore RS-422 su una linea TX sul master (bus controller). Ciò consentirebbe il fan-out verso i ricevitori multipli (terminali remoti).

Tutti i RT ascolterebbero i messaggi trasmessi ma autenticheranno ed eseguiranno solo i comandi ad esso indirizzati tramite l'indirizzo RT.

Se fosse utilizzato un protocollo di bus simile al 1553 sarebbe facile da implementare.