Cheksum o Paridad??

[cucaracha]

Aun soy algo novato en el uso de RS232. En el programa que estoy haciendo me gustaría controlar los posibles errores en la comunicación.
Para eso creo que se usa la paridad o una rutina que haga un cheksum.
Me pueden ayudar sobre esto. Cual el la mejor manera de hacerlo y como??
Uso el CCS. Trae este alguna función para hacer estas cosas??

Por cierto, y con el I2C que se hace. O no se hace nada?? Ya que a ver como le explico yo a un RTC que me envíe un cheksum o una paridad o que compruebe la que yo le envío... Que se hace pues, leer dos veces y comprobar, cuando leo,  y escribir y luego leer para comprobar, cuando escribo (que de tiempo perdido no?)

Saludo!!

[cucaracha]

Eeeeeh! Nadie tiene nada desde donde partir...

Digan algo, no se, alguna experiencia religiosa con esto de los errores en las transmisiones...

Saludos!!

[pacalaconcurso]

puedes usar el CRC de modbus...o mejor modbus
y ya lo tienes todo...piensa que lo puedes implementar sobre 232..... asi que al ETE.

[Elena2000]

Hola Cuca!

Básicamente, lo que necesitas es un algoritmo que acepte una cadena de texto como entrada y devuelva ún número de bits. La idea es que si pasas el algoritmo al fichero antes de enviarlo, debes obtener un número de bits exactamente idéntico al resultado de pasar el algoritmo al fichero recibido después de la comunicación.
El checksum es un algoritmo de este tipo, me parece que va creando "polinomios" con la cadenas de texto de entrada, y va hallando sumas parciales de no se qué... pero al final lo que te da es un numerito. De hecho en la Kshell de unix existe este comando, checksum, o sea que si estás usando linux, por ejemplo, con hacer un script del checksum del fichero te vandría.

Pero.... como dices que estás usando C, te recomiendo que busques las librerías del algortimo MD5, que es una función de cifrado tipo hash que acepta una cadena de texto como entrada, y devuelve un número de 128 bits. Esto lo usan en seguridad, sabes? para firma electrónica, porque este tipo de algoritmos tienen dos ventajas: Es imposible (computacionalmente) reconstruir la cadena original a partir del resultado, y además es también imposible encontrar dos cadenas de texto que generen el mismo resultado.

Voy a buscar los .h y .c, por si los tengo por algún sitio, pero mira tú también por la red que seguro que encuentras algo de esto que te digo, vale? Busca por MD5sum... o MD5 sólo...

Besotes
Elena

[cucaracha]

He estado ojeando lo que me habeis dicho. Como estoy algo liado, a partir de mañana me pondré más a fondo con esto...
En el manual de español que dejaron para Modbus....
De lo que he visto, creo que me quedo con el método LRC del Modbus, que parece el más simple y ocupará en memoria menos.
El CRC, con esas tablas, creo que se me va en memoria y mi aplicación no se lo puede permitir.
Corríjanme si lo he entendido mal...
El LRC lo que hace es una suma de todos los bytes que se envían y al final hace un complemento a dos del resultado. Ese sería el LRC que devuelve. Se haría los mismo en el receptor, sin incluir el LRC claro, y se comprobaría que coincide con el LRC recibido.
La suma la hace sobre un registro de tamaño 8bits, sin acarreo. Si éste se desborda empieza desde cero, osea si tengo 0xFF y le sumo 0x01 sería 0x00. Esta en verdad sería una suma erronea (debería ser 0x100), pero como el que recibe va a hacer lo mismo da igual (buena idea esta...). Osea, se hace esa criba.

Si a esto le añado la paridad, creo que sería más que suficiente no??

En cuanto a cambiar a Modbus... no soy yo el que decide eso. Entre otras cosa porque no soy el que modificará la aplicación del PC (que ya está hecha). Además sólo se conectará al PC una maquinita a la vez, y por lo que he ojeado, la ventaja de ese protocolo es poder conectar muchos a la vez, no??

Lo dicho, mañana me pongo con esto...

Saludos y muchas gracias a los dos!!

[pacalaconcurso]

no le hagas caso a Elena que se le fue el piano
je,je es broma... mira el CRC del modbus, tienes el calculo puesto en basic en ETE y son unos xor de nada.
esta bien el standarizar las cosas...

[cucaracha]

Si, se me olvidó comentar eso que dices...
Guardé ese código en basic en un txt, para manual de basic en mano, descifrar como lo hace ahí, ya que noté que no usa las tablas que te comenté ví en el manual del modbus.

A que te refieres por "está bien estandarizar la cosas"??

Saludos!!

[Elena2000]

Mira lo que hago con tu maestro Picachu, Felix::::



Tanto modbus, tanto modbus.... ni que te llevaras comisión.....

Vale, reconozco que es mejor opción para lo que quiere el bicho de Cuca.
Bye, pedorros.
Elena

[jorgeansuini]

Cuca:
Indudablemente el LRC es mas sencillo de entender que el CRC, y mas facil de implementar.-
Por otro lado el crc existen 2 formas de calcularlo, según un algoritmo que te da los resultados de esas tablas que viste, o,byte a byte .La diferencia es la velocidad (¿Con un micro a 20Mhz?) versus tamaño de memoria.-
Aparte de CRC y LRC, existe el checksum ,que es similar al lrc, solo que lo único que hace es sumar todos los bytes.-

De estos métodos,el más dificil de calcular es el crc, que si mal no recuerdo, se desarrollo no solo como control de errores sino tambien como corrector de los mismos, quizas en un archivo esto se pueda hacer, pero en los protocolos de transision de datos industriales, es mas sencillo verificar que hubo un error y si lo hubo,repetir la transmisión del dato.-
Saludos
Jorge

[cucaracha]

Si Jorge, creo que me voy a decidir por el LRC pero sin el final, osea, suprimiendo lo de devolver el complemento a dos de la "suma". Es decir, lo que devolverá la función será la "suma". El complemento a dos se usa también para detectar el errores, no? Y la verdad... si falla se envía de nuevo y listo.
Así que será más o menos lo que dices de ese otro CRC que sólo suma, pero con ese tipo de "suma" que hace el LRC (que no se si es la misma que en ese tipo que comentas).

Y que opinan de lo de añadir la paridad en el envío. Bastaría sólo con el LRC...

Saludos!!

[Ignite]

Como dice jorgeansuini  el LRC es más sencillo de comprender aunque el CRC tampoco es que sea muy complejo. Para un micro de 20Mhz casi mejor emplear el LRC ya que el CRC requiere de más cálculos. Ambos códigos son simplementes codigos detectores,pero si no recuerdo mal, si se producen muchos errores en una misma transmisión es posible que no se pueda detectar.
La utilización de un código u de otro depende de la tasa de errores que se produzcan.Si por ejemplo sabes que se producen pocos errores y no te importa volver a transmitir con uno de estos dos ya es suficiente. Por el contrario si sabes que se producen normalmente errores y no te interesa volver a retransmitir es más aconsejable emplear códigos detectores-correctores como puede ser el Hamming.
Ignite