hola cfede1984 muy interesante y util lo q hiciste con la comunicacion Te felicito. Pero antes de ir tan lejos recien estoy tratando de realizar la lectura y mostrarla en un display. Vos le entendes a la logica que sigue el programa grabado en el pic? Si es asi me gustaria hacerte unas consultas ya que no logro ver el valor correcto de la medida en el lcd. Por ejemplo cuando el calibre voy aumentando la medida en incrementos de 0,01 en el lcd visualizo incrementos de 1 en 1. Pero el problema aparece cuando llega al valor 0.09 en el calibre, en vez de pasar en el lcd de 9 a 10 coomienza de nuevo en 0. Pongo el codigo en ccs abajo por si alguien me puede dar algunas indicaciones de lo q este haciendo mal
...
Espero la colaboracion de alguien jajaj. Saludos
Hola Lucas! Una mano no se le niega a nadie. Primero que nada, vamos a dejar en claro algunas cosas.. Abramos el png adjunto. Puse un ejemplo midiendo 0.00 y otro con 0.01 mm. Los datos que sirven son los marcados en verde en el diagrama. (Cambie el modo operativo de la interface desde la misma terminal (en este caso CuteCom) para que transmita TAL CUAL LO QUE RECIBE -mas un byte de inicio mas un byte de checksum atras-) Resumiendo:
Violeta: Un byte de inicio generado por el PIC, no sirve para nada porque no lo genera el calibre.
Azul: 3 bytes absolutos, los genera el calibre pero no son utiles.
Verde: 3 bytes de posición relativa, son lo que tenes que utilizar!!!
Rojo: checksum ES GENERADO POR EL PIC no por el calibre, no sirve para nada.
Entonces a lo que voy, es que necesitas hacer algo equivalente con tu programa, tratar de leer los bytes tal cual y una vez que nos aseguramos que esto ESTA OCURRIENDO BIEN despues nos abocamos a transformar la data. Claro que esto implica multiplicar por 127/1024 para los mm al valor de los 3 bytes verdes y corre el punto dos lugares, o sea dividir por 100 en la practica.
Un detalle que quiero que se entienda, veras que pese a que el valor es 0.00 hay lecturas DIFERENTES. Esto es normal porque el calibre te esta transmitiendo info para armar muchos mas decimales que los que te muestra en pantalla. Sin embargo errores de todo tipo hacen que ese ultimo byte quede oscilando sin efectos a la hora en que transformamos los datos y truncamos el numero a una cantidad estable.
Otra cosa que te queria preguntar es si probaste conectar un analizador logico a la senal acondicionada a 5V del calibre, solo para asegurarte que esta todo bien conectado y los cables y formas de onda bien identificados. Te adjunto tambien una captura de esta hecha con el Pickit 2 Clone.
Repasando el ASM, tenemos el inicio de la lectura del calibre en la linea 479 clocksync, ahi busca una senal de clock con cierta longitud minima, y recien ahi cuando sabemos cuando va a terminar porque nos cercioramos con el analizador cuanto mide ese clock inicial, ahi nos mandamos con un bucle de alta velocidad a capturar los 3 bytes absolutos, totalmente inutiles para nuestro fin, despues esperamos el clock largo del medio con igual tecnica y nos largamos de nuevo por los 3 bytes utiles.
El resto es transformar los datos.
Por lo que mi recomendacion seria que trates de capturar esos bytes verdes como sea, si queres los azules tambien, y empezar a mostrarlos en la pantalla del LCD. Ahi si no se si se van a transformar en ASCII o que porque nunca me intereso su manejo.
Respecto a tu programa, te recomiendo ponerle algunos comentarios, pero creo que entiendo que queres hacer y creo que se lo que pasa.. la variable DATO son dos bytes de 8 bits, pero el calibre te transmite TRES bytes de 8 bits. Aparentemente vos con la interrupcion activas el mecanismo de lectura, esperas delay_us(494); y ahi te enterras hasta un punto que cae dentro de la lectura de los 2 ultimos. Vos deberias aterrizar en el clock alto del medio (ver timing.pdf) y leer los TRES BYTES para despues analizar cual es el numero. Porque medida NO ES IGUAL A dato/10 ES IGUAL A DATO (De 24 bits) / 1024 * 1.27 (Entiendo que la linea esta comentada con //)
Desconozco como es el manejo de los 16 bits que hace C, puede que la cosa venga por aqui.. de paso, con 16 bits tenemos como maximo 81.27 mm (2^16 /1024 *1.27)
Otra idea, casi siempre los compiladores de C permiten mandar ASM en el medio. Porque no pegar las rutinas de lectura y despues retomar con C a la parte feliz de mandar la data de la ruptura al LCD?? Si o si tiene que ser un dispositivo independiente? No puede una PC capturar diferentes datos en serie y graficar como se produce la ruptura??
Abrazo,
Federico
p/d: La semana proxima subo fotos al blog, para que se entienda que quise hacer..
