Extraño comportamiento de pin con pic16f88

3

He estado aprendiendo (intentando al menos) cómo trabajar con microcontroladores pic, y he notado este comportamiento que no estoy seguro de si es solo mi culpa o se supone que suceda. Escribí el siguiente programa con la esperanza de hacer un parpadeo. Parpadea muy bien cuando está conectado al pin etiquetado como RA2, pero cuando conecto el led al pin 15 (etiquetado como RA6 / OSC2 / CLKO en la hoja de datos) el led permanece encendido, como si lo hubiera conectado a Vdd. Luego, cuando lo vuelvo a colocar en RA2 donde pertenece, se apaga. La única manera de volver a encenderlo es conectando una resistencia de 10k entre Vdd y MCLR (como en la programación). ¿Que está sucediendo aquí? MCLR también es necesario cuando lo tocas en otros pines. ¿Estoy causando daño?
El circuito tiene 3 baterías AA que alimentan la imagen, con una resistencia de 330 y un led de 3 mm en serie desde el pin 1 (RA2) al pin 5 (masa).
pic16f88 datasheet
Código:

#include <xc.h>

__CONFIG(MCLRE_ON & CP_OFF & WDTE_OFF);

void main(){

    TRISA = 0x0000;
   // RB6 = 0b000010;
    for(;;){
        RA2 = 1;
        Wait();
        RA2 = 0;
        Wait();
    }
}
int Wait(void) // gives me a delay of 1/3rd a second or so
{
for (int i = 0; i < 50; i++)
 {
 }
}
    
pregunta a sandwhich

3 respuestas

4

Es necesario atar el pin MCLR alto durante la operación normal, de lo contrario el chip se mantendrá en reinicio. Observe la barra sobre MCLR, esto significa que es active low .
Utilice una resistencia entre MCLR y Vdd de alrededor de 10kΩ (< 40kΩ)
Ver p.132 / 133 de la hoja de datos.

    
respondido por el Oli Glaser
2

Su problema radica en el pin! MCLR. Cuando programa el PIC, está usando la función VPP, pero el mismo pin tiene la función! MCLR (Master Clear), y como esta función está baja, debe asegurarse de que este pin se mantenga alto para que el PIC pueda ejecutar su código. Como dijo Oli, puedes lograr esto conectando una resistencia de pull-up para el pin! MCLR.

Como alternativa, puede desactivar la función MCLR restableciendo (escribiendo un 0) el bit MCLRE en el registro CONFIG1.

__CONFIG(MCLRE_OFF & CP_OFF & WDTE_OFF);

Detalle del bit MCLRE de la página 130 de la hoja de datos:

  

MCLRE: Bit de selección de función de pin RA5 / MCLR / VPP
  1 = La función de pin RA5 / MCLR / VPP es MCLR
  0 = La función de pin RA5 / MCLR / VPP es E / S digital, MCLR vinculado internamente a VDD

Agregado

En cuanto al problema de lectura-modificación-escritura, ocurre debido a la forma en que funciona el PIC. Los PIC de 8 bits necesitan cuatro ciclos de reloj para cada ciclo de instrucción. Las escrituras se realizan en el último ciclo de reloj, mientras que las lecturas se realizan en el primer ciclo de reloj. Esto puede causar problemas cuando trabaja con diferentes bits del mismo puerto.

Supongamos que tiene el siguiente código:

RA0 = 1;
RA1 = 1;

Es de esperar que tanto RA0 como RA1 sean altos después de ejecutar este código. Este puede no ser el caso. Si tiene todos los bits establecidos en 0 en PORTA , cuando ejecute RA0 = 1 , el PIC leerá el valor en PORTA en el primer ciclo de reloj, establezca el bit 0 y vuelva a escribir el resultado en PORTA . Hasta el momento no hay problema, pero cuando ejecute la segunda instrucción (RA1 = 1), el PIC leerá primero el valor de PORTA, y lo más probable es que el pin RA0 no haya aumentado en 1, entonces el valor leído para ese pin es 0 en lugar de 1, luego se establece el bit 1, luego el resultado se vuelve a escribir en PORTA, pero solo se establece el bit 1.

Para evitar esto, puede agregar demoras entre las siguientes instrucciones:

RA0 = 1;
asm("nop");  // No operation
RA1 = 1;

Una instrucción nop debería ser suficiente.

En su código no debería tener este problema por dos razones:

  1. No estás cambiando bits diferentes en PORTA
  2. Tiene una instrucción de espera entre los bits de PORTA

El registro de sombra del que habla León consiste en un registro donde se modifican los bits individuales antes de escribir todo el registro en el PUERTO.

    
respondido por el Bruno Ferreira
1

Es posible que desee asegurarse de que los fusibles de configuración estén configurados de modo que RA6 sea un pin GPIO y no la función CLKO a la que también puede acceder el pin. Me encontré con este problema con un programa simple y el compilador de CCS. El compilador tiene una documentación tan pobre que es imposible saber exactamente qué está sucediendo sin mirar los bits del fusible.

Habría esperado que si el LED está en RA2 o RA6, tendrías un comportamiento errático si MCLR # no es alto. Quizás RA6 está más cerca de MCLR # y el problema se agrava; No estoy seguro.

    
respondido por el akohlsmith

Lea otras preguntas en las etiquetas