CODEWITHSUNDEEP
stm32interrupthal
ElecDesigner
ElecDesigner

Reputation: 59

STM32F0 input to output latency - interrupt

I've got the device running at 48MHz and am simply using one input pin in interrupt mode to set an output high (setting low is done after a period is elapsed.

I'm surprised to see that the best latency I can get is about 2.8us. I'm using the HAL libraries to handle the interrupt but am writing to the output directly as eventually I might need multiple outputs to be set at once.

Is there anything that can be done to reduce this?

Here is my listing output.

    void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
    {
    800089c:    b580        push    {r7, lr}
    800089e:    b082        sub sp, #8
    80008a0:    af00        add r7, sp, #0
    80008a2:    0002        movs    r2, r0
    80008a4:    1dbb        adds    r3, r7, #6
    80008a6:    801a        strh    r2, [r3, #0]

            GPIOB->BSRR |= 0b0100000000000000;
    80008a8:    4b05        ldr r3, [pc, #20]   ; (80008c0 <HAL_GPIO_EXTI_Callback+0x24>)
    80008aa:    699a        ldr r2, [r3, #24]
    80008ac:    4b04        ldr r3, [pc, #16]   ; (80008c0 <HAL_GPIO_EXTI_Callback+0x24>)
    80008ae:    2180        movs    r1, #128    ; 0x80
    80008b0:    01c9        lsls    r1, r1, #7
    80008b2:    430a        orrs    r2, r1
    80008b4:    619a        str r2, [r3, #24]

    }
    80008b6:    46c0        nop         ; (mov r8, r8)
    80008b8:    46bd        mov sp, r7
    80008ba:    b002        add sp, #8
    80008bc:    bd80        pop {r7, pc}
    80008be:    46c0        nop         ; (mov r8, r8)
    80008c0:    48000400    .word   0x48000400

Upvotes: 0

Views: 206

Answers (1)

ElecDesigner
ElecDesigner

Reputation: 59

Thanks everyone who left comments, I looked into all of them and have managed to get down to about 660ns now. I think that's possibly the best achievable.

Changing the |= to the BSRR register saved about 100ns.

The bulk of the time was saved by moving the output assertion from the HAL callback function to the EXTI4_15_IRQHandler and doing the pin assertion first. In my case there are no other pins that can cause that interrupt so I figure I don't really need to check the source. Checking the source appears to take about 300ns.

I also have another HAL_GPIO_EXTI_IRQHandler call in the EXTI4_15_IRQHandler for a pin that I might have configured as an interrupt at one point (but isn't now).

I've ditched HAL completely; I assume I just needed to write something to clear the interrupt i.e. EXTI->PR = (1<<15); (it works anyway).

The only problem is that now every time I force an update to the source files, the program puts the calls to HAL back in.

Upvotes: 1

Related Questions