Protocollo: Pratica

[nonno_62]

Sto ancora giochicchiando con l'os del displayminimo ..... uffff ci sto dedicando troppo poco tempo, e ogni volta mi serve più tempo per capire dove ero arrivato che per quello di nuovo che faccio.

In ogni caso bando alle ciance ..... e affrontiamo ciò che durante le notti insonni mi fa stare sveglio (si scherza ovviamente).

La prima domanda che mi pongo è come riconosco l'inizio pacchetto?

Le risposte che mi sono dato sono le seguenti:

1) 9 bit, il byte di inizio pacchetto ha il nono bit a uno. Però se non ricordo male il nono bit non è supportato dagli atmel, e così abbiamo deciso di non usarlo;

2) il primo carattre del paccheeto è un carattere speciale, questo cosa comporta? Bisogna leggere tutti i byte dell'intestazione ogni volta che ci troviamo di fronte al byte di inizio pacchetto (per escludere che nel byte di intestazione capiti più volte il byte speciale) e usare il byte di len per contare i byte non utili, letti e scartati, infine controllare che il successivo byte sia di nuovo un byte di inizio pacchetto. Insomma mi sembra un pò un casino .... cioè mi sembra che si sprechi molto tempo per non fare nulla, inoltre se ci si disallinea come si fa a riallinearsi ...... Per ultimo per evitare al massimo gli errori sarebbe da inviare i byte dei dati sotto forma di byte in formato ascii, in pratica il bit 7 è a zero. questo comporta che ilprimo byte è per forza maggiore di 0x80 ..... e che dati semplici (0-255) prenderanno più byte per l'invio.

3) Iniziare la lettura del pacchetto solo dopo che fra un byte trasmesso e l'altro sia passato un certo tempo (io dicevo almeno due volte il tempo dell'invio di un byte, con clok a 40 mhz e trasmissione a 115 kbps sono circa 85 ns x 2, cioè circa 850x2 istruzioni macchina), per essere sicuri che è proprio l'inizio della stringa trasmessa. Questo sistema però implica l'uso di un timer, che va resettato dopo la ricezione del bit di stop. Quando un altro byte è trasmesso si verifica il tempo che è trascorso e si verifica se questo è maggiore o minore del tempo di inizio messaggio ...... Un'ultima considerazione, invece di dedicare un timer a questo scopo si può usare il timer del tick di sistema, si legge il valore ..... poi si rilegge e si fa la differenza ....... forse si è limitati nelle pause ......

4) .......... bohhh

Riflessioni?

Saluti Nonno

PS Ripensando al convertitore rs232-rs485-wifi, la seriale hardware dovrebbe dare pochi problemi, però la gestione della seriale software (zigbee e rs232) se mandata ad esempio a 115 kbps sarà una vera sfida ..... visto che posso fare solo 85 istruzioni fra un bit e un'altro a 40 mhz.

[nonno_62]

E' un post non visto .... o mi volete abbandonare prorpio ora ......

Mi basterebbe anche un posto dove studiare

Saluti Nonno

[selfservice]

io l'ho letto solo ora...
se decidiamo di spedire i dati in ascii diventa tutto più semplice, basta un interrupt che a ogni ricezione confronta il byte ricevuto con il byte di start...
il rovescio della medaglia è che va tutto convertito in ascii prima di essere spedito. e se tocca spedire un numero? per spedire per es 230 per esempio ci vogliono 3 byte, quando ne basterebbe uno...

quindi penso sia da considerare l'uso di un timer per determinare quanto tempo passa tra un byte e l'altro... se tale tempo è maggiore di tot allora quello che arriva è un nuovo pacchetto

[marnic]

Non vorrei dire ma forse è più frequente spedire dei numeri (valori di variabili, sensori, dati tipo velocità accelerazione ecc.)

Devo dire la verità nel primo lungo 3D sul protocollo mi ero perso e ho seguito molto poco ma, ci stiamo reinventando il protocollo RS232 o 485?
Se uso il picbasic o anche il C (credo) e dico al pic "SEROUT hello word" sul terminale di windows mi vedo "hello word" non ho idea (si fa per dire) di come siano messi i bit però funziona......
Se ci sono altri motivi per rifare ed erano già stati affrontati siete autorizzati a rispondere: "Taci e leggi"

[nonno_62]

E' vero forse ho parlato tanto senza dire il perchè delle mie considerazioni.

In un sistema multiutente con un master e tanti client, come sarà la rs485 almeno in un primo momento, presumo che il master ciclicamente interrogherà le periferiche collegate.

E' ovvio che il master deve necessariamente interrogare ciclicamente e con una certa frequenza tutte le periferiche collegate. Perchè se una di quest'ultime deve comunicare dei dati (non siamo nel multimaster dove ogni scheda prova a trasmettere quando serve) lo può fare solo dopo essere stata interrogata. (lo vedremo in un altro post questo)

Da quello che ho detto si capisce che il traffico di dati sarà enorme, anche solo del tipo: "periferica 1 ci sei" .... "si" ... "perif-2 ci sei" ...... "si" ...... "p3?" ..... "si" ...... etc.

Qui si aprono due strade. Sistema ideale senza errori, e sistema reale con possibilità di errori nella trasmissione.

Qui ulteriori due strade, tempo cpu impiegato per fare le operazioni base (ogni scheda sarà impegnata a fare qualcosa) o per controllare la rs485.

Se avviene un errore nella trasmissione è probabile che la periferica che legge un dato per un altro deve sapere come riallinearsi ...... da dove inizierà la nuova la stringa trasmessa?

Inoltre se io so dove inizia la stringa posso anche comportarmi così:

se è l'inizio trasmissione verifico se l'indirizzo di destinazione sono io,
- se si mi leggo tutta la stringa memorizzando i singoli byte per poi analizzarli a cominciare dalla len (che mi indica i byte da leggere) per finire ai comandi e ai dati ........

- se l'indirizzo di destinazione non sono io leggo i byte ma semplicemente li scarto fino alla nuova condizione di inizio trasmissione ....

E' ovvio che in questo secondo caso mi ritrovo con la cpu che non perde tempo a controllare, a memorizzare e a analizzare tutti i byte trasmessi, ma lo fa solo se di interese per le proprie attività. con un notevole risparmio di tempo cpu che ne frattempo farà altro, come controllare il PID ........

Saluti Nonno

PS Ma come individuare l'inizio trasmissione, io non lo so o meglio ho fatto alcune ipotesi ma non so se sono esaustive del problema.

[nonno_62]

Mi ero dimenticato di dire:

Se la comunicazione è invece fra solo due periferiche è ovvio che bata anche il serout. Perche se il master invia dati sulla linea, sono per forza dell'unico client presente. Inoltre con buona probabilità il master non invierà altri dati se prima non avrà ricevuto una risposta dal client ..... molto, ma molto più semplice da gestire, addirittura gestibile in sequenziale. Ricevo comando, elaboro (senza preoccuparmi più della seriale) rispondo aspetto il messaggio .............. etc....

Nel nostro sistema rs485 con fino a 32 periferiche, si deve per forza, mentre si fanno i propri compiti, verificare se abbiamo una richiesta che ci interessa dalla seriale .......

Saluti Nonno

[astrobeed]

Orginalmente inviato da nonno_62

Nel nostro sistema rs485 con fino a 32 periferiche, si deve per forza, mentre si fanno i propri compiti, verificare se abbiamo una richiesta che ci interessa dalla seriale .......

Ti (vi) do un consiglio, guardati il protocollo MODBUS, che è molto usato con la RS485, è open e molto valido, non è difficile da implementare e si trovano una marea di librerie open già fatte che lo implementano per PC, PIC e AVR.

[sergio_camici]

Orginalmente inviato da nonno_62

Ma come individuare l'inizio trasmissione, io non lo so o meglio ho fatto alcune ipotesi ma non so se sono esaustive del problema.

Diro' una banalita'...

Il pacchetto inizia sempre con un Byte di Start.
Il ricevente si sincronizza con quel byte.

Se all'interno del pacchetto e' necessario trasmettere lo stesso valore usato come start lo si trasmette doppio

[nonno_62]

Orginalmente inviato da astrobeed

Ti (vi) do un consiglio, guardati il protocollo MODBUS, che è molto usato con la RS485, è open e molto valido, non è difficile da implementare e si trovano una marea di librerie open già fatte che lo implementano per PC, PIC e AVR.

Azzz se trovo chi ha inventato l'inglese ..............

Mi sono scaricato i due manuali sul layer 7 e sul layer 1 e 2. Fra un'imprecazione e l'altra me li sono letti, sperando di aver capito tutto riporto qui le mie considerazioni:

1) Capisco perchè in ambito industriale è molto usato ...........

2) In riferimento ai miei dubbi, mi sembra che uno dei metodi usati sia quello di avere lo start tramite un 3,5 tempi carattere di pausa o nel caso di trasmissione ASCII si usa un carattere di start e due di stop, il resto è inviato con carratteri ascii raffiguranti solo i caratteri esadecimali (Sergio così è impossibile che il byte di inizio si trovi in mezzo al pacchetto) ...... insomma non mi sembra che stavo tanto lontano poi ..........

3) Geniale l'idea di usare per riferimento sugli slave dei registri, come se si stessero usando i registri interni al micro, o quasi.

4) Secondo me e per come la vedo io macherebbe una possibilità fondamentale, la risposta ad una richiesta dati è generalmente immediata ma manca la possibilità di una risposta differita, del tipo:
a. "chiedo dati"
b. "ho capito te li do più tardi" (risposta standard con len=0=non pronti)
a. (fa altro)
.....
a. "dati pronti" (comando nuovo da implementare)
b. "si" (oppure) "no" (risposta standard con len=0=non pronti)

se si, b. invia anche i dati richiesti ......... Non capisco, è un sistema che si interfaccia su diversi sistemi di trasporto, ma perchè non hanno previsto la risposta differita che è fondamentale se si hanno bus a velocità diverse .....

5) ci sono dei comandi lasciati liberi per l'utente, io aggiungerei quello di cui sopra sopra (da studiare) ...... e forse qualcuno non lo implementerei ........

6) Non concordo con la scelta di avere registri a 1 o a 16 bit ..... io avrei optato per 1 o 8 bit, tanto si possono leggere più registri in contemporanea, ma io (noi) ho altri scopi.........

7) forse la len sul comando da master a slave andrebbe inplementata ..... non so

L'implementazione non mi sembra molto difficile, i comandi effettivi sono pochi, e molto simili .... scrivi registro/gruppo registri .... leggi reg./gruppo reg. scrivi dati in un file leggilo e pochi altri. Ho fatto un giro per librerie e mi sembra che il meno supportato sia proprio il pic .... il giro era veloce vedrò di cercare meglio.

Il sistema è prettamente monomaster, ad esempio usa un solo byte di header, che è l'indirizzo dello slave, il resto sono già dati, insomma monomaster ma molto, anzi moltissimo efficente.

Non so cosa ne pensano gli altri ....... con le modifiche dette si potrebbe quasi adottare ..........

Saluti Nonno

[Alan2]

Io butto lì una soluzione:

|START|ID|DATALEN|DATO|CRC|STOP|

Tutti i campi (eccetto quello dei dati) sono composti da un byte.
Quando ricevo un dato genero un'interrupt che verificherà ed interpreterà un eventuale pacchetto.
Alla fine del pacchetto (che finisce con il campo di STOP) esco dall'interrupt ed elaboro i dati ricevuti secondo le mie esigenze.
Se si è verificato un errorre, mando un messaggio di errore all'interò BUS, in questo modo chi mi ha inviato il messaggio saprà che c'è stato un errore e lo invierà nuovamente.

START è l'inizio del pacchetto e (ad esempio) contiene un carattere speciale.
ID è l'ID di ogni dispositivo.
DATALEN contiene il numero di Byte da leggere, quindi se ad esempio contiene il valore 8, sò che ci sono 8 byte da leggere e se tra questi c'è il carattere dello start sò che non è un campo del blocco start ma è un campo del blocco data.
DATA contiene i dati.
CRC serve a verificare errori nel messaggio.
STOP indica la fine del messaggio quindi esco dall'interrupt.