UART Interrupt dosen't cause lag ?

[CYara.1]

I run an example project which has 250 ms HAL_Delay with led blinking in while loop, and also an HAL_UART_Transmit_IT function which prints "Hello world!" with HAL_UART_TxCpltCallback calling itself.

250 ms led blink is not lagging and printing also works.

Quesition is; since interrupt also requires CPU, why led blinking is not lagging ?

Doesn't the interrupt just change the flow of the code which will be executed by the CPU?

[Peter BENSCH]

Welcome, @Cüneyt Yaran​, to the community!

What lag do you expect?

The HAL_Delay blocks the CPU while waiting for the end of the delay, but HAL_UART_Transmit_IT will not visibly lag this while transmitting the few characters, at best you might be able to measure it.

Regards

/Peter

[CYara.1]

Hello, thank you for answer @Peter BENSCH​  

i print 2000 character. actually im doing this example;

https://youtu.be/ic7hCrDopOQ?t=474

and it says interrupt method, data transfers are non-blocking.

[Peter BENSCH]

Well, the question is, how you define "blocking".

The interrupt method always gets the next character via interrupt, which only takes a few clock cycles that can normally be neglected, but of course you could measure it.

In contrast to this, the polling always waits until the characters have been transmitted, which logically slows down the CPU.

[Oliver Sedlacek]

The delay function uses a hardware timer (usually Systick but not always) and counts overflow interrupts until the number of interrupts calculated as corresponding to 250 msec have occurred. When the CPU has other work to do, e.g. servicing the print spool USART interrupt, the timer will still be counting. You only get a problem if the servicing of the timer interrupt is blocked by a higher priority interrupt service routine for longer than the timer overflow period.