版本 fb3d55e3876ff2787190b635ee14e79524442beb
Week #7 (Apr 7) :: ARM and RTOS: Part II
重大事項宣達
- 分組
Lab 39</embedded/Lab39>
_: FreeRTOS 作業分析
Adrian Huang<https://www.facebook.com/adrian.huang.10>
_ 的共筆<https://embedded2015.hackpad.com/Lab39-Cross-Development-2015Q1-Week3-DOv3d3rwi8b>
_ 與GitHub<https://github.com/AdrianHuang/freertos-basic/tree/new-task>
_- 建立每一Task所需要的資料結構 (使用heap_ww.c):
- XBlockLink:此結構用來記錄每一個區塊 (Block) 大小、下一個未被佔用的區塊大小與下一個未被佔用的區塊實體記憶體位址,其大小為 12 個位元組。由於使用 ARM Cortex-M3 架構,其對齊位元組為 8 個位元組。所以經過調整,一律使用 16 個位元組配置記憶體。
- TCB (Task Control Block):大小為 80 個位元組
- Stack:呼叫 xTaskCreate() 時,usStackDepth 設定 128,所以 stack 大小為 512 bytes (128 * 4)
- 每建立一個 task,需佔用 624 位元組。且記憶體大小為 17K,當剩下的記憶體空間低於 624 位元組時,就無法再建立 task
- task 建立/刪除後,一直在追蹤記憶體的變化,意外發現 vPortFree() 有個 bug,請見
重現和修正的方式<https://github.com/AdrianHuang/freertos-basic/commit/320274ddfd42cf20377e6f0b4e38bf146db9c877>
_
- 建立每一Task所需要的資料結構 (使用heap_ww.c):
- 曾柏翔的
共筆<https://embedded2015.hackpad.com/hw2-Ka5oXguvUje>
_- 針對優先序高的task執行太久而佔據 CPU,提出的改進方法:在 task 中加入
vTaskDelayUntil(&xLastWakeTime, xFrequency);
,當執行到一段時間後,就會主動釋出執行時間給別的 task 使用,從而避免因為一個 task 執行太久而造成 shell 來不及回應的問題
- 針對優先序高的task執行太久而佔據 CPU,提出的改進方法:在 task 中加入
Lab 40</embedded/Lab40>
_: Scheduling 作業分析
- Gary Gu 的
共筆<https://hackpad.com/Scheduling-nF35kNugzKX>
_4 組 system register 可用來設定
SysTick<http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0179b/ar01s02s08.html>
_- SysTick Control and status : enable , clock source, poll ,interrupt (address : 0xE000E010)
- SysTick reload value : value to load Current Value register when 0 is reached (address : 0xE000E014)
- SysTick current value : the current value of the count down (address : 0xE000E018).
- SysTick Calibration Value : might contain the number of ticks to generate a 10ms interval and other information, depending on the implementation (address : 0xE000E01C)
若要設定 SysTick,我們需要載入 SysTick event 發生間隔的數值到 reload value register,當 SysTick Control and Status Register 的 COUNTFLAG bit 內含值從 1 到 0 時,SysTick 會被啟動,所以會需要 n + 1 個 clock tick,如果 period 為 100 的話,那就是要輸入 99,reload value register 所支援的數值空間為 1 ~ 0x00FFFFFF
若想透過 SysTick 在固定的時間內產生一個事件,比如說 1ms,那可透過另外一個 Calibration register 的數值來 scale 給定的 reload register 值,Calibration register 是唯讀的暫存器,其數值表示 10 ms (SysTick 的 reload 週期) 的整數倍
若要讓 SysTick 產生中斷的話,要去設定 TICKINT (bit 1) 為 HIGH,然後透過 NVIC 去設定適當的中斷,另外還要設置 CLKSOURCE (bit 2) 為以下:
- 1 for core clock
- 0 for external reference clock
這次實驗就是透過讀取 current reload register 的數值,來達到精準的時間單位。系統載入階段,在記憶體初始化時,會做 memory mapping,定義的在檔案
CMSIS/CoreSupport/core_cm3.h
中關於 USART2 這個 IRQ 的 handler,可以到
$(CMSIS_PLAT_SRC)/startup/gcc_ride7/startup_stm32f10x_md.s
中定義的 vector table 找到USART2_IRQHandler
,但是這邊存放的不是處理的程式碼,而是真正 handler 的位址,ARM 核心會依據這個位址跳到真正處理的 handler 的位置進行中斷處理。在處理前,必須要先設定這個中斷,透過NVIC
- hsuedw 的
共筆<https://embedded2015.hackpad.com/Lab-40-NmDXrhMLX3B>
_ 與GitHub<https://github.com/hsuedw/visualizer>
_vTaskSwitchContext()
中,執行 switch out 前的那一刻記錄在previous_systick_current
中,執行完畢之際,利用traceTASK_SWITCHED_IN()
來記錄 task 被 switch in 的時間,而traceTASK_SWITCHED_IN()
是trace_task_switch()
的 wrapper。這樣的做法是,呼叫了trace_task_switch()
後,才記錄 task 被 switch in 時間- 這樣的作法不夠精確,因為這樣含有呼叫
trace_task_switch()
與呼叫get_current()
的時間。嚴重錯估 context switch 成本
- 延伸閱讀: Cortex M3 SysTick Explained
Part I<http://www.zembedded.com/cortex-m3-sys-tick-explained-part-i/>
,Part II<http://www.zembedded.com/cortex-m3-systick-explained-part-ii/>