Đang tải... (xem toàn văn)
Giới Thiệu Đề Tài Với mục tiêu làm quen với cách sử dụng HĐH thời gian thực (Real Time Operating System), Nhóm đã tự xây dựng cho mình hoàn chỉnh phần cứng cũng như ứng dụng chạy trên nền CooCox CoOS – một RTOS miễn phí được xây dựng cho dòng ARMCotexM3 Các module mà nhóm đã hoàn thành • Board phần cứng chạy với chip LPC1766 với các chức năng ngoại vi như ADC, DAC, USB, UART, JTAG, GPIO, TFT LCD • Toàn bộ Driver điều khiển LCD TFT 240x320 điểm ảnh • Phát triển library FAT để truy xuất file theo định dạng FAT từ thẻ nhớ • Xây dựng chương trình chơi nhạc WAV player, với wave file được đọc từ thẻ nhớ • Xây dựng chương trình BMP Viewer, với BMP file được đọc từ thẻ nhớ MicroSDCard • Toàn bộ giao diện được hiển thị trên LCD Graphic 2.4 inch và tương tác với người dùng bằng module Touching Mục Lục 1 Phần 1. Tìm hiểu CooCox CoOS RTOS 6 1.1 Mục tiêu 6 1.2 Kernel CoOS 6 1.2.1 Vấn đề Task Management 6 1.2.1.1 Các trạng thái của task 6 1.2.1.2 Task Control Block – Nơi lưu giữ thông tin một task 6 1.2.1.3 Ready Task List – Hàng đợi của các task ở trạng thái ready 8 1.2.1.4 Task Scheduling Định thời cho các task 8 1.2.1.5 Cách thức xử lí Critical Section của CoOS 9 1.2.1.6 Các interrupt trong CoOS 9 1.2.2 Vấn đề quản lí thời gian 10 1.2.2.1 System Tick 10 1.2.2.2 Delay Management 11 1.2.2.3 Software Timer 12 1.2.3 Memory Management – Quản lí bộ nhớ 12 1.2.3.1 Static Memory Allocation – Cấp phát bộ nhớ tĩnh 12 1.2.3.2 Dynamic Memory Management – Quản lí bộ nhớ động 13 1.2.3.3 Kiểm tra Stack Overfloaw 16 1.2.4 Intertask Synchronization – Vấn đề đồng bộ các task 17 1.2.4.1 Semaphore 17 1.2.4.2 Mutex 18 1.2.4.3 Flag 20 1.2.5 Intertask Communication – Vấn đề giao tiếp giữa các task 22 1.2.5.1 Mailbox 22 1.2.5.2 Message queue 23 1.3 Ứng dụng các API của CoOS 24 1.3.1 Các API liên quan đến OS. 24 1.3.1.1 CoInitOS() 24 1.3.1.2 CoStartOS() 25 1.3.2 Các API liên quan đến Task. 25 1.3.2.1 CoCreateTask() 25 1.3.2.2 CoExitTask() 26 1.3.2.3 CoDelTask() 26 1.3.3 Các API liên quan đến Software Timer. 27 1.3.3.1 CoCreateTmr () 27 1.3.3.2 CoStartTmr () 27 1.3.4 Các API liên quan đến Flag. 28 1.3.4.1 CoCreateFlag () 28 1.3.4.2 CoSetFlag () 28 1.3.4.3 CoWaitForSingFlag () 29 2 Phần 2. Các module hộ trợ cho việc phát triển ứng dụng trên CooCox CoOS 30 2.1 SDCard và giao tiếp SPI trên LPC1766 30 2.1.1 SDCard 30 2.1.1.1 Giới thiệu 30 2.1.1.2 Giao thức truyền dữ liệu 30 2.1.1.3 Sơ đồ chân 30 2.1.1.4 Thanh ghi 31 2.1.2 Module SPI trong LPC1766 33 2.1.2.1 Giới thiệu 33 2.1.2.2 Cấu hình căn bản khi sử dụng module SPI trong LPC1766 33 2.1.2.3 Hệ thống thanh ghi trong SPI: 33 2.1.2.4 Hoạt động của module SPI ở chế độ Master 36 2.1.3 Giao tiếp SPI giữa SD Card và LPC1766 36 2.1.3.1 Cấu hình kênh giao tiếp SPI 36 2.1.3.2 Cách thức trao đổi dữ liệu trên kênh SPI 36 2.1.3.3 Định dạng thông tin 37 2.1.3.4 Một số hoạt động diễn ra trên kênh SPI 39 2.2 Cấu trúc dữ liệu và hệ thống tập tin FAT 39 2.2.1 Cấu trúc vùng dữ liệu của thẻ nhớ 39 2.2.1.1 Partition Area 39 2.2.1.2 Regular Area 40 2.2.2 Hệ thống tập tin FAT 40 2.2.2.1 Cấu trúc tổng quan 40 2.2.2.2 Boot Sector 41 2.2.2.3 Bảng FAT (File Allocation Table) và cơ chế lưu trữ, cấp phát file 42 2.2.2.4 Thư mục (directory) 43 2.3 Thư viện EFSL 43 2.3.1 Tổng quan 43 2.3.2 Cấu hình và sử dụng EFSL 44 2.3.2.1 Cấu hình các thông số: 44 2.3.2.2 Hiện thực Hardware endpoint 44 2.3.2.3 Các hàm giao diện người dùng: 45 2.3.3 Cấu trúc EFSL 45 2.4 Xây dựng thư viện cho TFT LCD 2.4’ sự dụng chip điều khiên ILI9320 47 1.1. Giới thiệu 47 2.4.1 Xây dựng thư viện cho TFT LCD 47 2.4.1.1 Các hàm cấp thấp giao tiếp với phần cứng của LCD 47 2.4.1.2 Các hàm cấp cao phục vụ người dùng. 49 2.5 Module Touching 55 2.5.1 Cơ chế hoạt động 55 2.5.2 Hiện thực 56 2.6 Mô tả về Board hỗ trợ 57 3 Phần 3. Xây dựng ứng dụng 58 3.1 Task GUIMain 58 3.2 Task WAVPlayer 60 3.2.1 Định dạng của file WAVE 60 3.2.2 Hiện thực Task WAVPlayer 62 3.3 Task BMPViewer 64 3.3.1 Định dạng ảnh BMP 64 3.3.1.1 Giới thiệu: 64 3.3.1.2 Thuộc tính của BMP 64 3.3.1.3 Cấu trúc của BMP: Một tập tin BMP thường chứa những khối dữ liệu sau: 65 3.3.1.4 Sự dụng định dạng BMP 66 3.3.2 Hiện thực module BMP 67 3.3.2.1 Vai trò của module BMP 67 3.3.2.2 Các cấu trúc dữ liệu được sử dụng trong module BMP 67 3.3.2.3 Mô tả các hàm được cung cấp bởi module BMP 67 3.3.3 Hiện thực task BMPViewer 67 3.3.3.1 Giới thiệu 67 3.3.3.2 Hiện thực 67 4 Phần 4. Tổng Kết 68 Tài liệu tham khảo 70 Phục Lục 71 1 Phần 1. Tìm hiểu CooCox CoOS RTOS 1.1 Mục tiêu Tìm hiểu kernel CooCox CoOS (open source): cách quản lí các task, quản lí thời gian, quản lí bộ nhớ và điểu khiển việc đồng bộ, giao tiếp giữa các task.
TRƯỜNG ĐẠI HỌC BÁCH KHOA TPHCM Khoa Khoa học & Kỹ thuật Máy tính BÁO CÁO ĐỒ ÁN KTMT Đề tài Thiết kế và xây dựng ứng dụng với ARM Cotex-M3 trên nền CoOS-RTOS GVHD: Lê Trọng Nhân SVTH: Cao Văn Hùng Hồ Đăng Bảo Lê Đình Khánh Mai Xuân Minh RTOS – ARM Cortex M-3 GVHD : Lê Trọng Nhân TPHCM, tháng 1 năm 2010 Page 2 RTOS – ARM Cortex M-3 GVHD : Lê Trọng Nhân Giới Thiệu Đề Tài Với mục tiêu làm quen với cách sử dụng HĐH thời gian thực (Real Time Operating System), Nhóm đã tự xây dựng cho mình hoàn chỉnh phần cứng cũng như ứng dụng chạy trên nền CooCox CoOS – một RTOS miễn phí được xây dựng cho dòng ARM-Cotex-M3 Các module mà nhóm đã hoàn thành • Board phần cứng chạy với chip LPC1766 với các chức năng ngoại vi như ADC, DAC, USB, UART, JTAG, GPIO, TFT LCD • Toàn bộ Driver điều khiển LCD TFT 240x320 điểm ảnh • Phát triển library FAT để truy xuất file theo định dạng FAT từ thẻ nhớ • Xây dựng chương trình chơi nhạc WAV player, với wave file được đọc từ thẻ nhớ • Xây dựng chương trình BMP Viewer, với BMP file được đọc từ thẻ nhớ MicroSDCard • Toàn bộ giao diện được hiển thị trên LCD Graphic 2.4 inch và tương tác với người dùng bằng module Touching Page 3 RTOS – ARM Cortex M-3 GVHD : Lê Trọng Nhân Mục Lục TRƯỜNG ĐẠI HỌC BÁCH KHOA TPHCM 1 Khoa Khoa học & Kỹ thuật Máy tính 1 1 1 BÁO CÁO ĐỒ ÁN KTMT 1 Đề tài 1 Thiết kế và xây dựng ứng dụng 1 với ARM Cotex-M3 trên nền CoOS-RTOS 1 1 Phần 1. Tìm hiểu CooCox CoOS RTOS 5 2 Phần 2. Các module hộ trợ cho việc phát triển ứng dụng trên CooCox CoOS 29 3 Phần 3. Xây dựng ứng dụng 56 4 Phần 4. Tổng Kết 66 Tài liệu tham khảo 68 Phục Lục 69 Page 4 RTOS – ARM Cortex M-3 GVHD : Lê Trọng Nhân 1 Phần 1. Tìm hiểu CooCox CoOS RTOS 1.1 Mục tiêu Tìm hiểu kernel CooCox CoOS (open source): cách quản lí các task, quản lí thời gian, quản lí bộ nhớ và điểu khiển việc đồng bộ, giao tiếp giữa các task. 1.2 Kernel CoOS Đây là một nhân hệ điều hành thời gian thực, đa nhiệm, nguồn mở, tương thích với họ LPC1700 dùng chip vi xử lí ARM Cotex-M3. 1.2.1 Vấn đề Task Management CoOS dùng cơ chế scheduling preemptive và round robin. Một task là một công việc cụ thể mà CPU phải làm, một application có thể gồm nhiều task. Đối với hệ điều hành đa nhiệm, vào một thời điểm, có nhiều công việc cần được CPU thực hiện. Vấn đề quản lí các task như thứ tự thực hiện, thời gian thực hiện từng task, …sao cho đạt được hiệu suất cao là vấn đề cốt lõi của mọi hệ điều hành đa nhiệm. 1.2.1.1 Các trạng thái của task Running: Khi một task đang được CPU thực hiện thì nó ở trạng thái running. Ready : Khi một task đang chờ CPU thì nó ở trạng thái ready. Một task khi được tạo ra sẽ ở vào trạng thái ready. Waiting : Một task đang chờ một sự kiện nào đó xảy ra (chẳng hạn IO) sẽ ở vào trạng thái waiting. Dormant: Một task bị xóa khỏi bộ nhớ, không bao giờ được thực hiện nữa sẽ ở vào trạng thái dormant (terminated). 1.2.1.2 Task Control Block – Nơi lưu giữ thông tin một task Khi hệ điều hành đa nhiệm chuyển CPU từ task này qua cho task khác (vì thời gian dành cho task cũ đã hết), cần có một khối dữ liệu để lưu các thông tin về task cũ (chẳng hạn câu lệnh đang thực hiện) để nó có thể được thực hiện tiếp sau này. Khối dữ liệu này là gọi là một Task Control Block (TCB) có kiểu là struct. typedef struct TCB { OS_STK *stkPtr; /*CoOS tạo cho mỗi task một stack để lưu trạng thái của CPU. Điều này đồng nghĩa với việc lưu 16 thanh ghi đa dụng 32 bit của CPU (trong đó có thanh ghi Progam Counter cho biết đang thực hiện lệnh nào của task). Do cần thêm 4 byte để phát hiện stack bị over flow, tối thiểu mỗi stack phải có sức chứa 68 byte*/ U8 prio; /*priority của task, là một số unsigned 8 bit*/ Page 5 RTOS – ARM Cortex M-3 GVHD : Lê Trọng Nhân U8 state; /*Trạng thái của task */ OS_TID taskID; /*ID của task, dùng để xác định một task*/ #if CFG_MUTEX_EN > 0 OS_MutexID mutexID; #endif /*Nếu như có sử dụng cơ chế Mutex thì định nghĩa mutexID là ID xác định Mutex. Cách viết #if … #endif này giúp tiết kiệm bộ nhớ */ #if CFG_EVENT_EN > 0 OS_EventID eventID; /*!< Event ID.*/ #endif #if CFG_ROBIN_EN >0 U16 timeSlice; /*!< Task time slice. */ #endif #if CFG_EVENT_EN > 0 struct TCB *waitNext; /*!<Next TCB in the Event waiting list */ struct TCB *waitPrev; /*!<PrevTCB in the Event waiting list.*/ #endif #if CFG_FLAG_EN > 0 void* pnode; /*!< Pointer to node of event flag.*/ #endif U32 delayTick; /*!< The number of ticks which delay. */ struct TCB *TCBnext; /*!< The pointer to next TCB.*/ struct TCB *TCBprev; /*!< The pointer to prev TCB. */ }OSTCB,*P_OSTCB; Các TCB được tổ chức thành một danh sách liên kết một chiều, các TCB đã cấp phát cho các task nằm ở đầu danh sách, TCB cấp phát cuối cùng trỏ vào TCB trống đầu tiên. Nếu TCB cấp phát cuối cùng trỏ vào NULL, thì có nghĩa là đã hết TCB trống và task sẽ không được tạo ra nữa. Lúc mới khởi động hệ thống, các TCB đều trống, và được tổ chức như sau: 1.2.1.3 Ready Task List – Hàng đợi của các task ở trạng thái ready Hàng đợi này được tổ chức theo một danh sách liên kết 2 chiều, mỗi mắt xích là một TCB của một task. Khi một task được tạo ra, TCB nó sẽ được xếp vào danh sách liên kết theo Page 6 RTOS – ARM Cortex M-3 GVHD : Lê Trọng Nhân nguyên tắc FIFO có tính đến priority, tức là xếp vào cuối cụm các mắt xích TCB có cùng priority với nó. Task có TCB ở đầu hàng đợi sẽ là task được ưu tiên cao nhất, TCB đó gọi là RdyTCB. 1.2.1.4 Task Scheduling - Định thời cho các task Đối với các task khác priority, CoOS sử dụng cơ chế định thời Preemptive, tức là một task ready có thể giành quyền thực thi từ một task running nếu nó priority cao hơn. Đối với các task cùng priority, CoOS dùng cơ chế định thời Round robin, tức là luân chuyển CPU giữa các task, mỗi task được cấp CPU một khoảng thời gian nhất định gọi là time slice. Các time slice cho các task có thể khác nhau, như trong hình sau minh họa 3 task A, B, C có time slice lần lượt là 1, 2, 3. CoOS làm công việc định thời khi một trong các điều kiện sau xảy ra: a. Một task có priority cao hơn task running được chuyển vào trạng thái ready. Ở trường hợp này, hệ điều hành sẽ thực hiện cơ chế preemptive (tranh giành). b. Task running chuyển sang trạng thái waiting hay dormant. Ở trường hợp này, hệ điều hành chỉ đơn giản lấy task ready đầu hàng đợi ra, đưa nó vào trạng thái running. c. Task running đã dùng hết time slice của nó và có task khác trong ready list có cùng priority với task running. Ở trường hợp này, hệ điều hành sẽ thực hiện cơ chế round robin. Cụ thể là hàm định thời Schedule sẽ được gọi khi có một tick interrupt (hết time slice) hay có một sự chuyển trạng thái xảy ra. /*a. Is higher PRI task coming in? */ if(RdyPrio < RunPrio ) //priority number bé hơn nghĩa là priority cao hơn { TCBNext = pRdyTCB; //chuyển ngữ cảnh, đưa RdyTCB vào trạng thái running pCurTcb->state = STATE_READY; //chuyển trạng thái pRdyTcb->state = STATE_RUNNING; InsertToTCBRdyList (pCurTCB); RemoveFromTCBRdyList (pRdyTCB); } Page 7 RTOS – ARM Cortex M-3 GVHD : Lê Trọng Nhân /*b. Does Running task status change */ else if(pCurTcb->state != TASK_RUNNING) { TCBNext = pRdyTCB; //chuyển ngữ cảnh, đưa RdyTCB vào trạng thái running pRdyTcb->state = STATE_RUNNING; RemoveFromTCBRdyList (pRdyTCB); } /* c. Is it the time for robinning */ else if((RunPrio == RdyPrio) && (OSCheckTime == OSTickCnt)) { TCBNext = pRdyTCB; //chuyển ngữ cảnh, đưa RdyTCB vào trạng thái running pCurTcb->state = STATE_READY; //chuyển trạng thái pRdyTcb->state = STATE_RUNNING; InsertToTCBRdyList (pCurTCB); RemoveFromTCBRdyList (pRdyTCB); } 1.2.1.5 Cách thức xử lí Critical Section của CoOS Critical Section là đoạn code có câu lệnh làm thay đổi các tài nguyên dùng chung giữa các task và do đó không được chuyển ngữ cảnh khi đang thực thi trong Critical Section. Các cách xử lí Critical Section là: cấm các interrupt hoặc cấm các system call có thể gây chuyển ngữ cảnh trong Critical Section. CoOS chọn cách disable bộ định thời thay vì disable các interrupt để đảm bảo tính đáp ứng của hệ thống, vốn rất quan trọng trong các hệ thống thời gian thực. void Task1(void* pdata) { CoSchedLock ( ); // Enter Critical Section // Critical Code CoSchedUnlock ( ); // Exit Critical Section } 1.2.1.6 Các interrupt trong CoOS CoOS phân loại 2 kiểu interrupt, dựa vào tiêu chí nó có gọi các hàm API của CoOS hay không. Các interrupt không gọi API không ảnh hưởng gì đến hệ điều hành, do đó CoOS không đặt đòi hỏi gì các interrupt này. Đối với các interrupt có gọi API, CoOS yêu cầu bạn phải gọi các API thích hợp bên trong interrupt. Ví dụ: void WWDG_IRQHandler(void) { CoEnterISR ( ); // Enter the interrupt isr_SetFlag(flagID); // API function ; // Interrupt service routine CoExitISR ( ); // Exit the interrupt } Mọi API có thể được gọi trong ISR bắt đầu bởi isr_, như isr_PostSem ( ), isr_PostMail ( ), isr_PostQueueMail ( ) và isr_SetFlag ( ). Việc gọi một API khác bên trong ISR sẽ dẫn đến tình trạng system chaos. Page 8 RTOS – ARM Cortex M-3 GVHD : Lê Trọng Nhân Khi gọi một API tương ứng trong ISR, hệ thống cần xác định xem bộ định thời đang bị khóa hay không. Nếu như không khóa, hệ thống có thể gọi nó một cách bình thường. Ngược lại, hệ thống sẽ gửi một service request phù hợp đến list các service request và đợi đến khi bộ định thời được mở khóa mới đáp ứng nó. 1.2.2 Vấn đề quản lí thời gian 1.2.2.1 System Tick CoOS sử dụng interrupt systick để hiện thực system tick (tick: một khoảng thời gian rất ngắn). Bạn cần thiết lập tần số của system tick trong file config.h. CFG_CPU_FREQ là tần số của CPU clock. CFG_SYSTICK_FREQ là tần số của system tick bạn muốn. CoOS hỗ trợ tần số từ 1 đến 1000Hz, mặc định là 100Hz. SYSTICK là gì? SYSTICK là một Timer được tích hợp vào NVIC và được sử dụng để phát sinh một SYSTICK exception (exception kiểu #15). Exception là một điều kiện đặc biệt có thể làm thay đổi dòng chảy bình thường của chương trình. NVIC là một bộ phận được tích hợp với vi xử lí Cotex M3, có khả năng hỗ trợ đến 240 ngắt ngoài với số mức ưu tiên lên tới 256 và có thể quy định lại mức ưu tiên. SYSTICK là một hardware timer, nên không phụ thuộc vào các task đang chạy và do đó hệ thống không bị task đó chiếm quyền. Để làm được điều này, timer cần có khả năng tạo ra interrupt và được bảo vệ khỏi những user task để không có một user application nào có thể thay đổi timer. CoOS tăng giờ hệ thống lên 1 trong mỗi system tick ISR. Bạn có thể xem giờ hệ thống bằng cách gọi hàm CoGetOSTime(). CoOS cũng kiểm tra xem delayed list và timer list có rỗng hay không trong system tick ISR mà không tăng system time lên 1. Nếu list không trống, giảm delayed time của của phần tử đầu trong list đi 1 đơn vị, và kiểm tra xem có phải là waiting time của phần tử đầu trong list đã hết hay không. Nếu hết rồi, gọi hàm xử lí tương ứng, nếu không, chuyển qua bước tiếp theo. CoOS gọi hàm định thời để xác định xem hệ thống có cần phải chạy bộ định thời hay không khi thoát từ system tick ISR. Đoạn mã sau xử lí một system tick interrupt. void SysTick_Handler(void) { OSSchedLock++; /* Lock the scheduler. */ OSTickCnt++; /* Increment system time. */ if(DlyList != NULL) /* Have task in delayed list? */ { DlyList->delayTick ; /* Decrease delay time of the list head. */ if(DlyList->delayTick == 0) /* Delay time == 0? */ { isr_TimeDispose(); /* Call hander for delay time list */ } } #if CFG_TMR_EN > 0 if(TmrList != NULL) /* Have timer be in working? */ { TmrList->tmrCnt ; /* Decrease timer time of the list head. */ if(TmrList->tmrCnt == 0) /* Timer time == 0? */ { Page 9 RTOS – ARM Cortex M-3 GVHD : Lê Trọng Nhân isr_TmrDispose(); /* Call hander for timer list. */ } } #endif OSSchedLock ; /* Unlock scheduler. */ if(OSSchedLock==0) { Schedule(); /* Call task scheduler */ } } 1.2.2.2 Delay Management CoOS quản lí mọi delay và timeout của task thông qua delayed list. Khi bạn gọi các hàm CoTickDelay(), CoTimeDelay() hay CoResetTaskDelayTick() hay các hàm API khác có liên quan đến delay, CoOS sẽ sắp xếp các thời gian delay từ ngắn đến dài và sau đó chèm vào delayed list. Biến delayTick trong TCB lưu lại sự khác biệt giá trị của thời gian delay giữa task hiện thời và task trước. Phần tử đầu của list là giá trị thời gian delay hay thời gian timeout, trong khi những phần tử tiếp theo là sự sai biệt giá trị với phần tử trước nó. Để dễ hiểu, hình dung task A, B, C có thời gian delay lần lượt là 10, 18, 5, khi đó chúng được sắp vào delayed list như sau: Hệ thống sẽ giảm giá trị đầu list đi 1 mỗi system tick interrupt, và chuyển nó vào ready list nếu nó đã đạt giá trị 0. Khi chuyển các task có giá trị delayTick (xem hình) đạt 0, hệ thống phải xác định xem cần phải xử lí theo delay hay theo timeout. Đối với delay, CoOS, đưa nó vào ready list sau khi nó đã đưa ra khỏi delayed list. Đối với timeout, CoOS sẽ kiểm tra xem sự kiện nào dẫn tới overtime trước rồi mới chuyển task từ waiting list sang ready list. CoOS không bảo đảm độ chính xác dưới những điều kiện sau: i. Có một task có độ ưu tiên cao hơn task Achiếm CPU khi task A đang bị delayed, thời gian delay sẽ được xác định bằng thời gian chạy của task có độ ưu tiên cao hơn. ii. Có một task có độ ưu tiên bằng task A chiếm CPU khi task A đang bị delayed, thời gian delay được tính bằng số task có độ ưu tiên bằng task A ở trong ready list và chiều dài của time slice cũng như thời điểm kết thúc delay time. 1.2.2.3 Software Timer Software Timer (ST) là một timer chính xác cao, lấy nguồn là system tick. CoOS hỗ trợ 32 ST, mỗi ST có thể ở mode periodic (tuần hoàn) hay mode one-shot (một lần). Khi bạn tạo ra một ST bằng hàm CoCreateTmr(), ST được tạo ra ở trạng thái stopping, bạn phải gọi hàm CoStartTmr() để bật nó chạy. Khi một ST được tạo ra, CoOS gán cho nó một Page 10 [...]... trả lại vào free list và làm thao tác kết khối nếu nó nằm kề với một khối nhớ free khác Sau đây là sơ đồ Từ sơ đồ trên, task thấy rằng free list sẽ được chia thành nhiều mảnh nhỏ sau nhiều lần cấp phát và giải phóng bộ nhớ, dẫn đến tình trạng phân mảnh bộ nhớ Hệ thống lúc này phải dò tìm đến cuối free list mà vẫn không tìm được khối bộ nhớ phù hợp để gán cho ứng dụng Để khắc phục tình trạng trên, CoOS... priority inheritance với 3 task A, B, C có priority tương ứng là high, medium và low Các API liên quan: CoCreateMutex (): Tạo một mutex CoEnterMutex (), CoLeaveMutex (): vào, ra mutex section Đoạn code sau minh họa cách sử dụng các API trên: Page 18 RTOS – ARM Cortex M-3 GVHD : Lê Trọng Nhân 1.2.4.3 Flag Flag được sử dụng khi một task phải đồng bộ với nhiều sự kiện Mỗi sự kiện tương ứng với một flag Task... lượng bộ nhớ cần thiết không thể được xác định trong khi biên dịch mà phụ thuộc vào môi trường runtime khi hệ thống đang chạy Việc cấp bộ nhớ tĩnh là dựa trên kế hoạch; trong khi việc cấp bộ nhớ động là dựa trên yêu cầu tức thời Page 11 RTOS – ARM Cortex M-3 GVHD : Lê Trọng Nhân Bộ nhớ động linh hoạt hơn và sử dụng hiệu quả bộ nhớ Tuy nhiên nó chiếm CPU và có thể làm phân mảnh bộ nhớ, và không phải lúc... thái sẵn sàng … } Page 28 RTOS – ARM Cortex M-3 2 GVHD : Lê Trọng Nhân Phần 2 Các module hộ trợ cho việc phát triển ứng dụng trên CooCox CoOS 2.1 SDCard và giao tiếp SPI trên LPC1766 2.1.1 SDCard 2.1.1.1 Giới thiệu Secure Digital (SD) là chuẩn thẻ nhớ được sử dụng phổ biến trong các thiết bị di động hiện nay Thẻ nhớ SD được phân loại chủ yếu dựa vào kích thước vật lý và dung lượng Về kích thước, thẻ... lần lượt trùng với các chân 15, 16, 17 và 18 của Port 0, do đó cần ghi các bit tương ứng trong các thanh ghi PINSEL0, PINSEL1 và FIO0DIR để thiết lập hướng và chức năng cho các chân trên o Cấu hình ngắt: ngắt SPI được kích hoạt khi kích hoạt cờ ngắt SPI trong NVIC, đồng thời bit SPIF của thanh ghi S0SPINT được ghi lên 1 2.1.2.3 Hệ thống thanh ghi trong SPI: Gồm 5 thanh ghi điều khiển và 1 thanh ghi... periodic sẽ thiết lập lại timer dựa vào giá trị tmrReload mà bạn quy định và đưa trở lại vào timer list Ngược lại, ST kiểu one-shot sẽ bị đưa ra khỏi list và trạng thái của nó được đưa vào stop 1.2.3 Memory Management – Quản lí bộ nhớ 1.2.3.1 Static Memory Allocation – Cấp phát bộ nhớ tĩnh Việc cấp phát bộ nhớ tĩnh được áp dụng khi bạn không biết chắc bạn cần bao nhiêu dung lượng bộ nhớ khi biên dịch, và bộ... miniSD và microSD Còn về dung lượng, cũng có 3 chuẩn dung lượng là: Standard-Capacity (SD - dung lượng lên tới 2GB), High-Capacity (SDHC - dung lượng từ 4-32GB) và Extended-Capacity (SDXC - dung lượng từ >32GB lên tới 2TB) Trong đồ án này, thẻ nhớ microSD với dung lượng 1GB được sử dụng làm bộ nhớ thứ cấp cho VĐK LPC1766 Sau đây là một số điểm cần lưu ý về chuẩn SD, hỗ trợ cho việc thực hiện đồ án 2.1.1.2... data (theo cả hai hướng) • Có 2 kiểu giao diện bus giữa host và card: SD Card Bus và SPI Bus SD Card Bus dùng tới 4 chân Data, 1 chân Command và Responde để giao tiếp host, còn SPI Bus thì giao tiếp theo chuãn SPI, chỉ gồm 2 chân trao đổi tín hiệu Giao diện SPI Bus được sử dụng trong đồ án này và sẽ được nói rõ hơn trong phần sau 2.1.1.3 Sơ đồ chân Vai trò mỗi chân của SD Card khác nhau tùy theo kiểu... API trên: Page 21 RTOS – ARM Cortex M-3 GVHD : Lê Trọng Nhân 1.2.5.2 Message queue Một Message queue là một mảng các mailbox, khác với mailbox chỉ lưu 1 mail, nó có thể lưu được nhiều mail, được xác định bởi user khi tạo queue Các tính chất và API của Message queue hoàn toàn tương tự Mailbox Đoạn code sau minh họa cách sử dụng Message queue: Page 22 RTOS – ARM Cortex M-3 GVHD : Lê Trọng Nhân 1.3 Ứng dụng. .. đến bộ nhớ động là malloc() và free() Khi bạn gọi malloc(), hệ thống sẽ thực hiện những bước sau: i Tìm khối bộ nhớ thỏa mãn yêu cầu Thuật toán thường dùng nhất là first matching, tức là gán ngay khối nhớ đầu tiên thỏa mãn yêu cầu Thuật toán này tối thiểu thời gian tìm kiếm, song lại làm phân mảnh bộ nhớ ii Chia khối nhớ ra làm hai, phần đúng bằng dung lượng được yêu cầu và phần còn lại iii Chuyển phần