Phân tích một RTOS kernel trong vi điều khiển

[qmk]

Đặc trưng của RTOS loại nhỏ như Tiny là chủ yếu dùng cho embedded system. Với ý nghĩa là một hệ chuyên dụng thì chỉ có một phần mềm (firmwave) phục vụ mục đích này thôi. Đặc trưng của RTOS là quản lý theo task và được biên dịch và nạp cùng lúc với chương trình. Việc viết chương trình cũng cần chia thành các task.

[opentdoors]

Chúng ta thử nói về Real time Linux thử nhé:

RTL sẽ đóng vai trò như một máy ảo đối với kernel hiện tại của linux. Do đó các tiến trình sử dụng RTL sẽ tương đương với lớp device driver, nghĩa là nó sẽ được nạp vào RAM, và được gọi theo yêu cầu (do thời gian, do sự kiện...). Do đó, để chơi với RTL, ít nhất phải biết tất cả những gì về kernel của Linux, nghĩa là một hacker thực sự.

Vậy mấu chốt nằm ở cách xử lý hàm timer phân giải cao mà mà Intel support, và thấu hiểu sched.h/c của linux kernel, và vai trò của con trỏ toàn cục "current"

Hãy bỏ qua tất cả những cái liên quan tới net, scsi, VGA... Hãy quan tâm cách boot đối với từng loại uP 32 bit, còn những device driver sẽ tương đương với lớp kernel, như khi chúng ta tìm cách viết một tiến trình trong 1 hệ RTOS 32 bit vậy.

Các bạn cứ tiếp tục thảo luận, tôi tranh thủ đọc lại kernel. Chúng ta sẽ bàn luận một Real-time 32 bit ở chủ đề khác, và cũng loanh quanh với "current", "FIFO"... thôi.

Bác QMK nghiên cứu thử 1 SBC/uC ARM 16/32 bit được không? Lúc nào anh em ta build thử trên em ARM

[opentdoors]

Tớ hỏi tiếp, đặc trưng nhất của một hệ điều hành là có thể cài thêm được các phần mềm. Vậy, tinyOS trong Keil có thể cài thêm các phần mềm được ko? Các phần mềm đó nó do ai phát triển hay các phần mềm đó chỉ là các bản add-on cho Keil thôi?

Cái này hay đấy!

Tôi không nghĩ cài thêm một phần mềm là một đặc trưng của OS. Ban đầu khi Linus Torvalds viết Linux, ông cũng không nghĩ đến điều này. Mà ông công bố mã nguồn, chuẩn RPM sau này là do RedHat sáng tạo. Việc tích hợp thêm các chức năng khác nhau, các công cụ khác nhau là do kiến trúc unix quy định, vậy các developer phát triển phần mềm và copy các thư viện, các file nhị phân vào đúng thư mục cũng như quyền truy nhập thì tự kernel nó hiểu.

Thực ra cách setup như windows cũng không có gì khác lạ, chẳng qua là MS quy định thế và che đi các thao tác.

Vì theo cách anh bạn nghĩ, phải có 1 consol hay tương tự để user đưa phần mềm mới vào một hệ thống đang có sẵn. Điều đó không khó, vì đó là cái giống như boot loader mà mọi tài liệu uC đều nói đến. Nhưng tôi nghĩ, không nên quy mọi cái giống như PC, vì bản thân uC nó có vai trò của nó trong thế giới Cyber, cung như PC có nhiệm vụ giao tiếp với human.

[qmk]

Chúng ta thử nói về Real time Linux thử nhé:

RTL sẽ đóng vai trò như một máy ảo đối với kernel hiện tại của linux. Do đó các tiến trình sử dụng RTL sẽ tương đương với lớp device driver, nghĩa là nó sẽ được nạp vào RAM, và được gọi theo yêu cầu (do thời gian, do sự kiện...). Do đó, để chơi với RTL, ít nhất phải biết tất cả những gì về kernel của Linux, nghĩa là một hacker thực sự.

Vậy mấu chốt nằm ở cách xử lý hàm timer phân giải cao mà mà Intel support, và thấu hiểu sched.h/c của linux kernel, và vai trò của con trỏ toàn cục "current"

Hãy bỏ qua tất cả những cái liên quan tới net, scsi, VGA... Hãy quan tâm cách boot đối với từng loại uP 32 bit, còn những device driver sẽ tương đương với lớp kernel, như khi chúng ta tìm cách viết một tiến trình trong 1 hệ RTOS 32 bit vậy.

Các bạn cứ tiếp tục thảo luận, tôi tranh thủ đọc lại kernel. Chúng ta sẽ bàn luận một Real-time 32 bit ở chủ đề khác, và cũng loanh quanh với "current", "FIFO"... thôi.

Bác QMK nghiên cứu thử 1 SBC/uC ARM 16/32 bit được không? Lúc nào anh em ta build thử trên em ARM

Khoảng 1 tháng nữa bác sang chỗ em anh em ta mổ sẻ một cái uCLinux trên ARM

[opentdoors]

Khoảng 1 tháng nữa bác sang chỗ em anh em ta mổ sẻ một cái uCLinux trên ARM

OK, nhưng uCLinux hình như hơi kén ARM.

[qmk]

OK, nhưng uCLinux hình như hơi kén ARM.

Bác tinh ý ghê, hihi em sửa lại thành embedded linux

[qmk]

Post tiếp bải đi bác opendoors ơi!
Lần này sẽ ủng hộ bác hết mình...

[anhtuan133]

Bravo bác opentdoors. Ý tưởng làm một cái RTOS mở cũng hay đấy. Hiện nay đã có cái FreeRTOS (www.freertos.org) với vô vàn PORTS (avr,arm,pic...). Con rtos này cũng oách phết đấy, có đầy đủ bộ phận như semaphore, message queues, mailboxs,monitor... đi kèm với bộ dịch WinAVR (www.avrfreaks.net/AVRGCC), hay WinARM thì còn có cả driver cho peripherals nữa. Đối với người dùng AVR, thì AVRStudio quả là một môi trường lập trình tương đối tốt (ngoại trừ tính năng search kém). Tuy nhiên, FreeRTOS cũng có nhược điểm là viết tương đối phức tạp, hầm hố, và dịch ra cũng khá to. Mình đã thử dịch cho con ATMEGA323 thấy hết 23Kbytes. Có một rtos khác là AVRX được xây dựng riêng cho dòng AVR (free).
Có một vấn đề khác khi xây dựng rtos, đó là compiler. Một số hãng viết compiler và rtos đi kèm nhau nên 2 phần ăn nhập với nhau rất tốt. Cụ thể, nếu bạn khai báo các biến array lớn trong task (vdu int arr_local[100] sẽ phát sinh vấn đề, compiler sẽ dịch nhầm khiến một số biến local chồng lấn lên nhau. Một vấn đề khác là reentrant functions (tham khảo trong tài liệu của Keil), các hàm standard thường mập mờ không nói rõ có hỗ trợ multi thead request hay không. Nếu phải khắc phục bằng đặt semaphore hay viết lại hàm thì quá tội.
Một vấn đề khác nữa, đó là speed grade của rtos. Nếu viết bằng C thì dễ open nhưng tốc độ giảm đi rất nhiều. Mà viết bằng asm thì lại kén compiler, người đọc cũng khó hiểu.
Một vấn đề nữa là tài liệu hỗ trợ, FreeRTOS có một kho tài liệu (core+libs), có một forum. Bạn thử viết 100 trang tài liệu mô tả sản phẩm xem có dễ hay khó. Ở cty tôi đã từng sản xuất tổng đài 2000 số nhưng tài liệu chỉ có chục trang giấy A4. Nếu viết để dùng thì rối rắm, mờ mịt thế nào cũng được nhưng viết cho người khác dùng thì phải rõ ràng, ngăn nắp, sáng sủa (nếu không em ThaiThuTrang lại bắt bẻ), đầy đủ tài liệu.
Có quá nhiều việc phải làm để 1 open RTOS được cộng đồng chấp nhận. Nếu opentdoors mà làm được điều đó thì bác quả thực là một "võ lâm đại cao thủ", bài học rút ra trên con đường đi tới thành công của bác sẽ được con cháu noi theo. chúc bác thành công.

[PTA08404]

Bác opentdoors có thể cho em hỏi, làm thế nào để viết 1 chương trình lên AVR323 dùng FreeRTOS, mình cần phải khai báo như thế nào trong file configRTOS,port.h,và macroport.h.
Bác có thể cho em 1 ví dụ đơn giản về cách tạo ra 4 task ứng với 4 led của 4 chân ra PC0,...PC3.
Cám ơn bác nhiều

[dinhanhvo]

noi nhieu ma chang thay cai gi ca

[emgaihocarm]

mông lung...

yeah...đúng rồi, nói dài thành nói... thôi. lần đầu tiên được một ông thầy nhận dạy thêm vi điều khiển, bài học đầu tiên thầy bắt mình làm là on/off một chân vi điều khiển và rồi tự đọc...tự viết...khi biết on/off một chân vi điều khiển rồi thì có thể làm được mọi việc tiếp theo.(tùy năng lực hi...).mấy sư huynh cứ bàn tán đâu đâu,theo em thì các sư huynh cứ cho mấy cái vị dụ cụ thể đi: nháy mấy con led ở các chân vi điều khiển khác nhau, vừa bấm fim hiển thị lcd trong khi port khác của vi điều khiển vẫn đang quét led chẳng hạn.từ các vị dụ đó để bọn em phát triển được nhiều việc hơn, tự đào sâu suy ngĩ thêm...các huynh cứ trao đổi mang tính hàn lâm quá, chẳng biết có mấy người hiểu không mà cứ khen nhau hoài ah! hay mấy huynh đang giấu bài

[opentdoors]

Chủ đề này khá lâu rồi, và tôi cũng không còn nghiên cứu về RTOS nữa. Tuy nhiên vì có những bạn sau này mới tham gia diễn đàn, nên tôi cần diễn giải lại để tránh hiểu nhầm:

- Tôi đã nghiên cứu RTOS cho mcu (cụ thể là 8051) dựa trên các tài liệu về hệ điều hành và qua tài liệu " Real-timer Systems Design and Analysis của Phillip A.Laplante. Bạn có thể tìm tài liệu này ở quầy Photo của ĐHBK TPHCM.

- Động cơ nghiên cứu của tôi là xuất phát từ sự yêu thích thuật toán và cấu trúc dữ liệu, từ đó mới nảy sinh ý tưởng xây dựng trên 8051. Vì cơ bản là xây dựng realtime stack, thuật toán realtime cho ngăn xếp.

- Tại thời điểm đó, có rất ít thông tin và chưa có ADSL như bây giờ nên tôi không biết (chính xác là sau này mới biết) AVRx hay FreeRTOS, tuy nhiên tôi không quan tâm đến phần code, và tôi nghiên cứu vì tôi thích và chia sẻ ý tưởng của thuật toán. Chứ tôi không có tham vọng làm một cái RTOS made in Vietnam.

- Vấn đề tại sao tôi stop? Bạn biết nhiều hơn tôi về các dạng RTOS trên net rồi, vậy bạn biết RTOS sử dụng như thế nào và ở đâu chưa? Tôi làm ra mà không có ai sử dụng thì tôi làm làm gì? Những cái tôi đã làm đủ để tôi hiểu về lập trình với RTLinux, RTAI và đọc mã nguồn cũng như giới hạn của một hobby RTOS.

- Khi tôi dừng tôi đã tổng kết thành một tài liệu và post lên luồng này dựa trên kiến trúc của 8051 và PIC16F. Sau đó, tôi cũng xóa luôn các tài liệu tham khảo cũng như tài liệu tổng kết này trên máy tính của tôi.

- Diễn đàn này sau đó bị hack và tài liệu đó cũng mất luôn. Tôi không lưu lại tài liệu, do đó các bạn không thấy tài liệu này nữa. Cũng đã có người hỏi nhưng rất tiếc tôi không còn trên máy tính.

[opentdoors]

Title của luồng này RTOS kernel. Vì vậy nó không liên quan đến một mcu cụ thể cũng như các tín hiệu điều khiển. Kernel chủ yếu là phân tích về cấu trúc xử lý các tác vụ theo một deadline, mà deadline này do các ngắt timer điều khiển.

Để hiểu RTOS, trước hết cần hiểu về khái niệm hệ điều hành, cấu trúc dữ liệu stack và queue, cũng như đa nhiệm. Nếu không thì việc nghiên cứu ứng dụng RTOS không có ý nghĩa, vì chúng ta không cảm nhận được sự khác biệt giữa một OS và một RTOS ở những khoảng thời gian nhỏ hơn 100ms.

Bạn dùng RTOS để điều khiển đèn LED hay nút nhấn cũng không có ý nghĩa, vì bạn không đo được hoặc khó mà thực hiện bài test về jitter và sự ảnh hưởng của jitter.

Ở giới hạn là yêu thích và nghiên cứu, tài liệu " " Real-timer Systems Design and Analysis" là tài liệu phù hợp nhất và tương đối hay.

Để sử dụng nó bạn phải dựa trên một bài toán cụ thể và phân tích bài toán. Tuy nhiên RTOS không phải là giải pháp tối ưu trong nhiều bài toán, một số bài toán không cần RTOS vẫn đảm bảo thời gian thực và nếu ứng dụng RTOS thì dẫn đến phức tạp và rối rắm.

Ví dụ, bộ SSC32 của Lynx Motion là bộ giao tiếp RS-232 để điều khiển 32 RC Servo, nó chỉ cần bộ định thời vì 32 tác vụ là như nhau và thời gian 40ms là quá nhiều với một AVR tại 7MHz.

Nhưng nếu là một bài toán điều khiển 3 bậc tự do + hiển thị thì trước hết phải phân tích deadline, tối ưu hóa công việc sau đó mới có thể nói đến ứng dụng RTOS.

Cho nên khi bạn hỏi về một con chip hay FreeRTOS cụ thể, tôi không trả lời là vì vậy. Vì tôi không biết chi tiết đến từng dòng lệnh, cũng không rành về chip AVR hay ARM.

[tackebongdn]

ANH CHO EM XIN ỨNG DỤNG TRÊN PIC 18F ĐƯỢC KHÔNG CẢM ƠN ANH MAIL EM LÀ vansontran09@gmail.com EM ĐANG LÀM TOT NGHIEP VỀ RTOS MONG MỌI NGƯỜI GIÚP ĐỞ.