Why does the printf serial port function affect the interrupt configuration?

传媒学子

Why does the printf serial port function affect the interrupt configuration? [Copy link]

Recently, I was debugging the camera receiving data part, YUV422, 15fs, field synchronization signal 66.7ms once.

In fact, external interrupts are very simple, but, I encountered a pit:

1. printf("\r\nInitialization completed"); config_interrupt();

复制代码

As shown in the figure above, the program can enter the interrupt correctly,

but put printf after the interrupt configuration function, after entering the interrupt, the interrupt flag is cleared and invalid, if there are instructions such as i++ in the program, it will be executed all the time.

1. config_interrupt(); printf("\r\nInitialization completed");

复制代码

I don't know what the problem is. I hope everyone can discuss it. . . It is initially believed that the UART send function will affect this interrupt, but the specific principle is not clear. I hope the masters can enlighten me.

For other codes, please check [GD32F350 Urban Youth Family Security Guard] The fifth post uses external interrupts to receive camera field and line synchronization signals https://en.eeworld.com/bbs/forum ... 8493&fromuid=363532

Supplementary content (2018-10-8 22:33): The problem has been solved, see my reply below, or the fifth post

tianjiu

I have encountered a problem when calling printf in C51. I had to set TI=1 first to work properly. The reason is that the printf function calls the putchar function for input, and putchar should first determine whether TI is 1. If it is not 1, it will wait for it to be 1. If it is 1, it will clear 0 and then send a character. The problem mentioned by the original poster needs to check the execution process of this function to find out the cause.

传媒学子

tianjiu posted on 2018-10-8 08:59 I once encountered a problem when calling printf in C51. I had to set TI=1 first to make it work properly. The reason was that the printf function called the putchar function for input, ...

I have located it. The PCLK clock is too high, causing the interrupt signal to be submerged. Thank you