STM32当中,ucos的OSTimeDly是依靠是么硬件实现的,它属于软中断还是硬中断？

liyuanmrwhite

1、STM32当中,ucos的OSTimeDly是依靠是么硬件实现的,它属于软中断还是硬中断？

2、在原子给的delay.c文件中，我们发现，在延时小于5ms时，用的是STM32M-3提供的systick，在大于5ms时，调用的是UCOS的系统延时，那么，系统延时是依靠什么时钟实现的，也是通过systick来定时的么？

3、我现在写的液晶程序是用的delay.c，在ucos下，会发生进程调度而引起的中断。那么我将delay.c拆成非ucos的延时功能（即注释掉调用ucos那一部分代码），仅留下裸机时候的延时程序，是不是就不会导致进程调用而引起的中断了呢？

归根结底还是在于不清楚ucos的OSTimeDly是依靠什么硬件时钟实现的。

liyuanmrwhite

回复【楼主位】liyuanmrwhite:
---------------------------------
有书上说，UCOS需要利用单片机内的定时器产生时钟节拍中断服务程序，在STM32是借助于谁呢

正点原子

回复【2楼】liyuanmrwhite:
---------------------------------
systick

回复【楼主位】liyuanmrwhite:
---------------------------------
你看过哪些ucosii的书本？

liyuanmrwhite

回复【3楼】正点原子:

---------------------------------
单片机嵌入式应用的在线开发，嵌入式实时操作系统，任哲的和邵贝贝的，只是需要用到的地方才看，
我现在将delay.c 在ucos下的ms延时改了一下，

//延时nms
//nms:要延时的ms数
//void delay_ms(u16 nms)
//{
// if(OSRunning==TRUE)//如果os已经在跑了     
// {   
// if(nms>=fac_ms)//延时的时间大于ucos的最少时间周期 
// {
//    OSTimeDly(nms/fac_ms);//ucos延时
// }
// nms%=fac_ms; //ucos已经无法提供这么小的延时了,采用普通方式延时    
// }
// delay_us((u32)(nms*1000)); //普通方式延时,此时ucos无法启动调度.
//}

void delay_ms(u16 nms)
{

delay_us((u32)(nms*1000)); //普通方式延时,此时ucos无法启动调度.
}

这样，在液晶等一些驱动需要延时又不希望被进程中断的地方，就用systick来实现，
各个模块之间的进程调用就用ucos提供的 OSTimeDlyHMSM来实现，不知道理论上有没有问题。

正点原子

回复【4楼】liyuanmrwhite:
---------------------------------
自己测试下了。