Hanoi University of Science and School of Electrical Engineering

Technology Department of Automatic Control

Thiết kế hệ thống điều khiển nhúng

Lập trình nhúng

Chu Đức Việt

Department of Automatic Control
vietcd-fee@mail.hut.edu.vn 30.08.2012

Nội dung
• Tổng quan về phần mềm nhúng và ứng dụng
• Sơ đồ trạng thái hữu hạn (Finite State Machine-
FSM)
• Khuôn mẫu chương trình
• Kiến trúc chương trình

Chu Đức Việt 2

Dept. Of Automatic Control

1
 Tổng quan
• Là cơ sở cho các chức năng thông minh của hầu hết
thiết bị
• Tốc độ tăng trưởng 25-60% một năm
• Việc thiết kế và viết phần mềm nhúng khó khăn hơn so
với lập trình truyền thống
– Giao tiếp trực tiếp với phần cứng
– Tính thời gian thực
– Thực hiện song song nhiều quá trình
– Hướng theo sự kiện

Chu Đức Việt 3

Dept. Of Automatic Control

Hệ phát triển

Simulator
 Là một chương trình phần mềm cho phép người phát triển mã chương
trình chạy mô phỏng một chương trình viết cho một nền VXL/VĐK
(nền phần cứng đích) trên một môi trường phần cứng khác (hay còn
gọi là môi trường phát triển)  không hỗ trợ các ngắt thực và các thiết
bị ngoại vị.

Emulator
 Là một thiết bị phần cứng có khả năng thực hiện như một nền phần
cứng đích  là công cụ phát triển thời gian thực bởi nó cho ta phản
ứng với các sự kiện như nền phần cứng đích thực thi.
Chu Đức Việt 4
Dept. Of Automatic Control

2
 VD: Chương trình điều khiển cửa tự động
• Hàm điều khiển đóng mở cửa tùy theo
trạng thái của cảm biến

• Hãy cho biết đoạn chương trình trên

có lỗi gì ?

Chu Đức Việt 5

Dept. Of Automatic Control

Mô tả hành vi với sơ đồ trạng thái FSM

• Đoạn chương trình trên thiếu một khả năng chuyển

trạng thái từ “timing” => “open”
• Cửa có thể đập vào mũi khách ra vào

Chu Đức Việt 6

Dept. Of Automatic Control

3
 VD: Chương trình điều khiển cửa tự động

Chu Đức Việt 7

Dept. Of Automatic Control

Sơ đồ trạng thái của bộ điều khiển thang máy

• Bộ điều khiển gồm hai Mô tả hành vi bằng
thành phần ngôn ngữ tự nhiên
– Request Resolver: “Di chuyển buồng thang
nhận tín hiệu từ các máy đi lên hoặc đi xuống
nút bấm trong thang tới khi đến được tầng yều
máy và tại các tầng cầu, mở cửa thang trong
để đưa ra tầng yêu ít nhất 10s, sau đó tiếp
cầu kế tiếp cho bộ tục mở cửa cho đến khi
điều khiển thang có yêu cầu di duyển mới.
Đảm bảo cửa không bao
– Unit Control: điều
giờ mở khi đang di
khiển buồng thang di
chuyển. Không thay đổi
chuyển tới tầng được
chiều di chuyển trừ khi
yêu cầu
không còn yêu cầu có
• Hãy thử thực hiện mức ưu tiên cao hơn khi
đoạn chương trình đang đi lên hoặc thấp hơn
theo mô tả trên khi đang đi xuống”

Chu Đức Việt 8

Dept. Of Automatic Control

4
Sơ đồ trạng thái của bộ điều khiển thang máy
Mô tả hành vi bằng
ngôn ngữ tự nhiên
“Di chuyển buồng
thang máy đi lên hoặc
đi xuống tới khi đến
được tầng yều cầu, mở
cửa thang trong ít nhất
10s, sau đó tiếp tục mở
cửa cho đến khi có yêu
cầu di duyển mới. Đảm
bảo cửa không bao giờ
mở khi đang di chuyển.
Không thay đổi chiều di
chuyển trừ khi không
còn yêu cầu có mức ưu
tiên cao hơn khi đang
đi lên hoặc thấp hơn
khi đang đi xuống”

Chu Đức Việt 9

Dept. Of Automatic Control

Sơ đồ trạng thái của bộ điều khiển thang máy

• Nếu trực tiếp viết chương trình thể hiện mô tả hoạt

động của thang máy như trên sẽ khá phức tạp, khó
kiểm soát.
• Xây dựng một sơ đồ trạng thái hữu hạn mô tả hoạt
động của hệ thống như sau:
– Các trạng thái:
• Chờ, Đi lên, Đi xuống, Mở cửa
– Các khả năng chuyển từ trạng thái này sang trạng thái
khác tùy theo tập giá trị của các đầu vào
• VD: khi req > floor
– Các hành động được thực hiện trong mỗi trạng thái
• VD: Khi đang ở chế độ Đi lên, u,d,o,t = 1,0,0,0 (up = 1, down,
open, và timer_start = 0)

Chu Đức Việt 10

Dept. Of Automatic Control

5
Finite-state machine (FSM)
Mô hình trạng thái của bộ điều khiển UnitControl

req > floor

u,d,o, t = 1,0,0,0 GoingUp !(req > floor)

req > floor timer < 10

u,d,o,t = 0,0,1,0 !(timer < 10)
Idle DoorOpen
req == floor u,d,o,t = 0,0,1,1
req < floor

u,d,o,t = 0,1,0,0 !(req<floor)

GoingDn

u is up, d is down, o is open

req < floor
t is timer_start

Chu Đức Việt 11

Dept. Of Automatic Control

Định nghĩa
• FSM là một tập F<S, I, O, F, H, s0>
– S là tập tất cả các trạng thái của hệ {s0, s1, …, sl}
– I là tập các đầu vào {i0, i1, …, im}
– O là tập các đầu ra {o0, o1, …, on}
– F Là hàm chuyển trạng thái (S x I → S)
– H là hàm thể hiện các đầu ra (S → O)
– s0 là trạng thái ban đầu của hệ
• Sơ đồ kiểu Moore
– Hàm thay đổi các đầu ra được thực hiện tại các trạng thái (H là
ánh xạ S → O)
• Sơ đồ kiểu Mealy
– Hàm thay đổi các đầu ra được thực hiện trong khi chuyển trạng
thái (H là ánh xạ S x I → O)

Chu Đức Việt 12

Dept. Of Automatic Control

6
 FSM với dữ liệu (data path)
• FSMD: sử dụng các biến với kiểu dữ liệu phức hợp để lưu giữ liệu về
hoạt động của đối tượng
– FSM chỉ sử dụng kiểu nhị phân để biểu diễn các đầu vao/ra và các điều
kiện chuyển trạng thái
• FSMD: 7 thành phần <S, I , O, V, F, H, s0>
– S là tập tất cả các trạng thái của hệ {s0, s1, …, sl}
– I là tập các đầu vào {i0, i1, …, im}
– O là tập các đầu ra {o0, o1, …, on}
– V is a set of variables {v0, v1, …, vn}
– F Là hàm chuyển trạng thái (S x I x V → S)
– H là hàm tác động đến các đầu ra và thay đổi giá trị của các biến (S → O + V)
– s0 là trạng thái ban đầu của hệ
• I,O,V có thể là các biến với kiểu phức hợp (VD, số nguyên, số thực
v.v.)
• F,H Có thể chứa các hàm tính toán với các kiểu dữ liệu trên
Chu Đức Việt 13
Dept. Of Automatic Control

Các bước mô tả hành vi của hệ thống

1. Liệt kê tất cả các trạng thái của hệ thống
2. Định nghĩa tất cả các biến (variable) cần dùng (none in
elevator example)

3. Với mỗi trạng thái, liệt kê tất cả các khả năng chuyển tới
trạng thái khác với các điều kiện tương ứng
4. Đỗi với mỗi trạng thái và chuyển trạng thái, liệt kê các
hành động kèm theo (actions)
5. Đảm bảo việc chuyển trạng thái là đơn nhất
– Không được phép tồn tại hai điều kiện chuyển trạng thái cùng
đúng
• Nếu điều này xảy ra, ta sẽ có một mô hình không xác định
– Tại mọi thời điểm, luôn tồn tại một điều kiện đúng

Chu Đức Việt 14

Dept. Of Automatic Control

7
 Lập trình dựa theo mô tả của sơ đồ trạng thái

• Các ngôn ngữ lập trình phổ biến:

– C, C++, Java, Ada, VHDL, Verilog, v.v.
• Để lập trình dựa theo mô tả của sơ đồ trạng thái thường có hai cách
chính:
– Sử dụng các công cụ của phần mềm lập trình
• Thường là những công cụ được cài thêm để hỗ trợ việc lập sơ đồ trạng thái
– Hỗ trọ việc lập sơ đồ trạng thái ở dạng hình vẽ hoặc ở dạng text
– Hỗ trợ việc mô phỏng hoạt động của sơ đồ trạng thái
– Tự động sinh ra chương trình dưới dạng các ngôn ngữ lập trình khác nhau và
cho phép người lập trình sử dụng đoạn mã lệnh này để tích hợp vào chương
chình của mình
• Nhược điểm
– Bộ công cụ phần mềm để làm việc này thường đắt tiền, phức tạp
– Đoạn chương trình được tự động sinh ra thường phức tạp, không tối ưu và khó
kiểm soát.
– Language subset approach
• Là cách thường được các lập trình viên sử dụng...

Chu Đức Việt 15

Dept. Of Automatic Control

Language subset
• Tuân theo các khuôn mẫu
(template) để xây dựng chương #define IDLE
#define GOINGUP
0
1
trình từ sơ đồ trạng thái #define GOINGDN 2
• Các khuôn mẫu này có thể #define DOOROPEN
void UnitControl() {
3
được sử dụng trong nhiều loại int state = IDLE;
ngôn ngữ lập trình while (1) {
switch (state) {
• VD: UnitControl bằng ngôn ngữ IDLE: up=0; down=0; open=1; timer_start=0;
C if (req==floor) {state = IDLE;}
– Định nghĩa các trạng thái có if (req > floor) {state = GOINGUP;}
if (req < floor) {state = GOINGDN;}
thể có (#define) break;
– Khai báo các biến cần thiết và GOINGUP: up=1; down=0; open=0; timer_start=0;
khởi tạo trạng thái đầu (IDLE) if (req > floor) {state = GOINGUP;}
if (!(req>floor)) {state = DOOROPEN;}
– Sử dụng lệnh “switch” để rẽ break;
nhánh tới các đoạn lệnh tương GOINGDN: up=1; down=0; open=0; timer_start=0;
ứng với các trạng thái if (req < floor) {state = GOINGDN;}
if (!(req<floor)) {state = DOOROPEN;}
– Mỗi trạng thái có các hành break;
động DOOROPEN: up=0; down=0; open=1; timer_start=1;
• up, down, open, timer_start if (timer < 10) {state = DOOROPEN;}
– Kiểm tra điều kiện để chuyển if (!(timer<10)){state = IDLE;}
break;
sang trạng thái khác }
}
• if(…) {state = …;} }

UnitControl state machine in sequential programming language

Chu Đức Việt 16

Dept. Of Automatic Control

8
 Khuôn mẫu chung
#define S0 0
#define S1 1
...
#define SN N
void StateMachine() {
int state = S0; // or whatever is the initial state.
while (1) {
switch (state) {
S0:
// Insert S0’s actions here & Insert transitions Ti leaving S0:
if( T0’s condition is true ) {state = T0’s next state; /*actions*/ }
if( T1’s condition is true ) {state = T1’s next state; /*actions*/ }
...
if( Tm’s condition is true ) {state = Tm’s next state; /*actions*/ }
break;
S1:
// Insert S1’s actions here
// Insert transitions Ti leaving S1
break;
...
SN:
// Insert SN’s actions here
// Insert transitions Ti leaving SN
break;
}
}
}

Chu Đức Việt 17

Dept. Of Automatic Control

FSM phân cấp (Hierachical finite state machine)

• FSM có phân cấp được phát triển từ
FSM
– Mở rộng khả năng mô hình hóa các hệ
thống phức tạp. Without hierarchy With hierarchy
– Một số trạng thái nhỏ được “đóng gói” A
trong một trạng thái lớn A1 z
A1 z
x w
• Chức năng của mô hình không thay đổi y B x y B
nhưng sẽ có ít đường mũi tên biểu diến w
A2 z
các chuyển trạng thái hơn. A2

Chu Đức Việt 18

Dept. Of Automatic Control

9
 FSM phân cấp (Hierachical finite state machine)
Without hierarchy
req>floor UnitControl • FireMode
u,d,o = 1,0,0 GoingUp
req>floor
!(req>floor) – Khi tín hiệu fire báo có cháy
u,d,o = 0,0,1
Idle timeout(10) DoorOpen u,d,o = 0,0,1 xảy ra, buồng thang máy di
req==floor
req<floor !(req<floor) fire
fire chuyển xuống tầng 1 và mở
fire
u,d,o = 0,1,0 GoingDn fire FireGoingDn u,d,o = 0,1,0 cửa.
floor==1 u,d,o = 0,0,1
req<floor floor>1 FireDrOpen – Nếu không dùng FSM phân cấp
!fire fire
thì sơ đồ trở nên phức tạp.
– Sử dụng FSM phân cấp khiến
With hierarchy
cho sơ đồ trở nên dơn giản, dễ
UnitControl
req>floor NormalMode theo dõi và kiểm soát.
u,d,o = 1,0,0 GoingUp
!(req>floor)
req>floor
u,d,o = 0,0,1 u,d,o = 0,0,1
Idle DoorOpen
req==floor timeout(10)
req<floor !(req>floor)
u,d,o = 0,1,0 GoingDn

req<floor

fire FireMode
FireGoingDn u,d,o = 0,1,0
!fire
floor==1 u,d,o = 0,0,1
floor>1 FireDrOpen
fire

Chu Đức Việt 19

Dept. Of Automatic Control

Round Robin architecture

void main(void)
{
while(TRUE)
{
if ( !! I/O device A needs attention )
{
!! Take care of device A and handle its data
}
if ( !! I/O device B needs attention )
{
!! Take care of device B and handle its data
}
…
if (!! I/O device Z needs attention)
{
!! Take care of device Z and handle its data
}
}
}
Chu Đức Việt 20
Dept. Of Automatic Control

10
 Round Robin architecture
• RR Examples
– Digital multimeter
• Measure: resistance, current and potential
• For each situation select the right scale
– Washing machine
– Airbag controller
– Anything that displays information.
• RR Evaluations
– Simplicity!
• No priorities, no interrupts, no data-sharing bugs
• Suited for systems with no latency concerns
• Worst response time of task code = sum of all task code
– Alternative design: interleaving devices
– Fragile design: timing in future versions?

Chu Đức Việt 21

Dept. Of Automatic Control

Round Robin with interrupt

bool flagA=FALSE, flagB=FALSE, ..., flagZ=FALSE;
void interrupt handleA (void) {
!! Take care of the I/O device A flagA = TRUE;
}
...
void interrupt handleZ (void) {
!! Take care of the I/O device Z flagZ = TRUE;
}

void main(void) {
while(TRUE) {
if (flagA) {
flagA = FALSE
!! Handle data from device A
}
if (flagB)
...
}
}
Chu Đức Việt 22
Dept. Of Automatic Control

11
 RR-ISR Characteristics
• Splits the work between interrupts and
main
– Interrupts handle I/O of devices
– Main function deals with processing data
• Why use interrupts?
– Allow fast response time for handling I/O
buffers(event-based design vs. polling design)
– Set flags to indicate work has to be done
– Take advantage of the interrupt-priority
system
• Often the most appropriate architecture!
Chu Đức Việt 23
Dept. Of Automatic Control

RR-ISR Examples
• Systems with few components needing fast
response time (limited processing needed)
• Most likely to be found in:
– Stopwatches
– Modern washing machines
– Coffee machines
– Microwave ovens
– Central heating units
– Traffic light controllers
• Other: data-bridge devices and barcode
scanners
Chu Đức Việt 24
Dept. Of Automatic Control

12
 RR-ISR Evaluation
• Leads to a simple design (still...)
– Data-sharing problem introduced
– All task codes have the same priority - no long
tasks!!!
– Worst response time = sum of all task code + ISR
times
• Alternative designs:
– Move code in interrupts
– Interleaving devices in main()
• Fragile design: timing in future versions?
– Changing code or ISR priority for one device.

Chu Đức Việt 25

Dept. Of Automatic Control

Function-Queue Architecture
!! Queue of function pointers
void interrupt handleA(void) {
!! Take care of I/O device A
!! Put functionA on queue of function pointers
}
!! ISR for devices B...Z
void functionA(void) {
!! Handle actions required by A
}
!! Functions for devices B...Z
void main(void) {
while(TRUE) {
while (!! Queue of function pointers is empty) {};
!! Call first function on the queue
}
}
Chu Đức Việt 26
Dept. Of Automatic Control

13
 FQ Evaluation
• Splitting of responsibilities similar to RR-ISR
– Interrupts handle I/O of devices
– Main function deals with processing data (via
functions)
• Insert operation for the queue was not
specified!
– FIFO queue leads to RR-ISR
– Priority queue leads to task priorities
– FQ architecture gives the basis for “non-
preemptive OSes”
• Worst response time = longest task + tasks
with higher priority + ISR routines

Chu Đức Việt 27

Dept. Of Automatic Control

14