Comunicacion con un sensor optico ADSN2620

[golumx]

Buenos dias, aunque no soy prolifico en la escritura en el foro, si lo sigo asiduamente. Os comento, me encuentro bloqueado con la comunicacion entre un PIC y este sensor. Llevo tiempo intentandolo, pero no consigo evolucionar. Este sensor establece una comunicacion serie y yo deseo emplear el modulo MSSP que incorporan algunos PIC y el protocolo I2C, creo que es el camino apropiado pero no se me ajusta completamente a las caracteriaticas de este modulo. Yo configuro el MSSP para que me funcione como master ya que el ADSN2620 solo funciona como esclavo, sin Ack, pero la señal de sincronizacion no se ajusta al modo de funcionamiento  del sensor, cuando envio el byte del registro, la señal de reloj me hace 9 oscilaciones en vez de 8, ya que aunque no envia el bit de Ack  si genera la señal de reloj de este, ademas entre la escritura del registro del que quiero obtener los datos y la respuesta han de pasar un minimo de 100us, pero con la señal de sincronizacion en nivel alto y se me queda en nivel bajo durante la pausa. Ademas me vuelve a generar la señal de sincronizacion para el Ack de respuesta, que no es generada por el ADSN2620 y este lo interpreta como el MSB del siguiente registro a leer (como la linea SDA esta 0, lo interpreta como que quiero leer el siguiente registro). Estoy utilizando el CCS y un 16F886 ya que comence con un 16F88 pero este PIC solo dispone del modulo SSP y lo simulo en proteus por que solo tengo un 16F886 en formato SOIC y quiero reservarlo para el montaje en la placa con el ADSN2620 (si consigo que en la simulacion las señales sean correctas). Tambien he intentado programar las señales apropiadas con delays, bucles y condicionales pero durante la ejecucion del codigo se producen desfases que no lo hacen apropiados. ¿Como he de configurar el pic para que no me genere la señal de reloj del Ack y se matenga esta en nivel alto durante la espera de la respuesta?

[AngelGris]

  No he trabajado mucho con I2C, solo un un par de sintonizadores de TV, algún potenciometro digital y varias memorias y en todos los casos existía el pulso de ACK. Si no me equivoco, justamente en las especificaciones del bus I2C indica que debe existir el pulso de clock para dicho bit y que el dispositivo debe responder con ACK o NAK siempre. No puede no existir dicho pulso.

  Estoy mirando un poco rápido el datasheet del sensor y el protocolo se parece mucho más a SPI en lugar de I2C

[golumx]

Muchas gracias por tu rapida respuesta, a mi me parecio lo mismo ,dentro de mi ignorancia en protocolos de comunicacion, pero lo que me aprto de la idea del SPI es que emplea la misma linea para la lectura y escritura y no he encontrado nada acerca de como he de configurar el SPI para que emple una linea de datos (lectura y escritura) y otra para la sincronizacion, por eso pense en el i2c en vez del SPI, es mas tras poner el mensaje en el foro he empezado a investigar el MBUS..... pero sigo igual....

[AngelGris]

 Fijate que en el datasheet muestra como del pin del dispositivo va una conexión al pin SDI y otra al SDO del microcontrolador.

[golumx]

Me acabas de descubrir el mundo..... ese detalle se me habia pasado, vamos, la verdad es que crei que eso no se podia hacer con un PIC, voy a probar y cuento te cuento como me va. Muchas gracias.

[golumx]

Pues una vez probado el SPI para la comunicacion con este sensor sigo igual, la generacion de los pulsos es correcta, una cadena de 8 oscilaciones del SCL sincronizada con el SDA, cuando termina el envio del byte de lectura del registro al que quiero acceder se queda la linea de reloj en nivel alto durante los 100us que necesita, pero aqui vienen los peros, ¿pasados los 100us no deberia generarse otra cadena de 8 pulsos para recibir el byte del registro llamado?, a mi no me genera nada ni simulandolo en proteus ni en la protoboard. Para montarlo en la protoboard he empleado un 16F88 que segun la hoja de datos tiene hardware SPI. De monento solo he probado la opcion del SPI por hardware, mañana me pondre con la simulacion por sofware......

[AngelGris]

Pues una vez probado el SPI para la comunicacion con este sensor sigo igual, la generacion de los pulsos es correcta, una cadena de 8 oscilaciones del SCL sincronizada con el SDA, cuando termina el envio del byte de lectura del registro al que quiero acceder se queda la linea de reloj en nivel alto durante los 100us que necesita, pero aqui vienen los peros, ¿pasados los 100us no deberia generarse otra cadena de 8 pulsos para recibir el byte del registro llamado?, a mi no me genera nada ni simulandolo en proteus ni en la protoboard. Para montarlo en la protoboard he empleado un 16F88 que segun la hoja de datos tiene hardware SPI. De monento solo he probado la opcion del SPI por hardware, mañana me pondre con la simulacion por sofware......

  No se como serán las funciones en CCS pero la idea sería algo así

Código: C

1. write_spi(algo); // imagino que hay que indicar el registro que se quiere leer
2. espera de 100 us
3. dato = read_spi();

  Primero enviamos la dirección del registro que queremos leer y luego hay que hacer una lectura sobre el bus.

[golumx]

Es esactamente lo que hago, primero escribo la direccion del registro al que quiero acceder, hago una pausa de 100us y leo la respuesta, pero no genera la señal de reloj, por lo que no hay respuesta....

configuracion de modulo SPI
setup_spi(SPI_MASTER|SPI_H_TO_L|SPI_CLK_DIV_64|SPI_XMIT_L_TO_H);

sentencias empleadas para la escritura-lectura
spi_write(0x43);
delay_us(100);
deltaX = spi_read();

tambien ha probado sin el delay_us(100) y con  deltaX = spi_read(0x43); pero en el osciloscoio (ni en el virtual del ISIS ni fisicamente) se genera la señal de reloj para la lectura......

[golumx]

Nada ni configurando el modulo por sofware ni por hardware obtengo la señal de reloj para la lectura. ¿Que estoy obviando? No lo entiendo, el segundo tren de pulsos deberia generarse aunque no hubiera nada conectado y no hubiera respuesta ¿no? ¿si no como se va a sincronizar la respuesta?

[golumx]

Pues ya lo tengo solucionado, como la mayoria de las veces, falta un pequeño detalle, una vez enviada la direccion de lectura spi_write(direccion),hacia la pausa de 100us y procedia a la lectura del byte contenido en la direccion enviada, pero no lo hacia correctamente por que no se lo indicaba correctamente, en el codigo que no funcionaba tenia escrito dato=spi_read() y la forma correcta es dato=spi_read(0). Esta pagina ha sido la que me ha guiado al buen camino:

http://www.wikiteka.com/apuntes/gestion-del-bus-spi-desde-c

una muy buena explicacion de como ha de configurarse el modulo SPI.
Aunque aun me tiene un poco desconcertado la cantidad de paginas que he consultado y dicen que es comunicacion I2C......

[AngelGris]

  Me alegro que funcione. Yo utilizo XC8 como compilador y sólo tiene librerías para la familia 18F así que me puse en la tarea de hacerme una librería SPI para poder probar algo y comentarte que conseguía, que bueno que ya te funciona.

  Tal vez haya dos versiones de dicho sensor... o son simples errores de quienes comentan al respecto.

[golumx]

 Por lo que he visto la mayoria de estos sensores son SPI y tienen una forma de trabajar muy similar, cambiando los registros y algo de los tiempos, solo he encontrado uno I2C de ST que ya no esta disponible.
Aun que no tiene nada que ver con el tema, ¿con que se programan los 16F si el XC18 solo es para 18F? siempre habia pensado que el compilador de microchip era para todos los de 8bits.
Muchas gracias por dedicarme tu tiempo, es muy reconfortante no sentirme tan solo y un poco de ayuda o una orientacion anima mucho a seguir, pero aun no ha conseguido extraer los datos del sensor, solo ha conseguido que me envie correctamente la direccion del registro deseado y genere el tren de pulsos para la respuesta, el siguiente paso es entender como procesar estos datos.
Gracias, seguire comentando mis avances y errores.

[AngelGris]

Por lo que he visto la mayoria de estos sensores son SPI y tienen una forma de trabajar muy similar, cambiando los registros y algo de los tiempos, solo he encontrado uno I2C de ST que ya no esta disponible.
Aun que no tiene nada que ver con el tema, ¿con que se programan los 16F si el XC18 solo es para 18F? siempre habia pensado que el compilador de microchip era para todos los de 8bits.
Muchas gracias por dedicarme tu tiempo, es muy reconfortante no sentirme tan solo y un poco de ayuda o una orientacion anima mucho a seguir, pero aun no ha conseguido extraer los datos del sensor, solo ha conseguido que me envie correctamente la direccion del registro deseado y genere el tren de pulsos para la respuesta, el siguiente paso es entender como procesar estos datos.
Gracias, seguire comentando mis avances y errores.

  El compilador anterior de microchip se llamaba C18 y efectivamente era para los 18F. Actualmente existen tres compiladores: XC8 que es para todos los micros de 8 bits (10F, 12F, 16F y 18F), XC16 que es para los de 16 bits (24F, dsPIC30, dsPIC33) y XC32 que es para los de 32bits.

[golumx]

Mi sensor ha muerto, o ya estaba muerto, es el problema de reciclar..... tendre que hacerme con otro para seguir practicando.

[golumx]

Buenos dias, vuelvo a la carga, aun no he conseguido otro sensor optico que funcione correctamente, pese ha haber desmontado unos ratones viejos que tenia, pero me surge una duda existencial, creo que tengo un grave error de concepto en cuanto al uso de los distintos tipos de variables, en concreto como emplear los bytes con signo (-128,127). No entiendo como calcular el incremento de distancia que me devuelve el sensor, segun la hoja de datos el byte almacenado en el registro del incremento de X e Y es del tipo complemento a dos, pero por mas vueltas que le doy no termino de enterarme como operar con estos datos, por ahora me he enterado por la wikipedia que es la forma de operar con numeros negativos en binario, pero no llego a mas. ¿Como deberia operar  con este tipo de datos para obtener el desplazamiento en mm?