spacer.png, 0 kB

Torna indietro   Roboitalia.com - Il primo portale in Italia sulla robotica amatoriale > Robotica di base > Informatica > P. in Basic per micro

Rispondi
 
Strumenti discussione Modalità  visualizzazioe
  #1  
Vecchio 07-07-2017, 09.38.34
L'avatar di aldofad
aldofad aldofad non è collegato
Robottaro sostenitore
 
Data registrazione: 22-01-2007
Residenza: Treviso
Età : 41
Messaggi: 925
Potenza reputazione: 78
aldofad Il suo nome è noto a tutti
Invia un messaggio via MSN a aldofad Send a message via Skype™ to aldofad
Predefinito Protocollo seriale ...un pò avanzato

Ciao a tutti,
mi sto divertendo a far comunicare via bluetooth un'applicazione per dispositivi Android, che ho scritto con Android Studio, con Arduino.
Mi sono reso conto però che finchè si spedisce un byte ogni tanto, tutto va bene, ma quando si comincia a spedirne parecchi, capita che qualche byte ricevuto non corrisponda a quello spedito.
Al di la delle cause (disturbi etere o frequenza troppo elevata), ho deciso di creare un protocollo affinchè il ricevitore scarti i bytes distorti.

Ciò che ho fatto funziona bene ma non vorrei aver reinventato la ruota e se c'è qualcosa di più efficace/efficiente, lo valuto volentieri.

Il protocollo che ho inventato è molto semplice e provo a spiegarlo.
Ho deciso che il byte 255 indica l'inizio di un pacchetto.
Ma potrei aver bisogno nei miei dati proprio del 255 e non ho voglia di complicarmi la vita con escapes e sequenze.
Quindi i bytes che seguono il 255 (il tag di inizio pacchetto) vengono convertiti da base 256 a base 255.
In altre parole se devo spedire il byte 23 questo diventa due byte, 0 e 23.
Se devo spedire proprio il byte 255, questo diventa due byte, 1 e 0
Insomma, è una semplice conversione di base.
Nel pacchetto ho inserito il controllo errore, un checksum, costituito dai bytes logici ripetuti.
Alla fine di tutto, se devo spedire il byte 23, il pacchetto completo diventa
255-0-23-0-23
e se devo spedire proprio il 255, il pacchetto diventa:
255-1-0-1-0

Ovviamente alla ricezione basta controllare che dopo ogni 255 ci siano due coppie di bytes uguali

E' evidente che ho raggiunto l'obiettivo con una fatica davvero minima, il codice scritto per l'implementazione, sia in trasmissione che in ricezione, è pietosamente poco e semplice. Tuttavia l'overhead credo sia abbastanza, per comunicare un byte ne spedisco 5.

In seguito gestirò anche la richiesta di reinvio dei pacchetti errati (e vai con altro overhead...)

Avete qualche suggerimento migliorativo in merito?

Salutone
Rispondi citando
  #2  
Vecchio 08-07-2017, 09.16.10
L'avatar di guiott
guiott guiott non è collegato
Robottaro sostenitore
 
Data registrazione: 23-04-2004
Residenza: Roma
Età : 61
Messaggi: 1,415
Potenza reputazione: 328
guiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua fama
Invia un messaggio via AIM a guiott Invia un messaggio via MSN a guiott Invia un messaggio via Yahoo a guiott Send a message via Skype™ to guiott
Predefinito

Come dici giustamente, nel campo dei protocolli è già stato inventato tutto

Io, all'epoca, mi ero inventato questo

serviva per mandare più byte in un pacchetto ed essere comunque molto leggero, anche come occupazione di banda, quindi usavo i dati in binario, tranne che per l'header. La sincronizzazione c'era comunque con il contatore di byte e la checksum. Non ho mai fatto grosse analisi di affidabilità, però in quel caso se perdevo qualche pacchetto non era un grosso problema. Un dato errato non arriva perché non ha la struttura corretta.

Per mandare pochissimi byte come nel tuo caso, forse è meglio accettare l'overhead della conversione in ascii esadecimale piuttosto che il cambiamento di base.
Se usi il formato HEX ti eviti tutti i problemi, tanto usi comunque due byte per un carattere. Diventa anche più facile da debuggare con un teminale ASCII qualsiasi. l'header rimane il byte 255 in binario, il payload 255 diventa FF in ASCII (byte 70-70), il payload 0 diventa 48-48 e così via.

nel tuo esempio diventerebbe:

255-50-51-checksum a 8 bit

per la checksum, senza usare polinomiali complicate tipo CRC che, se pur molto più sicure caricano molto un micro piccolo, potresti usare una semplice somma troncata a 8 bit di tutti i caratteri del pacchetto, così li controlli tutti. Per aumentare la sicurezza potresti fare la somma a 16 bit.
__________________
Guido
------
www.guiott.com
Rispondi citando
  #3  
Vecchio 08-07-2017, 12.52.27
L'avatar di aldofad
aldofad aldofad non è collegato
Robottaro sostenitore
 
Data registrazione: 22-01-2007
Residenza: Treviso
Età : 41
Messaggi: 925
Potenza reputazione: 78
aldofad Il suo nome è noto a tutti
Invia un messaggio via MSN a aldofad Send a message via Skype™ to aldofad
Predefinito

Ah, ho capito Guido, si, vero, con il tuo diventa immediato il debug a terminale, buona idea.

Un saluto
Rispondi citando
  #4  
Vecchio 15-07-2017, 11.14.41
L'avatar di aldofad
aldofad aldofad non è collegato
Robottaro sostenitore
 
Data registrazione: 22-01-2007
Residenza: Treviso
Età : 41
Messaggi: 925
Potenza reputazione: 78
aldofad Il suo nome è noto a tutti
Invia un messaggio via MSN a aldofad Send a message via Skype™ to aldofad
Predefinito

Mi sono fatto prendere la mano e sono andato un pò oltre. Ho messo in piedi un protocollo seriale con checksum in grado di spedire pacchetti fino a 254 bytes con un overhead di soli 4 bytes. Se i dati da spedire sono di meno, allora il pacchetto sarà automaticamente più piccolo senza doversene preoccupare.
Sto testando il protocollo tra Android e Arduino via Bluetooth, ossia tra Java e C++. Funziona alla grande e le librerie che sto facendo sono molto ricche e semplicissime da usare per l'utente finale. Con una sola riga di codice si comincia a ricevere e con un'altra si spedisce. Si possono comporre facilmente pacchetti formati da tutti i tipi di dati base con anche le stringhe.

Una cosa simpatica è che le librerie danno la possibilità di simulare comodamente in Java sul proprio PC tutto il sistema di comunicazione, sto trovando questa modalità molto comoda anche a scopo di doppia verifica. Di fatto simulo l'etere con l'UDP

Questo lavoretto lo andrò ad integrare in un altro progetto terminato anni fa.

A questo punto perchè non posso fare anch'io una pcb che chiamerei Aldoino?
La board conterrebbe un ATMega328P con modulo Bluetooth HC-05 e socket per XBee. Lo stesso protocollo si usa sia per il Bluetooth che per XBee

Con la Aldoino in mano e la libreria è possibile cominciare subito a trasmettere e ricevere la prima stringa tra Android, Arduino e XBee

Diciamo che ormai sono a pochi passi dalla prima release che potrei già mandare in stampa.

Al momento il protocollo funziona per la trasmissione solo tra due punti ma a brevissimo gestisco anche l'indirizzamento, così da coprire anche l'uso in XBee non solo in broadcast. Ovviamente tutto può funzionare anche con i ricetrasmettitori economici da 433 MHz, parto con l'XBee solo perchè il mio progetto lo prevede

Salutone da Aldoino

Ultima modifica di aldofad : 15-07-2017 alle ore 11.27.21
Rispondi citando
  #5  
Vecchio 15-07-2017, 11.42.02
L'avatar di guiott
guiott guiott non è collegato
Robottaro sostenitore
 
Data registrazione: 23-04-2004
Residenza: Roma
Età : 61
Messaggi: 1,415
Potenza reputazione: 328
guiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua fama
Invia un messaggio via AIM a guiott Invia un messaggio via MSN a guiott Invia un messaggio via Yahoo a guiott Send a message via Skype™ to guiott
Predefinito

GRANDE!!

restiamo in attesa di demo.

Mi posso permettere di suggerire un micro un po' più moderno dell'ATMega328P.

L'arduino zero (o M0 pro) usa il SAM D21. Alla fine costa anche meno dell'ATMega ma è un Cortex M0. Un 32bit contro un 8bit.
Si trovano tutti gli schemi e il bootloader ed è gestito dal classico IDE.
Non si trova l'EDBG, il chip di debug integrato montato sulla scheda originale ma puoi farne a meno, la programmazione funziona anche tramite l'USB integrata.

Facci un pensiero.
__________________
Guido
------
www.guiott.com
Rispondi citando
  #6  
Vecchio 15-07-2017, 12.09.17
L'avatar di aldofad
aldofad aldofad non è collegato
Robottaro sostenitore
 
Data registrazione: 22-01-2007
Residenza: Treviso
Età : 41
Messaggi: 925
Potenza reputazione: 78
aldofad Il suo nome è noto a tutti
Invia un messaggio via MSN a aldofad Send a message via Skype™ to aldofad
Predefinito

Si, buon suggerimento Guido, è vero che mi devo aggiornare ma la prima release di Aldoino la faccio ancora con l'ATMega328P per compatibilità con il mio vecchio progetto, così posso testare subito bene il software.
Poi ho già messo tra le cose da fare nella mia mente l'adozione di un micro un pò più avanzato. Faccio fatica ad aggiornarmi perchè ci ho messo parecchio a imparare a fare un pò di cosine importanti con l'ATMega328P che per me sono avanzate, ad esempio so gestire bene l'ibernazione sotto molti aspetti, oppure farmi l'immagine per il bootloader per frequenze e tensioni di alimentazione diverse, insomma ci ho sbattuto la testa parecchio. Non è propriamente la mia vocazione la gestione a basso livello dei micro ma sono d'accordo che mi devo aggiornare

salutone

Ultima modifica di aldofad : 15-07-2017 alle ore 12.15.53
Rispondi citando
  #7  
Vecchio 15-07-2017, 12.40.36
L'avatar di guiott
guiott guiott non è collegato
Robottaro sostenitore
 
Data registrazione: 23-04-2004
Residenza: Roma
Età : 61
Messaggi: 1,415
Potenza reputazione: 328
guiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua famaguiott La sua reputazione è oltre la sua fama
Invia un messaggio via AIM a guiott Invia un messaggio via MSN a guiott Invia un messaggio via Yahoo a guiott Send a message via Skype™ to guiott
Predefinito

Embé! Se vai fuori dagli standard

Hai ragione, io intendevo nell'utilizzo sotto IDE con le librerie standard.
Se vai a livello macchina il lavoro è molto. Il datasheet ha quasi 1000 pagine!
__________________
Guido
------
www.guiott.com
Rispondi citando
  #8  
Vecchio 15-07-2017, 13.07.55
L'avatar di aldofad
aldofad aldofad non è collegato
Robottaro sostenitore
 
Data registrazione: 22-01-2007
Residenza: Treviso
Età : 41
Messaggi: 925
Potenza reputazione: 78
aldofad Il suo nome è noto a tutti
Invia un messaggio via MSN a aldofad Send a message via Skype™ to aldofad
Predefinito

Devo spiegare una cosa.
Il sistema che sto mettendo in piedi, integrato con il mio vecchio progetto, è questo.

Supponiamo che io dispongo di 4 board Aldoino identiche tra loro.

3 di queste board le configuro per stare ibernate, solo ogni 8 secondi si svegliano per un brevissimo istante per controllare se nell'etere è presente un segnale che richiede il loro risveglio completo, se non è presente tornano a dormire. Il consumo in questa condizione è ridicolo, sono mesi che attendo lo scaricamento di una batteria al litio da 1 Ah.

La quarta board Aldoino invece la tengo in tasca, non va mai in ibernazione e con il mio telefono Android mi ci collego tramite Bluetooth usando una semplice App che ho scritto con Android Studio. Tramite l'app posso ordinare il risveglio di tutte le Aldoino presenti, anche a grande distanza, dal momento che il modulo XBee Digimesh adopera appunto una rete mesh. Una volta che tutte le Aldoino sono sveglie posso eseguire un test di comunicazione che mi da la conferma che tutte stanno comunicando bene via XBee, dopodichè, sempre tramite app posso comandare lo stato di un relay interno ad ogni Aldoino con conferma di ricezione dello stato.

Ultima modifica di aldofad : 15-07-2017 alle ore 13.15.22
Rispondi citando
Rispondi


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
Protocollo I2C Alan100 Arduino 10 08-08-2014 19.07.40
Tutorial Protocollo CAN Fu Mauro Comunicazione 22 05-10-2011 17.07.53
Editor avanzato per ipad Ziko Discussioni off-topic 9 26-08-2011 23.07.30
Protocollo: Pratica nonno_62 Progetto robot MODDI (forum chiuso) 23 18-02-2007 21.02.06
Protocollo marnic Progetto robot MODDI (forum chiuso) 115 30-09-2006 17.37.34


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


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