spacer.png, 0 kB

Torna indietro   Roboitalia.com - Il primo portale in Italia sulla robotica amatoriale > Progetti di Robot > Progettazione > Progetto robot MODDI (forum chiuso)

 
 
Strumenti discussione Modalità  visualizzazioe
  #1  
Vecchio 20-12-2006, 22.45.15
nonno_62 nonno_62 non è collegato
Robottaro sostenitore
 
Data registrazione: 25-11-2005
Residenza: sardegna
Età : 68
Messaggi: 572
Potenza reputazione: 74
nonno_62 E' un faro della comunità
Predefinito Protocollo: Pratica

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.

Ultima modifica di nonno_62 : 20-12-2006 alle ore 23.07.49
  #2  
Vecchio 21-12-2006, 18.28.05
nonno_62 nonno_62 non è collegato
Robottaro sostenitore
 
Data registrazione: 25-11-2005
Residenza: sardegna
Età : 68
Messaggi: 572
Potenza reputazione: 74
nonno_62 E' un faro della comunità
Predefinito

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

Mi basterebbe anche un posto dove studiare

Saluti Nonno
  #3  
Vecchio 21-12-2006, 20.07.42
L'avatar di selfservice
selfservice selfservice non è collegato
Moderator
 
Data registrazione: 16-11-2003
Residenza: Foligno
Messaggi: 1,183
Potenza reputazione: 87
selfservice E' circondato da una spettacolare aurea
Invia un messaggio via MSN a selfservice
Predefinito

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
__________________
Beatu chi lu pota, beatu chi lu zappa, na paralise secca a chi ce mette l'acqua!
  #4  
Vecchio 21-12-2006, 21.17.10
L'avatar di marnic
marnic marnic non è collegato
Administrator
 
Data registrazione: 24-05-2002
Residenza: Monselice (PD)
Età : 55
Messaggi: 5,457
Potenza reputazione: 414
marnic La sua reputazione è oltre la sua famamarnic La sua reputazione è oltre la sua famamarnic La sua reputazione è oltre la sua famamarnic La sua reputazione è oltre la sua famamarnic La sua reputazione è oltre la sua famamarnic La sua reputazione è oltre la sua famamarnic La sua reputazione è oltre la sua famamarnic La sua reputazione è oltre la sua famamarnic La sua reputazione è oltre la sua fama
Predefinito

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"
__________________
Marnic
Roboitalia Staff
www.fabbrimarco.com
  #5  
Vecchio 21-12-2006, 23.14.34
nonno_62 nonno_62 non è collegato
Robottaro sostenitore
 
Data registrazione: 25-11-2005
Residenza: sardegna
Età : 68
Messaggi: 572
Potenza reputazione: 74
nonno_62 E' un faro della comunità
Predefinito

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.
  #6  
Vecchio 21-12-2006, 23.32.28
nonno_62 nonno_62 non è collegato
Robottaro sostenitore
 
Data registrazione: 25-11-2005
Residenza: sardegna
Età : 68
Messaggi: 572
Potenza reputazione: 74
nonno_62 E' un faro della comunità
Predefinito

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
  #7  
Vecchio 22-12-2006, 06.49.54
L'avatar di astrobeed
astrobeed astrobeed non è collegato
Robottaro sostenitore
 
Data registrazione: 18-03-2004
Residenza: Roma
Età : 58
Messaggi: 3,377
Potenza reputazione: 343
astrobeed La sua reputazione è oltre la sua famaastrobeed La sua reputazione è oltre la sua famaastrobeed La sua reputazione è oltre la sua famaastrobeed La sua reputazione è oltre la sua famaastrobeed La sua reputazione è oltre la sua famaastrobeed La sua reputazione è oltre la sua famaastrobeed La sua reputazione è oltre la sua famaastrobeed La sua reputazione è oltre la sua fama
Predefinito

Citazione:
Orginalmente inviato da nonno_62 Visualizza messaggio
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.
__________________
Bye
  #8  
Vecchio 22-12-2006, 13.38.06
L'avatar di sergio_camici
sergio_camici sergio_camici non è collegato
Administrator
 
Data registrazione: 24-05-2002
Residenza: Binasco (MI)
Età : 53
Messaggi: 2,665
Potenza reputazione: 295
sergio_camici La sua reputazione è oltre la sua famasergio_camici La sua reputazione è oltre la sua famasergio_camici La sua reputazione è oltre la sua famasergio_camici La sua reputazione è oltre la sua famasergio_camici La sua reputazione è oltre la sua famasergio_camici La sua reputazione è oltre la sua famasergio_camici La sua reputazione è oltre la sua fama
Predefinito

Citazione:
Orginalmente inviato da nonno_62 Visualizza messaggio
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
__________________
ciao
Sergio
---
Hai deciso di costruire un robot? Bene...
Cominciamo dalle brutte notizie: non e' facile...
  #9  
Vecchio 23-12-2006, 23.44.09
nonno_62 nonno_62 non è collegato
Robottaro sostenitore
 
Data registrazione: 25-11-2005
Residenza: sardegna
Età : 68
Messaggi: 572
Potenza reputazione: 74
nonno_62 E' un faro della comunità
Predefinito

Citazione:
Orginalmente inviato da astrobeed Visualizza messaggio
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

Ultima modifica di nonno_62 : 24-12-2006 alle ore 00.06.33
  #10  
Vecchio 13-02-2007, 17.26.04
Alan2 Alan2 non è collegato
Robottaro master
 
Data registrazione: 23-12-2004
Residenza: Milano
Età : 32
Messaggi: 200
Potenza reputazione: 59
Alan2 E' per ora ancora un mistero
Predefinito

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.

Ultima modifica di Alan2 : 13-02-2007 alle ore 17.28.53
 


Utenti attualmente attivi che stanno leggendo questa discussione: 1 (0 utenti e 1 ospiti)
 
Strumenti discussione
Modalità  visualizzazioe

Regole di scrittura
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code è Attivato
Le smilies sono Attivato
[IMG] è Attivato
Il codice HTML è Disattivato

Vai al forum

Discussioni simili
Discussione Autore discussione Forum Risposte Ultimo messaggio
Distanza con protocollo SPI. Ziko Comunicazione 3 27-08-2012 12.21.49
Tutorial Protocollo CAN Fu Mauro Comunicazione 22 05-10-2011 17.07.53
Più strada cambiando protocollo. Ziko Comunicazione 8 28-01-2011 11.29.05
Protocollo marnic Progetto robot MODDI (forum chiuso) 115 30-09-2006 17.37.34
guida pratica per realizzare un minisumo valpale Minisumo 9 19-03-2005 12.01.40


Tutti gli orari sono GMT. Adesso sono le: 22.04.31.


Basato su: vBulletin Versione 3.8.8
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Realizzazione siti web Cobaltica Foligno
spacer.png, 0 kB