¿Qué ocurre con esta detección de cambio de pin PIC?

Question

Tengo dos PIC18F4620 conectado a través de SPI + Slave Select + adicionales de la línea de IRQ. Ambos controladores son impulsados desde el mismo oscilador de cristal utilizando la misma configuración del reloj. El maestro envía un byte y luego espera hasta que el esclavo alterna adicionales de línea de IRQ. La duración de la conmutación es de 4 ciclos de instrucción. Todos los bordes se ven bien sobre el alcance y la comunicación SPI funciona correctamente, excepto para la detección de la alternancia (while(!PORTBbits.RB1);).

Este es mi SPI envío de código:

    while (spi_out_msg_buffer.write_cursor > spi_out_msg_buffer.read_cursor)
    {
        DisableInterrupts;
        SSPBUF = spi_out_msg_buffer.data[spi_out_msg_buffer.read_cursor];
        LATBbits.LATB0 = 1;
        while(!PORTBbits.RB1); // wait for toggle on IRQ line
        LATBbits.LATB0 = 0;
        EnableInterrupts;
        spi_out_msg_buffer.read_cursor++;
    }

El while(!PORTBbits.RB1); se traduce en dos instrucciones:

BTFSS PORTB, 1, ACCESS
BRA 0x188

Yo insterted que B0 línea para propósitos de depuración, se puede ver en la parte inferior de este momento el diagrama:

Se puede ver que la conmutación de la línea de IRQ (segundo desde la parte inferior) y cómo se va sin ser detectados, debido a que el B0 de depuración de la línea se mantiene alta. Cuando puedo detener la ejecución a través de la CIE se cuelga en el interior de la while. Vale la pena mencionar que por lo general, funciona un par de bytes y luego se detiene, como se puede ver aquí:

He medido que el pulso es en realidad de 4 ciclos de instrucción (= 16 PLL ciclos = 4 ciclos de reloj) de largo:

Creo que debería ser suficiente para que el pulso sea detectado. Incluso si la primera BTFSS pierde es porque el puerto es muestreada en el comienzo del ciclo de una instrucción, a continuación, el segundo que se debe hacer es:

10 MHz -> PLL -> 40 MHz -> 10 M de instrucciones por segundo -> 100 ns de acuerdo a las instrucciones.

No debería ser lo suficientemente largo para salir de la while?

Answer 1

¿La última instrucción es una rama incondicional, correcta? Generalmente ramas y accesos de memoria (hechos en la primera instrucción, correcta?) toman de 2-3 x más tiempo para ejecutar, por lo en que caso las instrucciones podrían tomar unos 16 ciclos a ejecutar, que es 400ns (en el mejor de los casos).

Answer 2

Estás usando un compilador, por lo que no tienes idea de la cantidad de ciclos que el bucle de sondeo toma. En ensamblador podría llegar a 3 ciclos, pero le dio el derecho a contar los ciclos de cuando se escribió el código en un lenguaje de alto nivel.

Sin embargo, el verdadero problema es el enfoque general. Pedir el código para detectar un corto glitch no es una buena idea. Incluso si se pudiera garantizar el bucle de tiempo es menor que el glitch tiempo, ahora puede no activar las interrupciones durante la espera. Esto puede presentar problemas en la arquitectura posterior.

Una idea mucho mejor es utilizar el hardware que ya tiene que coger la falla, luego de tener el firmware comprobar que el hardware. La más sencilla sería la de alambre de la falla en uno de los INTx líneas, a continuación, busque la INTxIF bandera. Cambio de detectar los pines también el trabajo, pero tenga en cuenta que el indicador se establece en ambos bordes y usted tiene que borrar de la falta de coincidencia para eliminar la condición.

Answer 3

La razón real era ser un idiota. Mi DisableInterrupts lo macro INTCONbits.GIE=1 .

Encontré este accionando un pin durante la espera ocupada:

while(!PORTBbits.RB1)
{
    LATBbits.LATB0 = 0;
    LATBbits.LATB0 = 1;
}

Me di cuenta que la conmutación se detuvo en intervalos regulares y cuando el pulso de notificación entra en una de estas ventanas, pasa desapercibido.