WhyCan Forum(哇酷开发者社区)

是的，因为没有中断，可以使用一个线程专门轮询接收，当作一个中断函数用

是的，逻辑方面还好，速度方面很难搞，主机可以轻轻松松将scl搞到M级的速度，从机scl还在几K到几十K的级别。

除了keil，其他地方我只会一个printf调试大法~

锁要用到管理线程，对比一下当前线程分配，有没有配置管理线程，我代码里是用线程3

### HAL    1.2.2    2022-09-09
1.添加修改波特率函数，允许GPCOM在程序运行中单独修改波特率。

现在串口部分已经完成，对应的例程还没做好。

### HAL    1.2.1    2022-09-06   
1.修改HAL_DELAY()，现在最大可执行0xFFFFFFFFms的延时。   
2.优化hal库超时判断，包括mux和uart模块的超时，现在以更低的间隔来判断超时，也不再有额外的超时上限。   

### HAL    1.2.0    2022-09-03
1.添加uart模块。   

### HAL    1.1.2    2022-08-18
1.修改gpio部分寄存器名称。
2.将所有gpio寄存器添加到库中。
3.给gpio模块添加assert。

基于1.1.0帖子：互斥锁说明

### HAL    1.1.0    2022-08-14
1.添加hal库全局资源管理模块，占用一个线程，可配置。全局资源各线程循环获取，当前持有资源的线程下次将会最后判断。     
2.添加互斥锁。 
3.给printf()函数使用互斥锁。

今天又发现一个简单的延时，叫他版本3吧，代码如下：

版本3
void delay_us(u32 nus)
{
    u32 start,stop,ticks;
    start=CORE_CNT;
    ticks = nus * SYS_CORE_CLK_MHZ/4; 
    while(CORE_CNT-start<ticks){}
}

顺手测了一下误差。结果如下：

3比2少了一个判断和一个加减语句，但是每次循环多一个减法语句，误差不如2稳定，但是代码量小，用哪个大家自己决定。

那确实

由于每次调用该延时都有几us的误差，所以做长延时尽量不要使用循环。

//ms延时
void HAL_Delay(u32 Delay)
{
    delay_us(Delay*1000);    //误差更小
}
void HAL_Delay(u32 Delay)
{
    while(Delay--){
        delay_us(1000);
    }
}

修改波特率后乱码的问题解决方法在此https://whycan.com/t_8606.html

群里的青菜大佬vegetableswim给出了一个更优的解决方案，在100us内延时比原版代码更优，2us延时误差减小超过10%，以下是两种代码

原版：
void delay_us(u32 nus)
{
    u32 ticks;
    u32 told, tnow, tcnt = 0;
    GET_CORE_CNT(told);                             //读取内核定时器数值
    ticks = nus * SYS_CORE_CLK_MHZ/4;                                   //目标延时节拍数=需要延时时间(us)*CORE_CLK(MHz)/4
    while (1)
    {
        GET_CORE_CNT(tnow);
        if (tnow != told)
        {
            if (tnow < told)tcnt = 0xFFFFFFFF - told + tnow; //CORE_CNT递增32位，计算已延时节拍数
            else tcnt = tnow - told;
            if (tcnt >= ticks)break;                   //延时完成
        }
    };
}

优化版：
void delay_us(u32 nus)
{
    u32 start,stop,ticks;
    start=CORE_CNT;
    ticks = nus * SYS_CORE_CLK_MHZ/4; 
    if(0xFFFFFFFF-start>=ticks){
        stop=start+ticks;
        while(CORE_CNT<stop && CORE_CNT>start){}
    }
    else{
        stop=ticks-(0xFFFFFFFF-start);
        while(CORE_CNT>start){}
        while(CORE_CNT<stop){}
    }
}

互斥锁测试通过，现在以上两个问题可以确认解决。详细见https://whycan.com/t_8639.html/

添加了基于官方开发板的测试程序，程序在仓库的hal_mux分支，master分支我会尝试一些奇奇怪怪的功能，不适合大家参考。
https://gitee.com/ylc0919/mc3172/tree/hal_mux/
工程基于梦程的cmake，用visual studio 和vs code打开均可，原开源地址在https://github.com/dreamcmi/MC3172-CMake.

那好像确实有点，不过我的创建锁就是从全局所有空闲锁链表取一个，标记成已使用的，并不复杂，叫create应该没啥问题，或许叫get也可以，不过又怕和pend混淆了。

@海石生风
看来我要找点rtos的代码研究研究了

我也要搞个iic玩玩

这个printf库不是线程安全的，只能拿来临时用用

添加 printf库之后，需要将CMakeLists.txt中链接参数的-nostdlib -nodefaultlibs 这俩去掉。

如果用y=kx+b的方式表示延时曲线，假设准确延时为直线y=x，实测内部192M时钟源情况下，12M线程延时大概是y=0.99415x+1.245，x为期望延时，y为实测延时。

根据经验分析，k值应该是时钟误差，换用外部晶振可以减小。b值则是调用函数、取值、译码、计算等造成的，线程频率越高，误差越小。

在以上猜测基础上，10us以内延时用本代码没有什么精确性可言，且各线程误差受线程频率影响较大。不考虑时钟误差的情况下，延时越长越精确，不同频率的线程延时结果越接近，如果是ms级延时，则可以认为是通用延时。

我脑补了半天也没想到10us以内的通用延时怎么写。