新聞中心

        EEPW首頁 > 嵌入式系統 > 設計應用 > STM下純軟件實現精確定時

        STM下純軟件實現精確定時

        作者: 時間:2016-11-21 來源:網絡 收藏
        先上測試代碼(普通版)
        #include "stm32f10x.h"
        #include "core_cm3.h"
        __asm int Dellayus(u32 usec)
        {
        ALIGN
        PUSH.W {r1} //2時鐘周期
        MOV r1,#18 //1時鐘周期
        MUL r0,r1 //1時鐘周期
        SUB r0,#3 //1時鐘周期
        loop
        SUBS r0,#1 //1時鐘周期
        BNE loop //如果跳轉則為3個周期,不跳則只有1個周期
        POP {r1} //2時鐘周期
        BX lr //3個時鐘周期
        //總共所用周期為(usec*4)-4,此處減4主要用于抵消調用此函數的消耗時鐘周期(傳參1時鐘,BLX跳轉3時鐘)
        }
        int main(void)
        {
        while(1)
        {
        //運行到此處時32.93us,第1379時鐘周期
        Dellayus(100);
        //運行到此處時132.93us,第8579時鐘周期,運行上條指令共花8579-1379=7200時鐘周期
        //因系統時鐘為72MHz,所以每72時鐘周期所花時間為1微妙,上條指令所花時間
        //等于7200 ÷ 72 = 100微妙,延時完全準確
        Dellayus(100);
        //運行到此處時232.93us,第15779時鐘周期,同樣驗證上面的結論
        }
        }
        調試:
        第一個100微妙延時函數運行前

        第一個100微妙延時函數運行后

        所花系統時鐘周期8579-1379=7200個系統時鐘,時間精確為0.00013293-0.0003293=0.0001秒,
        也就是100微秒。延時函數通過軟件模擬以及硬件調試同樣精確,如果延時參數大于255微秒,調用
        時會多耗兩個時鐘周期(0.028微秒)用于從代碼段加載常數??梢孕薷拇a修正誤差。最大定時不能
        超過(232-1) ÷ 18 ≈ 238.6秒。
        以上方法可以節約系統定時器資源,避免和其他代碼爭用定時器。通常用于微秒級延時。
        版主的建議非常好,是該增加時鐘參數以適應不同的時鐘頻率,改了一下代碼,目前軟件仿真測試沒問題,等晚上再用JLink
        測試一下(理論上應該沒問題,已經考慮了閃存預取優化)。
        #include "stm32f10x.h"
        #include "core_cm3.h"
        __asm void Dellayus(u32 usec,u8 freq) //freq參數為系統時鐘頻率(SYSCLK),單位MHz,且必須能被4整除,且必須大 于等于16,常用的
        { //有24,36,48,56,72,如果一定要使用8MHz則必須滿足延時時間大于2微秒,但freq一定不要
        //小于8MHz,否則函數將出現混亂。條件為 ((usec >= 1) && (freq >=16)) || ((usec >= 2) && (freq >= 8))
        ALIGN
        LSR r1,r1,#2 //1時鐘周期,除以單次循環所用的時鐘數(4個)即得到延時1微妙所需的循環數
        MUL r0,r1 //1時鐘周期
        SUB r0,#3 //1時鐘周期
        NOP //用于匹配延時周期以及使loop循環處指令在8字節邊界對齊,提高精度(因為指令預取單元一次預取8字節指令)
        NOP //所以循環時都不用再從閃存內取指令,避免閃存延時影響延時精度
        loop
        SUBS r0,#1 //1時鐘周期
        BNE loop //延時循環,每次4個時鐘周期,最后一次只需兩個時鐘周期(如果跳轉則為3個周期,不跳則只有1個周期)
        NOP
        BX lr //3個時鐘周期
        //本函數內總共所用周期為usec*(freq/4)-2 +9,調用此函數的消耗5個時鐘周期(傳參2時鐘,BLX跳轉3時鐘)
        } //函數最低耗時11個時鐘周期,上面usec*(freq/4) - 2為循環代碼的耗時(此處減2是因為最后一次循環BNE沒有跳轉,只消耗1個時鐘比跳轉的3個時鐘節約2個所以減去2才是最終循環的耗時),9就是其它代碼的耗時
        //比如頻率為8MHz時延時2微秒所需延時周期數為2*8=16個時鐘,將值帶入上面的公式即為 2 * (8 / 4) - 2 + 9 =11 即為函數體耗時,再加上5個周期的調用開銷最終消耗16個時鐘周期,同時這也是最低延時周期數。
        int main(void)
        {
        while(1)
        {
        //運行到此處時32.93us,第1379時鐘周期
        Dellayus(100,72);
        //運行到此處時132.93us,第8579時鐘周期,運行上條指令共花8579-1379=7200時鐘周期
        //因系統時鐘為72MHz,所以每72時鐘周期所花時間為1微妙,上條指令所花時間
        //等于7200 ÷ 72 = 100微妙,延時完全準確
        Dellayus(100,72);
        //運行到此處時232.93us,第15779時鐘周期,同樣驗證上面的結論
        }
        }
        示例代碼見附件:
        附件1:軟件延時測試.rar (文件大小: 21 KB 下載次數:218次)

        附件2:軟件延時測試增強版.rar (文件大小: 22 KB 下載次數:309次)
        1、頂,花了不少功夫!
        不過在不同時鐘條件下,應該就又要修改代碼了吧?
        比如36M?8M?
        所以建議加入一個時鐘參數,這樣比較通用一點.
        2、謝謝樓主!,我軟件測試延時的時候并沒有出現當參數大于255微妙的時候會多消耗2個時鐘周期的情況,一樣很準啊。還有我用J-LINK仿真SW模式,單步,那個SEC沒有變化,不知道是怎么回事。還有一個問題:為什么返回值要用int不太懂匯編
        3、需要將J-LINK設為JTAG模式才能讀出SEC值,另外返回值用int當時主要是想以后增加函數功能
        4、這個建議非常好,馬上上個增強版
        5、呵呵,還不如用C的
        voidDelay_us(unsignedintt)
        {
        inti;

        for(i=0;i<144*t;i++){
        ;
        }
        }
        比上面匯編的要準:同時1000個循環,
        匯編用時為:100.844ms
        C及時:100.139ms
        6、搞個-O2優化試試,還準不準.
        另外換個時鐘頻率試試,還準不準?
        7、
        //加個編譯項就行了.
        #define OSC (8) //定義為8M
        #define OSC_D ((OSC*144)/8)
        #pragma O3
        void Delay_us(unsigned int t)
        {
        int i;
        for(i=0; i
        ;
        }
        }
        //測試
        //運行時間為100.014ms
        呵呵,純為游戲之作.在這種CPU,延時最好是用原子的方法了.
        8、用原子的戰艦開發板測試,用樓主這種方法,得到的延時總理理論時間的1.5倍,比如要延遲1秒,實際總是1.5秒。
        懷疑CPU運行在48M,但是我設置的的確是72M,是不是哪里設置有問題?
        9、要完全精確的話還得提前關掉中斷哦……
        不過一般也不需要這么精確的延時,獻上我的,不占用定時器資源哦:

        #defineRT_TICK_PER_SECOND100
        voidhw_tsc_init() //TSC-timestampcounter
        {
        unsignedintcnts;

        cnts=(unsignedint)9000000/RT_TICK_PER_SECOND;

        SysTick->CTRL&=0xfffffffb;//bit2清空,選擇外部時鐘,也即HCLK/8
        SysTick->LOAD=cnts-1;
        SysTick->VAL=0;//writetoclean
        SysTick->CTRL=0x01;//開始倒數不產生中斷
        }

        voidhw_tick_start()
        {
        unsignedintcnts;

        cnts=(unsignedint)9000000/RT_TICK_PER_SECOND;

        SysTick->CTRL&=0xfffffffb;//bit2清空,選擇外部時鐘,也即HCLK/8
        SysTick->LOAD=cnts-1;
        SysTick->CTRL=0x01;//開始倒數不產生中斷

        SysTick->CTRL=0x03; //啟動systick并產生中斷
        }
        voidhw_delay_us(unsignedintus)
        {
        unsignedintstart,target,cur;

        while(us>500) //防止us超過systick周期。(假設systick周期超過500us)
        {
        hw_delay_us(500);
        us-=500;
        }

        start=SysTick->VAL;
        target=(start-us*9);

        if(start
        {
        target+=(9000000/RT_TICK_PER_SECOND);
        do
        {
        cur=SysTick->VAL;
        }while(cur<=start||cur>target);//target不能等于start,否則死循環。也即us不能等于systick周期
        }
        else//target<=start
        {
        do
        {
        cur=SysTick->VAL;
        }while(target<=start); //假設target為一個很小的值,則cur有可能在循環周期內溢出而大于target,故須加上cur<=start的條件
        }
        }

        voidhw_delay_ms(unsignedintms)
        {
        while(ms--)
        {
        hw_delay_us(500);
        hw_delay_us(500);
        }
        }
        10、我不用軟件延時的...
        我一直用systick延時。
        11、樓主給力,不過不推薦用樓主這種笨辦法,樓主大可以移植ucos,移植成功后,你想定多久有多久,要多精確有多精確。
        同時,我覺得用定時器實現精確延時比這個方法靠譜得多。
        12、ucos的定時是以系統時基為單位的,比如OS_CFG_TICK_RATE_HZ設為100時就只能精確到10ms,也就是說高于10ms并且步進為10ms(50ms,500ms能較精確,但55ms就不精確了)可以比較精確定時,那我說延時10us如何用ucos的定時器定時呢?
        13、你可以增大ucos的時鐘節拍數,然后用OSTimeTick()來實現定時
        14、STM32的定時器多的是,基本都用不完吧



        關鍵詞: STM純軟件精確定

        評論


        技術專區

        關閉
        主站蜘蛛池模板: 景德镇市| 宝应县| 石景山区| 定南县| 儋州市| 黑龙江省| 汉中市| 航空| 石渠县| 青河县| 莱阳市| 泸水县| 麟游县| 大同市| 顺平县| 池州市| 乡宁县| 滦南县| 景东| 西畴县| 犍为县| 壤塘县| 高密市| 集贤县| 阿勒泰市| 茂名市| 宜阳县| 任丘市| 理塘县| 出国| 海丰县| 承德县| 广昌县| 昭苏县| 菏泽市| 原阳县| 贵定县| 神木县| 固原市| 闻喜县| 江华|