next topic »

[Reply #30 on:]

E ritorno anche al mio dubbio...

50 ms sono una eternità, il tempo medio per la transazione master/slave è 4-5 ms, il timeout mediamente si imposta tra 10-20 ms ed è una condizione di errore

certo, con 4-5 ms i conti tornano... ho però qualche dubbio. In questo tempo, il master deve inviare la richiesta e lo slave deve rispondere; pensi che sia fattibile con Arduino? Appena ho un po' di tempo ci provo.

E poi non è che il master debba terminare tutto il ciclo di interrogazioni quando deve spedire un comando.

questo mi piace  In pratica appena riceve una variazione da uno slave esegue la logica di controllo per verificare se deve comandare qualcosa ed invia i comandi necessari.

Il controllo degli slave sarà fatto nei momenti di idle del sistema.

questo invece non lo capisco. Mi pare, come dice anche astrobeed, che il sistema interroghi sempre gli slaves, altrimenti come fa a sapere se c'e' stata una variazione o meno. E comunque immagino che la logica di controllo venga eseguita in un tempo brevissimo; credo che il master passi la maggior parte del tempo ad interrogare gli slaves.

Ciao.

[Reply #31 on:]

Allora dopo tutto questo parlare peché non ci uniamo in u n unico gruppo e iniziamo
a mettere le basi per un "simple protocol" da usare per un Arduino Master che
collegato con due slave esegue un controllo dello stato pin dei due slave in scansione e in continuazione e appena riceve uno stato High dei pin input 2,3,4 di ogni slave esegue un digitalWrite High dei suoi Pin Output 2,3,4  5,6,7  8,9,10


Slave1 pin2,3,4 ---- segue  Master pin2,3,4
Slave2 pin2,3,4 ---- segue Master pin5,6,7
Slave3 pin2,3,4 ---- segue Master pin8,9,10

Da dove iniziamo??

[Reply #32 on:]

@vittorio68:
la mia affermazione sul controllo degli slave nei periodi di idle era fatta relativamente ad un master che dovesse anche interagire con l'utente, lo avevo precisato che appunto in modalità "interattiva" dedicasse la sua attenzione al "padrone" piuttosto che alle sue periferiche.
Ovviamente questo dipende da come fai la lettura degli slave, se usi uno scheduler tipo il mio leOS e l'interrogazione la fai in background, puoi sempre ricevere dati senza fermare il loop principale del codice.

[Reply #33 on:]

Allora dopo tutto questo parlare peché non ci uniamo in u n unico gruppo e iniziamo
a mettere le basi per un "simple protocol" da usare per un Arduino Master che
collegato con due slave esegue un controllo dello stato pin dei due slave in scansione e in continuazione e appena riceve uno stato High dei pin input 2,3,4 di ogni slave esegue un digitalWrite High dei suoi Pin Output 2,3,4  5,6,7  8,9,10


Slave1 pin2,3,4 ---- segue  Master pin2,3,4
Slave2 pin2,3,4 ---- segue Master pin5,6,7
Slave3 pin2,3,4 ---- segue Master pin8,9,10

Da dove iniziamo??

Pietro...l'idea mi piace...scrivere qualcosa noi da mettere a disposizione di tutti (visto che si trova davvero poco) quello da cui partire sarebbe inventarci il protocollo

rispondendo a Vittorio...
la mia idea di avere un codice in esecuzione all'interno degli slave è solo per i comandi delle luci e per il sensore gas sostanzialmente...ciò per avere un'affidabilità maggiore e un tempo di risposta immediato, la sirena del sensore gas in questo caso è allocata all'interno dello slave in questione...nel caso di una fuga di gas..lo slave dovrebbe rilevare il gas, inviare il comando di accensione della sirena al master e il master dovrebbe restituirlo allo slave dicendo di attivare la sirena...mettiamo caso ci fosse un errore di comunicazione o qualsiasi altro problema per cui il segnale non riesce ad arrivare al master...la sirena non si attiva...è solo una questione di affidabilità, praticamente lo slave mi esegue il codice inviando solo un feedback al master alla prima interrogazione...comunque se vogliamo fare un codice insieme sono a disposizione...cominciamo a buttare giù qualcosa...

[Reply #34 on:]

Dovreste creare una serie di livelli di sicurezza. Se l'operazione è banale, come ad esempio accendere un faretto quando inizia a fare buio, potete usare un livello basso, spedendo al master la lettura del sensore ed attendendo che il master spedisca il comando.
Ma se il livello di sicurezza è alto, lo slave è abilitato ad invertire la sequenza: operare in proprio attivando una certa cosa ed informando il master del problema.

[Reply #35 on:]

Allora dopo tutto questo parlare peché non ci uniamo in u n unico gruppo e iniziamo
a mettere le basi per un "simple protocol"

Qualche tempo fa avevo fatto qualche prova con un paio di Arduino Mega (scelti sopratutto per la maggiore capacità di memoria...) ed un paio di SN75716BP per creare una RS485. Appena ho un po' di tempo rimetto insieme gli sketch di prova che avevo fatto e comincio a postarli.

Ciao.
Vittorio.

[Reply #36 on:]

Dovreste creare una serie di livelli di sicurezza. Se l'operazione è banale, come ad esempio accendere un faretto quando inizia a fare buio, potete usare un livello basso, spedendo al master la lettura del sensore ed attendendo che il master spedisca il comando.
Ma se il livello di sicurezza è alto, lo slave è abilitato ad invertire la sequenza: operare in proprio attivando una certa cosa ed informando il master del problema.

Cosa consigli???

[Reply #37 on:]

Una semplice tabella con i livelli di sicurezza.
Ad ogni operazione che deve eseguire lo slave assegnate un livello. Se il livello è base, fate la solita trafila: spedire al master il dato, attendere la decisione del master. Questo va bene, ad esempio, per la lettura di una fotoresistenza.
Se il livello è superiore (allarme fuga gas), potete decidere se:
1) inviare il dato al master e mettere un timeout alla sua risposta, per evitare che una caduta dello stesso o un problema sulla linea impedisca allo slave di prendere una decisione. Oppure
2) attivare una contromisura (es.: sirena) in maniera indipendente ed informare il master dell'accaduto.

Il master potrà avvisare l'utente con un sms/email/led, a seconda di come è stato programmato.

[Reply #38 on:]

Visti i pochi ritagli di tempo da parte mia per iniziare a stilare questa famosa tabella di protocollo bisogna pur cominciare da qualche base ...

Ora vista la mia scarsa propensione a programmare un protocollo mi affido a persone più competenti e più afferrate nel campo e soprattutto mi affido all'unione delle menti geniali allo scopo di iniziare a lavorare su qualcosa....
Vi prego buttate giù un qualcosa che sia anche solo un'esempio basilare per iniziare a far camminare i neuroni...Grazie e comunque senza obblighi...

[Reply #39 on:]

Ragazzi, vi prego di scusare la mia assenza a causa di svariati impegni lavorativi....dunque creiamo una base di partenza...e partiamo dal master....mettendo per ipotesi che noi vogliamo creare un protocollo semplice utilizziamo 6 byte... e quindi

Code:

byte data [6]
// il primo byte è il classico NULL, inviato per primo come meno significativo 0x00
byte Address; // il secondo byte è quello di indirizzo del dispositivo che invia
byte SlaveAddress; // il terzo byte è quello di indirizzo del dispositivo che riceve
byte Data; // il quarto byte richiama la funzione da eseguire...nel caso di invio di lettura digitale entrambi i byte di data riportanto il valore di 10 bit
byte Data2; // il quinto byte specifica cosa eseguire
byte Checksum; // l'ultimo byte invia un feedback al master indicando che l'operazione è stato eseguita

correggetemi se scrivo castronerie...(Leo72 aiutami tu che vedo che sei il più esperto qui...)
poi....

Code:

#define Address  xx; //impostiamo l'indirizzo del dispositivo
const int PinRS485Enable = 02; //impostiamo l'abilitazione del trasferimento dati sul pin 2 ( i pin 0 e 1 sono utilizzati per la comunciazione seriale)
const int ErrorComLed = 03; //reputo molto utile l'utilizzo di un led che ci segnali eventuali errori di comunicazione

poi sul void setup() scriveremo:

Code:

pinMode(PinRS485Enable, OUTPUT); // settiamo il pin di controllo della trasmissione come output
pinMode(ErrorComLed, OUTPUT); // settiamo il pin del led di errore come output

[Reply #40 on:]

Come inizio non è male...anzi almeno sappiamo da dove partire ma adesso viene il bello...

Come costruire i byte da te citati...o meglio come costruire la tabellina di riferimento per le funzioni...aspettiamo...
 

byte data [6]
// il primo byte è il classico NULL, inviato per primo come meno significativo 0x00
byte Address; // il secondo byte è quello di indirizzo del dispositivo che invia
byte SlaveAddress; // il terzo byte è quello di indirizzo del dispositivo che riceve
byte Data; // il quarto byte richiama la funzione da eseguire...nel caso di invio di lettura digitale entrambi i byte di data riportanto il valore di 10 bit
byte Data2; // il quinto byte specifica cosa eseguire
byte Checksum; // l'ultimo byte invia un feedback al master indicando che l'operazione è stato eseguita

[Reply #41 on:]

Ok dai, quindi siccome vogliamo fare un SimpleProtocol propongo di fare questa tabellina in un file.h da includere nel sorgente, il problema reale che ho riscontrato nei sorgenti che si trovano in giro nel web è appunto il non capire a che serve quella determinata stringa che magari sta solamente dichiarando cosa deve fare quel comando....quindi propongo di semplificare al massimo e lasciare all'utente che va a modificare il codice sorgente soltanto decidere cosa eseguire su quel pin ecc....che ne dici?...un sorta di brutta copia del Wire...

[Reply #42 on:]

dimenticavo....ovviamente nel void setup()

Code:

Serial.begin(9600); //inizializzo la porta seriale e la imposto a 9600 baud...

[Reply #43 on:]

Concordo pienamente nel compilare un file.h per i comandi a livello "open" per lasciare la possibilità a chiunque di personalizzare anche il sorgente...
Per la porta seriale pensavo chiaramente di poter usare almeno per il Master la classe SoftwareSerial per il bus485 e quindi usa re una porta virtuale e lasciare chiaramente la Com sui pin 0 e 1 per la comunicazione con PC e monitoraggio delle serialPrint ... che pensi si può fare ??

E intanto andiamo avanti in attesa che si introduca sempre più gente...+ne siamo e meglio è ....

[Reply #44 on:]

Ottima idea quella della SoftwareSerial... quindi procediamo in questo senso...abbiamo bisogno di altra gente che si aggreghi però...qui di lavoro ce n'è....ma il mio tempo è molto limitato purtroppo...quindi quando posso butto giù qualche idea....fattevi avanti anche voi...con pezzi di codice...a pezzo a pezzo buttiamo giù qualcosa di concreto...