Configurar Resistencias pull up en PIC16F628A por puerto

[Codrino]

Feliz año nuevo colegas!

Estaba en una cuenta regresiva pero no para recibir el año nuevo, sino para seguir trabajando jeeje.... y hasta ahora todo bien con las pruebas. Decidí mandar a fabricar el PCB. Gracias de nuevo por el apoyo recibido.

Sorpresivamente me llegó mucho antes el MCP41100 y me pondré a trabajar ya en la nueva versión. Espero poder avanzar ya que estoy programando en PIC BASIC PRO y de SPI no he encontrado nada claro hasta ahora, solo un par de videos en Ruso. Seguiré en mis labores. Slds.

 

[switchxxi]

Espero poder avanzar ya que estoy programando en PIC BASIC PRO y de SPI no he encontrado nada claro hasta ahora, solo un par de videos en Ruso. Seguiré en mis labores. Slds.

No programo en PIC Basic Pro, pero ¿ que es lo que no encuentras ?

Si es por funcionamiento, quizá te sirva: Protocolo SPI

Al menos esta explicado, como pude y lo mas simple posible, como funciona. Solo te queda trasladar del C al Basic el programa, ya que al no contar, el 16f628, con SPI por hardware lo tendrás que crear en software. (Y un tip para buscar en google, si te desenvuelves con el inglés, es usar las palabras bit-bang que es como llaman en inglés a realizar un protocolo de comunicación por software).

 

[Codrino]

Vale switchxxi lo revisaré. Si! eso estuve viendo. Hay que hacerlo a pedalazos línea a línea.

Hace algún tiempo me propuse a migrar de lenguaje, pero a falta de proyectos serios con PICs dejé la tarea en hold. Alguien que entiendo tiene un importante manejo de PIC me recomendó XC8 y bueno, creo que es el momento para iniciarme allí, pero tengo un pequeño problema, retengo muy poco la sintaxis de los lenguajes pasado algún tiempo, así que para solucionar esto, trato de tener una buena base de datos ordenada con ejemplos para invocarla cuando me trabo en los recuerdos; pero hasta ahora no he encontrado si no información muy parcial. Súper si quizá puedan recomendarme alguna fuente para iniciar mi estudio. Me sentiría muy bien si al final puedo migrar este último proyecto a través de XC8.

 

[Codrino]

El protocolo SPI parece ser sencillo de aplicar. Solo hay algo que no me quedó claro... Cómo sabré si pude enviar todo un Byte si el dispositivo SPI (en este caso el MCP41xxx) no devuelve datos para verificar esto?. No veo claro cómo se podría evitar o detectar un desplazamiento indeseado entre Bytes transmitidos (PIC) y Bytes de registro (MCP41xxx).

 

[Dr. Zoidberg]

Cómo sabré si pude enviar todo un Byte si el dispositivo SPI (en este caso el MCP41xxx) no devuelve datos para verificar esto?.

Si no hay realimentación desde el esclavo no hay forma de saber si el dato llegó bien o mal, y tampoco importa por que SPI es para comunicaciones en distancias muy cortas, por lo que el unico peligro de que llegue mal es que implementes mal el código de emulación. Una vez correctamente ajustado y en un entorno de aceptable nivel de ruido las probabilidades de falla/errores son prácticamente nulas.

 

[switchxxi]

Cómo sabré si pude enviar todo un Byte si el dispositivo SPI (en este caso el MCP41xxx) no devuelve datos para verificar esto?

¿ Como que no puedes verificarlo ? Enviás un dato al potenciómetro y mides para saber que la resistencia ha variado al valor que seleccionaste. Si es así, entonces el software esta manejando la comunicación correctamente.

 

[Codrino]

Dr. Zoidberg gracias.​

Entiendo entonces que un esclavo en SPI, supongamos una memoria, cuando esta se enciende, inicialmente espera a que se escriba el primer byte transmitido en su 1er registro byte, bit por bit y que el resto de registros se seguirán "llenando" bit a bit sin distinción de si se presenta algún desplazamiento no deseado (entre bytes). Esto es así?

 

[Dr. Zoidberg]

Definí "desplazamiento no deseado".
SPI es comunicación sincrónica, asi que no hay "desplazamientos".

 

[Codrino]

¿ Como que no puedes verificarlo ? Enviás un dato al potenciómetro y mides para saber que la resistencia ha variado al valor que seleccionaste. Si es así, entonces el software esta manejando la comunicación correctamente.

Pues cierto, jejej. he ahí la evidencia de que no había pensado lo suficiente...

Pero aún tengo esta duda: Si envío un Byte pero resulta que por cualquier razón no llega completo; El MCP41xxx esperará a que se complete el Byte para asignar un valor de resistencia o "llenará" los bits faltantes del registro con ceros y asignará un valor de resistencia...?

Mensaje automáticamente combinado: Ene 2, 2021

Definí "desplazamiento no deseado".
SPI es comunicación sincrónica, asi que no hay "desplazamientos".

Supongamos que deseo transmitir 2 Bytes. En el proceso pierdo un bit del primer Byte entonces el registro se termina llenando con el MSB más alto del segundo Byte. A esto llamo desplazamiento indeseado en una comunicación serial

 

[switchxxi]

Pero aún tengo esta duda: Si envío un Byte pero resulta que por cualquier razón no llega completo; El MCP41xxx esperará a que se complete el Byte para asignar un valor de resistencia o "llenará" los bits faltantes del registro con ceros y asignará un valor de resistencia...?

El chip no es inteligente y aun así lo fuera no puede, o mejor dicho, no debería hacer nada con un dato que no sabe que es y si es valido.

Sin embargo si que es medio inteligente. Habría que ver el datasheet pero normalmente si no recibe un byte completo, después de un tiempo, lo descarta y no hace nada con ese dato "corrupto".

Por otro lado tienes el CS que "resincroniza" la comunicación.

Obvio que puedo estar olvidándome algo y cometiendo algún error, por eso siempre es mejor preguntarle al fabricante que es el que mas sabe (Datasheet).

 

[Codrino]

El chip no es inteligente y aun así lo fuera no puede, o mejor dicho, no debería hacer nada con un dato que no sabe que es y si es valido.

Sin embargo si que es medio inteligente. Habría que ver el datasheet pero normalmente si no recibe un byte completo, después de un tiempo, lo descarta y no hace nada con ese dato "corrupto".

Por otro lado tienes el CS que "resincroniza" la comunicación.

Obvio que puedo estar olvidándome algo y cometiendo algún error, por eso siempre es mejor preguntarle al fabricante que es el que mas sabe (Datasheet).

Con lo que me han aportado hoy, lo veo más claro (esta mañana no podía ver a más de un metro) creo que podré avanzar con algunas pruebas y revisiones. Les estaré contando... tengan un buen resto de día.

 

[Codrino]

Hola switchxxi, parecía sencillo pero me tomó más tiempo del esperado. Hoy comencé a trabajar desde las 8 de la mañana y en mi zona horaria ya es media noche. Hace como media hora logré configurar la comunicación SPI en Pic Basic Pro. Moraleja: Ver menos videos genéricos peo sí revisar bien el Datasheet.

Los videos genéricos (al igual que algunos tutoriales escritos) presentan la comunicación SPI de forma genérica, es decir, indican que solo se envía un Data Byte y listo, pero para el caso del MCP41100, se requiere de un Command Byte previo, lo que en conjunto constituyen 16 bits continuos. No se pueden enviar 2 Byte, ya que dispositivo espera que se complete una palabra de 16 bits para poner a funcionar el MCP. Es como indicabas; hasta no completar el registro el dispositivo SPI no ejecuta nada.

...Y vaya que ahorro implementar el MCP. Me gusta; tiene buena resolución, es diminuto y barato. Seguiré dándole forma a esto y les comento cómo me termina de ir. Gracias!

 

[switchxxi]

Moraleja: Ver menos videos genéricos peo sí revisar bien el Datasheet.

Es un arma de doble filo, hay mucha información pero nadie dice que toda ella sea correcta. Cada vez mas, buscar se convierte en un arte.

A mi me paso tratando de compilar un driver para una placa de vídeo en linux hace siglos atrás. Sin saber, yo solo seguía pasos, pero después del quinto intento y ya sabiendo que todos los tutoriales eran un copy/paste a los que algunos obviaban incluso pasos, decidí empezar a buscar información de que hacía cada cosa.
Resumen: En uno de los pasos se ejecutaba un comando que apagaba/deshabilitaba el video 3D o algo así. Entonces pensé ¿ Hay forma de activarlo/habilitarlo ? y si, la había y en ningún tutorial lo hacían.
Perdido por perdido lo intente, ejecute el comando para comprobar que había aceleración 3D y efectivamente, ese paso era importantísimo.

Como había dicho antes, no confíes en nadie salvo en el fabricante (ojo, aunque si bien es raro, puede cometer algún error).
Una de las cosas que me quedo grabada en la cabeza fue cuando un profesor dijo: El fabricante no miente, omite.

Los videos genéricos (al igual que algunos tutoriales escritos) presentan la comunicación SPI de forma genérica, es decir, indican que solo se envía un Data Byte y listo, pero para el caso del MCP41100, se requiere de un Command Byte previo, lo que en conjunto constituyen 16 bits continuos.

Normalmente yo programo en ensamblador, de todas formas los programas que he hecho fueron simples. Pero eso te obliga siempre a programar con el datasheet en la mano.

No se pueden enviar 2 Byte, ya que dispositivo espera que se complete una palabra de 16 bits para poner a funcionar el MCP. Es como indicabas; hasta no completar el registro el dispositivo SPI no ejecuta nada.

Después me di cuenta, es una comunicación sincrónica, el chequeo de datos no va a ser por tiempo, eso puede pasar en comunicaciones asincrónicas.

 

[Codrino]

Vaya sí... toda una odisea si no se es suspicaz y como dices, todo un arte eso de buscar en medio de cada vez más información y no necesariamente la mejor...

El fabricante no miente, omite. Tal cual...

 

[Codrino]

Colegas quizá tengan una respuesta para una duda que me surgió volviendo al tema de poner los pines del PIC en alta impedancia:

Los comandos para escribir en los registros TRISA y TRISB usualmente quedan ubicados al inicio de cada programa, pero si en cambio tal instrucción se ejecuta indefinidamente dentro de un loop en donde se reescriben sus registros alternadamente entre entradas y salidas; Podría esto en algún momento dañar los registros TRISx? o Poseerá la misma capacidad para aguantar cambios alternados como los PORTx?

Nada indica que tengan diferencias operativas... pero me gustaría conocer sus opiniones.

 

[ricbevi]

No hay problemas de invocar el Tris puerto cuantas veces quieras...se hace habitualmente al inicio o ante un cambio de función entrada/salida de un port y/o pin especifico.

Recuerdo haber usado algo así en una alarma que en un momento el pin era usado como entrada del sensor y en otro como señal de salida de una comunicación serie y no hubo problema alguno.

 

[switchxxi]

Podría esto en algún momento dañar los registros TRISx? o Poseerá la misma capacidad para aguantar cambios alternados como los PORTx?

Solo se habilita o deshabilita los transistores de salida (si se explica con simpleza) con esas instrucciones. Así que no, puedes cambiar el puerto una miles de veces por segundo que no va a pasar nada.

Pero ! OJO ¡ si el pin esta como entrada, se pasa a salida y la señal externa aun sigue presente en el pin (Por ejemplo si hay otro dispositivo y no se espero el tiempo necesario para que este ultimo pase a alta impedancia) puede aparecer un corto dependiendo del valor de las dos salidas confrontadas.

 

[Codrino]

No hay problemas de invocar el Tris puerto cuantas veces quieras...se hace habitualmente al inicio o ante un cambio de función entrada/salida de un port y/o pin especifico.

Recuerdo haber usado algo así en una alarma que en un momento el pin era usado como entrada del sensor y en otro como señal de salida de una comunicación serie y no hubo problema alguno.

Gracias ricbevi

Mensaje automáticamente combinado: Ene 6, 2021

Solo se habilita o deshabilita los transistores de salida (si se explica con simpleza) con esas instrucciones. Así que no, puedes cambiar el puerto una miles de veces por segundo que no va a pasar nada.

Pero ! OJO ¡ si el pin esta como entrada, se pasa a salida y la señal externa aun sigue presente en el pin (Por ejemplo si hay otro dispositivo y no se espero el tiempo necesario para que este ultimo pase a alta impedancia) puede aparecer un corto dependiendo del valor de las dos salidas confrontadas.

Gracias. Por fortuna no tendré ese tipo de problema ya que los puertos estarán al aire (en alta impedancia) y en nivel bajo (cuando estén como salidas). Utilízare esta función para manejar un teclado matricial sin resistencias externas, solo las pull-ups internas del PIC. No soy experto en este tipo de teclados y tampoco he encontrado cómo hacerlo sin utilizar resistencias externas. Pero alternando el TRISx creo que lo haré (a mi manera). Probare y les comentaré.

 

[Codrino]

Bueno, simulando en Proteus me ha funcionado bien la matriz de teclado. Lo estaré montando en físico para probarlo un largo rato.

 

[Codrino]

No logro apagar del todo al MCP41100 mientras el resto del circuito permanece encendido.

Cuando se inicia el programa, la resistencia tiende a infinito, pero una vez selecciono un valor resistivo y sale de la rutina, comienzo a medir valores oscilantes superiores al nominal.

Revisiones hasta ahora:

- Se descarta ruido.
- Se reemplaza el MCP41100 (por otro igual).

- Debido al bajo consumo del MCP41100 (500uA), controlo el encendido y apagado a través de un pin del PIC. Cuando pongo el pin en nivel bajo, me arroja 0,92 V. Si lo desconecto del MCP, entonces mido 0V (como es de esperarse). Y ahora, estando al aire el pin Vdd en el MCP mido 4,6V. Me pregunté, de dónde sale ese voltaje?? Entonces caí en cuenta que en estado de reposo (en el programa) el pin CS (Chip Select) del MCP está en alto y pensé en ponerlo en nivel bajo y de esta manera hacer desaparecer los 4,6V del Vdd (al aire) en MCP (puesto que el resto de pines del MCP permanecen en nivel bajo mientras el programa está en reposo).

En resumen, así intenté apagar el MCP:

Nivel bajo en Vdd para desenergizarlo.
Nivel bajo en CS para quitar el voltaje indeseado en Vdd al aire.

Entendí que haciendo esto, podría apagar del todo el MCP, pero no fue así.... ... sigo midiendo valores oscilantes superiores al nominal.

Ahora me varé... lo dejaré en stand bye, mientras se me ocurre otra cosa.

Se me ocurrió apagar el potenciómetro con el siguiente seteo de bits en el Command Byte según Datasheet, pero lo que hizo fue darle el valor resistivo más bajo (160 ohm). Lo que necesito es poner la salida del MCP en alta impedancia.



Seguiré revisando el Datasheet...