GD32F芯片问题及解决分享

火辣西米秀

GD32F芯片问题及解决分享 [复制链接]

GD32F在有关初始化里，用库函数初始化分频系数，周期的 xxxx_init函数内，存在软件更新事件的代码，如果你不清除标志位，直接使能定时器中断，那么就会先进中断一次。导致有个别定时功能意外的激发。
再做LED点阵屏扫码程序时，发现对于08接口的单色屏扫16行大概，1ms就要扫1行，把扫屏串行数据函数放在1ms定时器中断里，就会发现这个定时器会占用特别多CPU时间，串口中断即便在19200波特率下，总是会丢失字节（发生字节超时错误），原因在于定时器优先级高，且定时器内做的事情差不多需要0.5ms，将串口中断优先级提升到可以抢占定时器中断，才不会发生串口字节丢失。虽然主频已经是跑36MHZ了，串口中断接收1个字节，应该在1us内就可以中断处理完毕。
void TIMER14_IRQHandler(void)
{
        timer_disable(TIMER14);
        timer_interrupt_flag_clear(TIMER14, TIMER_INT_UP);  
        timer_counter_value_config(TIMER14, 0);
        show_256x16_oneline(Sysinfo.scan_line);
        if(16 == ++Sysinfo.scan_line)   Sysinfo.scan_line = 0; //从第1行 扫到16行 再回到1行 舟而复始 索引0 是因为数组存储
        timer_enable(TIMER14);
}
3.keil5.2x采用新一代complier 6编译器，可以快速提升编译速度，但对于代码优化会跟c5不同，从而导致运行跟预先不符合。   void delay_us(unsigned char ctr)
{
    unsigned char nb;
   volatile unsigned char nop=1;
    for(; ctr>0; ctr--)
    {   
                for(nb=0; nb<US_UPPER; nb++)   //#elif  defined  (RISC_36MHZ)    #define  US_UPPER  5
                nop++;
    }
}
c6编译器 如果不对nop进行io修饰，全速运行下，这个for循环会比想的快很多（不能通过指令执行时间*估算一共需要执行多少次来==软延迟效果），而c5编译下，即便不用volatile 修饰，运行的效果 软延时时间会接近你 每条指令时间*大致的指令数。
4. 相信大家用的较多的应用往往包含USART，在大部分应用中，确保串口中断的优先级，在中断方式接收数据的时候，一定要快速读取接收到字节。否则容易出现字节超时错误OV，从代码健壮性和易于恢复来说，接收中断子程序里还是要对这个进行处理（判断标志位 清接收标志 读下接收寄存器）。一定要开1个定时器做字节超时保护，用于串口数据包异常下的自我恢复能力。

freebsder

不要用nop++,用自带的NOP宏空操作

火辣西米秀

freebsder 发表于 2021-5-8 09:31 不要用nop++,用自带的NOP宏空操作

是的，也是可以的

annysky2012

感谢分享~~~