关于200~300uS的延时

1 能否直接读取Rtos的 系统时钟计数器来 实现延时统计,改如何读取呢?
2 通过独立的定时器中断来实现,这样感觉有点麻烦,好处是比较严谨,但是代码稍微复杂
3 直接while 循环倒计时  阻塞等待 ,这个计算出 CPU时钟周期, 然后想延时多久就可以算出来了

哪种方案好,或者 还有什么更好的方案

目的 为了控制IO输出

一般用3就够了，需要注意最好把代码放在RAM上运行，避免某些MCU的Flash Prefetch或Cache造成影响。
用2也可以，就是需要占用一路定时器了。
1的话，应该没法做到。一般FreeRTOS的Tick是10ms左右，没法达到楼主要求的精度。

楼上的建议 我又想了一下,直接阻塞计数延时 还不是很好,因为系统的任务调度时间是以ms 为单位的,
那就意味着 阻塞延时器件  执行系统调度的概率非常非常小,几乎可以忽略, 所以这样的延时还是影响了系统的效率, 延时依然在延时,系统没有机会反应过来 去切换执行其他任务

关于第1个 我想的是 读取系统最核心的计数器, 不知如何

【FreeRTOS使用其它定时器(非SysTick滴答定时器)作为系统时钟节拍的.】
【FreeRTOS任务运行时间信息统计】
【RTOS通用仿真环境的设计与实现】
【硬件实时操作系统的设计与实现】
这几个资料里说到启动延时器,停止延时器等功能，可否能用呢，调度内核是系统的核心，负责任务的调度管理；中断管理模块负责管理外部中断；定时器模块负责任务延时和周期执行。Delay_Counter为任务延时计数器。

把FreeRtos的基准时间设为200us到300us试试看，不过这样的话，程序会任务切换比较频繁，影响效率。

toofree 发表于 2018-6-2 23:59
把FreeRtos的基准时间设为200us到300us试试看，不过这样的话，程序会任务切换比较频繁，影响效率。 ...

这样不太好,  为一个任务的要求就改变了整个系统的时钟,不划算

如果不想影响系统的相应速度，还是用定时器吧。如果其他任务的执行需求没有那么紧迫，也可以使用while这种死等的方式

感觉2-300us有点快，一般正常FreeRTOS都是10ms或者是1ms的

50031185 发表于 2018-6-3 09:26
这样不太好,  为一个任务的要求就改变了整个系统的时钟,不划算

反正，要想定时，只有两种办法。
要么硬件定时，要么软件定时。
硬件定时器嫌麻烦，RTOS系统软件定时都是以最小节拍时钟为单位的。如果是本任务内，可以用while死等，但是不能有中断事件，否则延时无法保证。