:Ayuda Descifrar codigo serial

[Lrios2019]

Buenas tardes colegas, antes que nada agradezco el formar parte de este foro ya que desde hace tiempo he leido sus respuestas a varios problemas que han surgido aquí y me han ayudado bastante en aprender c y asm para pics.
Me surgió un proyecto teóricamente "sencillo" les explico un poco de lo que trata tengo una tarjeta vieja la cual manda mensajes a un display LCD el cual ya esta descontinuado entonces busco adaptar uno nuevo, la tarjeta de control encargada de mandar códigos tiene un integrado m82c51-a2 y a la salida de este una compuerta NOT(con esto se que solo envía y no recibe datos) y el display tiene a la entrada una compuerta NOT y a la salida un integrado z86c91, cabe destacar que las compuertas las puedo eliminar ya que  al mandar datos el emisor la compuerta NOT de salida niega datos y el receptor vuelve a negar los datos de entrada, leyendo las hojas de datos del ms82c51(emisor) me dice lo siguiente: es un usart configurable de 5 a 8bits,bit de inicio de 1,1.5 y 2 con la posibilidad de agregar paridad par e impar y algo importante puede llevat bit de stop o no, el receptor que es el z86c91 es un microcontrolador sin indagar tanto recibe solo 8  bits con bit de stop y de paro. Ahora lo mas importante desconozco todos estos datos y es el reto que he tenido desde hace unas semanas, el planteamiento del problemas es el siguiente:
-Conocer la cantidad de bits en la transmisión
-Conocer la velocidad de transmisión
-Tratar de descifrar la cantidad de bits mandado
Estudiando el protocolo rs232 con la ayuda de proteus y pics llegue a la conclusión de que necesito tres programas en este orden:
-Un programa para leer la cantidad de flancos de bajada en un dato
Esto es con el fin de leer todos los tiempos sin perder alguno ejemplo:
La linea de comunicación siempre es a 5v si mando la letra e en código ascII seria 1100101 agregando los bits de stop y star seria asi 011001010, el pic me lee el numero de flancos de bajada en el dato y si le resto 1 a esta cantidad me da la cantidad aproximada claro del numero de 1 quedando de la siguiente forma: 4 flancos de bajada y 3 flancos positivos dentro de ese numero, esto se cumple con todos los caracteres sin excepción.
-El segundo programa que realice lo hice con interrupcion externa funcionando de la siguiente manera:
Cuando mando un carácter por rs232 la interrupción del pic me detecta un flanco descendente y cuento con ayuda del timer 1 el tiempo que permanece en estado bajo y alto de todos los caracteres enviados y estos caracteres serian la cantidad de flancos que detecte anteriormente 4 flancos de bajada y 3 de subida en total 7 tiempos,con estos tiempos puedo definir la velocidad de transmisión y la cantidad exacta de unos y ceros dentro de ese dato. Por ejemplo mandando la letra e el tiempo mas pequeño es de 9979 ticks usando el pic18F4550 a ,0.0833 us * tick si lo multiplicamos 9979ticks*0,0833us=831.2us =0,831.2ms un aproximado de 1200 baudios, esto lo comprobé con distintos tiempos y en todos se aproxima, volviendo a la tarjeta y aplicando esto llegue a lo siguiente:
-La tarjeta manda un total de 6 flancos de bajada y 5 de subida dentro de la transmisión.
-Midiendo los tiempos tengo que el mas pequeño es de 9999 ticks por lo que puedo decir que es a 1200 baudios.
-El dato en binario que logre sacar es el siguiente junto con los tiempos espero no hacerlos bolas ya que reconozco no soy bueno explicando, estos datos son consecutivos y van en el orden que los escribo:
Primer flanco 14448 ticks este es un flanco de bajada=0
Segundo flanco 64814 ticks este es un flanco de subida=1
Tercer flanco 9999 ticks este es un flanco de bajada=0
cuarto flanco 19999 ticks este es un flanco de subida=1
quinto flanco 19999 ticks este es un flanco de bajada=0
sexto flanco 50009 ticks este es un flanco de subida=1
septimo flanco 9999 ticks este es un flanco de bajada=0
octavo flanco 19999 ticks este es un flanco de subida=1
noveno flanco 9999 ticks este es un flanco de bajada=0
decimo flanco 29999 ticks este es un flanco de subida=1
onceavo y ultimo flanco 9999 ticks este es un flanco de bajada=1
y aqui la linea permance en 5v, con estos datos y dividiendo el tiempo menor de los ticks entre todos obtuve este codigo:
0111111011001111101101110
las conclusiones hasta ahora son que el tiempo es aproximadamente de ,833ms por bit aun no puedo estar seguro de el numero de bits*dato y el tercer programa que necesito es para verificar la información solo que aqui estoy atorado ya que yo debo de mandar ese codigo con los tiempos exactos para que el receptor los lea casi igual que el emisor, esto lo he resuelto de las maneras mas burdas como por ejemplo cambiando el estado logico de una salida del pic simulando los datos y dandole un delay de us simulando los tiempos, ha funcionado algunas veces ya que he podido ver el mensaje que manda la tarjeta original en el display pero solo algunas veces ya que los delays y las instrucciones no son tan precisas con el tiempo, otra que he intentado es mandar los 16 bits por el puerto serie del pic obviamente esto no sirve ya que recibo informacion muy extraña, espero puedan apoyarme es un tema bastante complejo, cualquier aporte lo agradeceria bastante, dejo mis programas por si le interesan a alguien y para los que quieran apoyarme, muchas gracias.

[Robert76]

Hola, pregunta. Que función cumple la tarjeta?
Porque quizás sea a la larga más simple cambiar tarjeta junto con el display que quieras.

[Lrios2019]

No existe la posibilidad dado que la tarjeta requiere códigos por servidor, de hecho esa era mi primer idea pero por lo visto seria mucho mas complejo descifrar todos los datos recibidos, lo que he tratado de realizar es sacar el "estandar de datos", ya tengo la velocidad de transmisión y ayer me di cuenta de que la tarjeta manda dos mensajes el primero de bienvenida es este codigo:
011001111101011110
y al cambiar el mensaje mostrado en la pantalla recibo este código
011001111101101110
viendo los codigos y mandando los decimales por el puerto serial tengo estos caracteres s; para el primero s= para el segundo el problema es que en ambos me falta uno ya que la s es 011001111 y el ;01101110 si los junto me dan 01100111101101110 faltando un 1 para completar esa cadena de caracteres entonces cuento con dos opciones configurar un pic del pic para leer el flanco de baja e ir sumando los bits simulando la comunicacion r232 pero con 16 caracteres.

[Lrios2019]

la otra idea que tengo es usar el rs232 pero modificado sin bit de stop pero por lo que he leido no es opcional en los pic

[Eduardo2]

La linea de comunicación siempre es a 5v si mando la letra e en código ascII seria 1100101 agregando los bits de stop y star seria asi 011001010,

Ojo con esto porque no es asi. En una comunicación serie normal los bits de start y stop son siempre diferentes:

viendo los codigos y mandando los decimales por el puerto serial tengo estos caracteres s; para el primero s= para el segundo el problema es que en ambos me falta uno ya que la s es 011001111 y el ;01101110 si los junto me dan 01100111101101110 faltando un 1 para completar esa cadena de caracteres

Asumiendo que el stop bit es 1 y considerando que el 1er bit es el LSB y la comunicación es 7bit paridad par, te queda :

0 11001111 1 0 1011110  =  StartBit - 0x73(0xF3 por la paridad) - StopBit - StartBit - 0x3D = "s="

0 11001111 1 0 1101110  =  StartBit - 0x73(0xF3 por la paridad) - StopBit - StartBit - 0x3B = "s;"

Falta  el '1' final de la paridad y el stopbit final ('1'), pero eso es una limitación de la rutina de medición porque no vas a tener flanco descendente hasta el siguiente dato.

[Lrios2019]

Buscando mas pantallas en la tarjeta encontré una tercera la cual seria con este código:
011001111 100011110
el primer byte borra la pantalla el segundo es el de la dirección del mensaje a mostrar, con respecto a tu respuesta me queda claro aunque siguiendo la teoría yo debería de mandar esos caracteres por el puerto serial esperando leer en la pantalla el mensaje que debería de mostrar cosa que no hace aunque dudo por la estructura del integrado que recibe esos datos tenga algún truco.
Ahora bien probando con un conversor usb-ttl con la configuracion que mencionas paridad par y 7 bits el mensaje que recibo de la tarjeta es el siguiente:
?s?=??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????s?;
con cualquier paridad es igual, cuando yo quito la paridad y quedando la comunicacion asi paridad N y 7bits si recibo los datos correctos.
Aunque sigo teniendo la duda, del porque con paridad no me llega el mensaje como teoricamente deberia y la duda que tengo como te comento es con el panel al mandar estos datos por el puerto serie no muestra nada, excepto cuando programo un puerto del pic como salida y simulo mandar los bits poniendo en bajo y alto el pin del pic con un delay de microsegundos algunas veces logro ver en la pantalla los mensajes.
Otra cosa que puede ser es que mi conversor usb ttl no me respete la paridad o este configurandolo mal por ejemplo 7 bits+paridad=8 bits, ya que hasta en simulaciones recibo codigos extraños con esto 

[Lrios2019]

Probando la comunicación como dijiste ya me leyó datos el panel aunque tal parece ser que tiene una rutina de inicializacion con el 255 o espacio dando lo siguiente
mando espacio y "comienza a leer datos"
puedo mandar el dato que tengo ya leído anteriormente y el display lo muestra, en cualquier caso supongo que los códigos que use sirven para descifrar el código serial sin tener ninguna información, muchas gracias por tu ayuda Eduardo, felices fiestas.

[Lrios2019]

Dos ultimas preguntas sabes como evitar esos signos de interrogacion?, ya que pienso que cuando programe el pic recibire mucho codigo basura y puede estropear los avances, y la otra respecto a la ultima pantalla que recibi deberia de mostrarse con s< o 011001111100011110 sin embargo en la terminal recibo esto s?<, hay alguna manera de recibir los codigos con el pic sin tantos signos de interrogacion ya que por lo visto son espacios o 11111111 que manda la tarjeta de control

[Eduardo2]

El signo entre 's' y '<'  es un código inválido, y los demás andá a saber,  analizando tan pocos datos no podés avanzar gran cosa.
El formato también podría ser 7-N-1 , 7-N-1.5 o 7-N-2  pues entre el bit de stop y el siguiente de arranque puede ser cualquier intervalo. 
Ya que por lo menos conocés el baudrate, no se si habrás probado con las diferentes combinaciones de longitud de datos, paridad y parada.

Con conversores USB-TTL he tenido problemas, el particular con un control FANUC que transmite 9600-7-E-1  no hubo caso y la unica solucion fue configurar 9600-8-N-1 y el bit de paridad crearlo/limpiarlo por software.

[Lrios2019]

Muchas gracias, tienes razon ya programe el pic a 7 bits sin paridad y el problema de los caracteres invalidos lo solucione con una sentencia if, tal parece ser que si podre adaptar otro panel ahora solo quedaria buscar informacion del controlador para el t6963c y algunas rutinas de inicializacion, por aqui he visto algo, te lo agradezco mucho.