Protocollo

[daniele1996]

si, comprendo in pieno quello che vuoi dire... quello che mi turba è un eventuale conflitto nella trasmissione...

perché la comunicazione avverrà cosi:

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

[WALTERmwp]

Beh, questo è un accenno a livello di architettura; ancora non dice niente.
Ma già così puoi fare le tue considerazioni.
Io ti proporrei di ragionare prima su uno scambio di messaggi (per fare una cosa sola, o, se preferisci per chieder una cosa sola) tra il Master ed uno Slave (lo Slave 0), eliminando tutti gli altri.
Componi un minimo di messaggio che il Master invia (come e cosa gli chiede) allo Slave e stabilisci la risposta (come e cosa gli risponde) che lo Slave deve inviare al Master: insomma, un passo alla volte.
Poi fai la stessa cosa inserendo anche lo Slave 1: ti dovresti già rendere conto, da solo, dove potresti intervenire per adattare/modificare la "struttura" del messaggio che parte dal Master.
Fai le tue considerazioni, in merito al contenuto dei messaggi, concentrandoti sulla comunicazione tra il Master ed un solo Slave; una volta che ti sei chiarito le idee puoi "estendere" la tua rete a due Slave (non occorre andare oltre per rendersi conto delle implicazioni).
Considera anche l'interfacciamento elettronico (come ho scritto nel Post precedente).
Queste righe sono solo l'indicazione per provare ad impostare qualcosa di concreto, quindi niente di più.
E non è detto che si possa approcciare la questione in altri modi (che comunque ci sono !).

Saluti

[daniele1996]

Benissimo, sono arrivato ad una bozza di codice, ho tenuto gia conto quello che hai detto tu, esistono i "MAX485" o i "MAX232", lo scambio di dati avviene a 8 bit (char) alla volta ognuna di quei membri che ho messo nella lista è composta da una variabile. Scrivo lo pseudo codice che ho ideato (serve solo per l'indirizzamento e l'inizializzazione)

Codice: Seleziona tutto

Pacchetto:
- indirizzo (uint8_t)
- richiesta/comando (uint8_t)
- informazione (uint8_t)
- bit parità (uint8_t)
Fine pacchetto

MASTER:
    {inizio invio identificazione}
   - invia:
           indirizzo (255) => {11111111}
           richiesta (255) => {11111111}
           informazioni (0) => {00000000}
           Bit parità => 1
   {fine invio identificazione}
   {inizio salvataggio} (salva gli indirizzi)
      -Riceve da "slave X"
      -salva in un Array
   {fine salvataggio}
SLAVE:
  {inizio invio identificativo}
    -Riceve il pacchetto
    - indirizzo (dato dai dip-switch)
    - comando (255)
    - informazioni (X) (dato dai dip-switch)
    - parità (X) => dipende dai campi precedenti
{fine invio identificativo}


fairyvilje non ho rispettato le regole di "ADA", così è chiaro piu o meno quello che ho scritto?

[fairyvilje]

I riferimenti riportati da fairyvilje nel Post [12], per quanto significativi, in tal caso potrebbero portare l'OP ad "allontanarsi" dalle sue necessità, prim'ancora che dal suo obiettivo.
In altre parole: c'è la possibilità che ci si metta a leggere del materiale senza coglierne il significato perché mancano a priori delle conoscenze.

Hai ragione. Non sono un buon didatta e le scelte che faccio in fase di progettazione sono dettate dal fatto di essere interessato principalmente all'aspetto informatico del problema (visto quello che studio non mi sorpende ). Un approccio che per me va bene, ma che qualcun altro potrebbe trovare oltremodo pesante.

[daniele1996]

ho pensato di mettere due pin in piu a disposizione per la trasmissione, servono per indicare quando un dispositivo sta trasmettendo e quando la centrale sta inviando, verificando questi due immagino non ci possono essere conflitti nella rete...

[fairyvilje]

Vedo la base del tuo protocollo molto fragile.

Codice: Seleziona tutto

Pacchetto:
- indirizzo (uint8_t)
- richiesta/comando (uint8_t)
- informazione (uint8_t)
- bit parità (uint8_t)
Fine pacchetto


L'indirizzo ci sta, a patto di prevedere un sistema per etichettare in precedenza i dispositivi.
Il bit di parità non ha senso metterlo in 8 bit. A questo punto calcola un checksum
Comando ed informazione li metterei insieme nel corpo del request frame. In situazioni come questa vedo più utile un approccio del tipo:

Codice: Seleziona tutto

header{ indirizzo, caratteristiche del pacchetto, etc}
body {corpo del pacchetto}
check {checksum}


Inoltre dal momento che i serventi potrebbero non essere disponibili alla ricezione piuttosto di perdere pacchetti per strada è bene implementare una doppia sincronizzazione di chi invia e di chi riceve.

[daniele1996]

Inoltre dal momento che i serventi potrebbero non essere disponibili alla ricezione piuttosto di perdere pacchetti per strada è bene implementare una doppia sincronizzazione di chi invia e di chi riceve.

i pin usati li collego agli interrupt cosi se per caso un dispositivo deve inviare un'informazione alla centrale, la centrale interrompe il codice che sta eseguendo e processa i dati nella uart. cosi facendo i dati non vengono persi, in piu quando la centrale invia, fa l'interrupt nei dispositivi, invia l'indirizzo del destinatario, e ogni dispositivo controlla se è il proprio indirizzo, se non lo è prosegue con il codice principale, invece se lo è si predispone con la uart, legge ed esegue la richiesta.

Una cosa che non mi è chiara: in che senso etichettare i dispositivi?

[fairyvilje]

E io ti rispondo:

• Cosa succede se la centrale non può interrompere il codice che sta eseguendo?
• Cosa succede se il dispositivo non è in grado di ricevere l'interrupt/non può interrompere il codice che sta eseguendo?
• Cosa succede alla centrale se attende risposta da un dispositivo che non darà mai risposta?
• La rete è statica o può cambiare configurazione senza richiedere una nuova compilazione di un nuovo programma?
• Posso "staccare" ed "attaccare" dispositivi durante il normale funzionamento?

Non voglio mandarti in crisi o cose simili, solo farti riflettere sulle possibili implicazioni di una soluzione semplicistica.

[daniele1996]

1) la centrale deve avare sempre gli interrupt attivi
2) il dispositivo avrà sempre gli intrerrupt attivi
3) si imposta un timeout
4) la rete è statica
5) non si possono attaccare/stacare i dispositivi

[fairyvilje]

Quindi assicuri in ogni contesto che non ci sono operazioni non interrompibili? Tipo non scriverai mai su una eeprom? Non avrai più task in esecuzione e cambi di contesto da effettuare?
Note queste cose si può andare oltre.