Software serial

International Italiano Generale
21

gbm:
Ciao, Astro cito wiki inglese: Checksum - Wikipedia

Quello che c'è scritto è corretto, però tu lo hai interpretato in modo sbagliato e hai generalizzato un caso particolare.
C'è scritto che la probabilità di ottenere lo stesso checksum nel caso esclusivo di due byte sbagliati è 1/256, però nel mondo reale è molto, ma molto, difficile che arrivano solo due byte errati il che abbassa enormemente la percentuale di possibile errore.
Tieni presente che se i byte sbagliati sono dispari l'errore viene sempre rilevato, se sono un multiplo di due la percentuale si riduce di un fattore 256 per ogni coppia, ovvero su quattro byte è 1/65556 etc.
Inutile dire che se la linea dati è fatta come si deve di byte errati ne arrivano pochissimi, si parla di 1 ogni qualche mega, se invece la linea è soggetta a molti errori per cause ambientali la reale possibilità di errore è comunque molto più bassa di 1/256 e poi il controllo integrità non si basa solo sul checksum/crc, ci sono di mezzo anche il preambolo, il postambolo e il timeout del pacchetto che concorrono ad abbassare ulteriormente la possibilità di ricevere, e validare, un pacchetto dati errato.
In tutti i casi a me non sta sulle palle il crc, lo uso spesso e volentieri, ti ho solo dato un consiglio calibrato su Arduino dove già pesa molto la presenza del C++, se poi ci metti pure altri carichi di lavoro non indispensabili non ti lamentare se alla fine diventa lentissimo :smiley:

22

Gli algoritmi che avevo suggerito NON sono CRC nel vero senso della parola ma sono validi algoritmi di somme di controllo (CRC era inteso in quel senso).

Non penso che qualcuno con l'Arduino abbia da comandare i missili termonucleari di una postazione militare e quindi avere la necessità assoluta di una trasmissione totalmente priva di errori. Un CRC come quelli segnalati penso che servano già allo scopo.

23

Dipende ragazzi!

Mi sono scritto da 0 un protocollo e lo sto provando attraverso diversi media (filo di rame, LEDs quindi luce, attraverso un cavo in rame, attraverso il mio corpo :grin: e con il suono, cioè due piezini che si guardano), funziona in tutti i casi ma il noise è elevato per tutti i test a parte che con il filo di rame. Ci sono situazioni, soprattutto se usi due led come RX/TX in cui ad alta distanza (1m) il noise è elevato ed è necessario un CRC. In qualsiasi caso gli errori aumentano in rapporto inversamente proporzionale alla velocità di trasmissione e alla distanza tra tx e rx (anche con il filo vale)....infatti diminuendo la durata di ogni bit gli errori aumentano.

Ovviamente in una situazione normale con un buon cavo in rame utilizzato come medium di trasmissione ha assolutamente ragione Astro. Il CRC puo' anche essere trascurato a basse velocità di trasmissione (quindi lontani dai limiti del protocollo). Ma io sto cercando velocità attraverso media non convenzionali quindi ne ho bisogno.

In qualsiasi caso un protocollo non sicuro è un grosso limite per la sperimentazione su progetti complessi, per esempio:

In questo progetto una scansione 3d rappresentata bisimensionalmente in scala di grigi con un sistema tiltpan a distanza elevata puo' durare anche 20 minuti, e la connessione è seriale. Una volta su due si inchioda a metà perchè a Processing arriva un carattere sbagliato oppure, arrivano codici RGB non corrispondenti a quello che sta percependo il sensore. Un altro esempio in cui il controllo di integrità sarebbe comodo