Những lưu ý sống còn khi làm việc với callback function của Software Timer

1. Giới thiệu

Trong FreeRTOS, Software Timer (bộ đếm thời gian phần mềm) là một thành phần quan trọng giúp thực hiện các thao tác theo chu kỳ hoặc sau một khoảng thời gian định trước. Khi một software timer hết thời gian, một hàm gọi lại (callback function) sẽ được thực thi. Mặc dù lập trình viên có thể tùy ý viết nội dung cho callback function, nhưng có một nguyên tắc quan trọng cần tuân thủ: tuyệt đối không được để callback function rơi vào trạng thái block hoặc thực hiện các thao tác có khả năng block (gây chờ đợi vô thời hạn hoặc kéo dài).

Bài viết này sẽ làm rõ lý do tại sao điều đó lại quan trọng, bao gồm cơ chế hoạt động nội bộ của software timer, ảnh hưởng của blocking đến hệ thống thời gian thực, và những sai lầm phổ biến mà lập trình viên cần tránh.

2. Tổng quan về Software Timer trong FreeRTOS

2.1 Cấu trúc và nguyên lý hoạt động

Software Timer trong FreeRTOS sử dụng một task riêng biệt gọi là Timer Service Task (còn gọi là Timer Task) để quản lý và thực thi các hàm callback tương ứng khi timer hết hạn.

Quy trình hoạt động như sau:

1. Khi một software timer được start hoặc reset, nó sẽ được đưa vào một hàng đợi bên trong hệ thống.
2. FreeRTOS kernel sẽ giám sát thời gian hệ thống (tick count).
3. Khi đến thời điểm timeout, thông tin về software timer sẽ được đưa vào một queue của Timer Task.
4. Timer Task sẽ wake-up, đọc từ hàng đợi, và thực hiện callback function tương ứng.

Timer Task chỉ có một task duy nhất, hoạt động theo nguyên tắc FIFO, nghĩa là các callback được thực hiện tuần tự.

2.2 Tính chất của Timer Callback

Callback function của software timer chạy trong context của Timer Task, không có stack riêng biệt, không có ưu tiên cao. Chính vì thế, nó bị ràng buộc bởi nhiều quy tắc nghiêm ngặt để bảo đảm hệ thống không bị treo, block hoặc mất thời gian thực.

3. Hiểu thế nào là “block” trong callback function

Trong FreeRTOS, "block" có thể hiểu theo nhiều dạng:

• Gọi hàm có thời gian chờ: ví dụ như xQueueReceive(queue, portMAX_DELAY) hay xSemaphoreTake(sem, 1000) bên trong callback.
• Chờ tài nguyên: như mutex bị chiếm giữ.
• Delay thủ công: như vTaskDelay() hoặc vTaskDelayUntil().
• Vòng lặp vô hạn hoặc lâu: ví dụ vòng while xử lý dữ liệu mất vài giây.

Bất kỳ hành vi nào khiến Timer Task không thể thực thi các callback tiếp theo kịp thời đều được xem là block trong ngữ cảnh này.

4. Hậu quả khi callback của software timer bị block

4.1 Mất thời gian thực của hệ thống

Vì chỉ có một Timer Task duy nhất thực thi tất cả các callback của timer, nên nếu một callback bị block, toàn bộ các timer khác sẽ bị đình trệ hoặc bỏ lỡ thời hạn. Điều này có thể dẫn đến:

• Các tác vụ định kỳ không được thực hiện đúng lúc.
• Các chức năng quan trọng như watchdog, kiểm tra sensor, cập nhật trạng thái, v.v… bị chậm hoặc bỏ qua.
• Hệ thống không còn đảm bảo tính "real-time".

Ví dụ:

void vLongCallback(TimerHandle_t xTimer)
{ vTaskDelay(pdMS_TO_TICKS(2000)); // Block trong 2 giây
}

Giả sử callback này được gọi sau 100ms, thì các software timer khác phải chờ ít nhất 2 giây để đến lượt mình được thực hiện, gây sai lệch nghiêm trọng.

4.2 Deadlock tiềm tàng

Nếu callback function cố gắng chờ mutex hoặc semaphore mà lại không được cấp phát ngay lập tức, Timer Task sẽ bị treo.

Ví dụ nguy hiểm:

void vBadCallback(TimerHandle_t xTimer)
{ xSemaphoreTake(xSomeSemaphore, portMAX_DELAY); // Deadlock nếu không có ai release
}

Nếu xSomeSemaphore không được release hoặc đang bị giữ bởi một task khác, callback này sẽ block vô thời hạn. Điều này khiến Timer Task không còn xử lý bất kỳ timer nào nữa — hậu quả tương đương hệ thống bị chết một phần.

4.3 Mất công suất hệ thống (CPU utilization bị lệch)

Vì Timer Task sử dụng stack riêng nhưng chia sẻ tài nguyên hệ thống với các task khác, việc một callback chiếm dụng CPU quá lâu sẽ gây ra:

• Lệch tải: Task khác không được ưu tiên đúng.
• Thiếu stack: Có thể gây stack overflow nếu callback thực hiện các thao tác quá phức tạp.
• Tăng jitter: Các thao tác vốn phải chính xác về thời gian bị lệch pha.

5. Những thao tác không nên làm trong callback function

6. Hướng giải quyết – Thiết kế đúng đắn

6.1 Sử dụng callback như một trigger

Thay vì xử lý trực tiếp trong callback, hãy dùng callback chỉ để gửi tín hiệu (trigger) cho một task khác có quyền xử lý riêng.

Ví dụ:

void vSafeCallback(TimerHandle_t xTimer)
{ xTaskNotifyGive(xMainTaskHandle); // Chỉ notify, không xử lý
}

Rồi trong xMainTaskHandle ta xử lý đầy đủ logic. Điều này giúp Timer Task nhanh chóng quay về trạng thái sẵn sàng phục vụ các callback tiếp theo.

6.2 Tăng độ ưu tiên của task xử lý logic

Nếu công việc cần thực hiện sau khi timer hết hạn là quan trọng, hãy dành riêng một task có độ ưu tiên cao để xử lý.

Cấu trúc điển hình:

Software Timer ↓ callback (notify)
Main Task (prioritized) ↓ full processing

6.3 Dùng queue hoặc semaphore không block

Nếu cần truyền dữ liệu từ callback ra task chính, hãy dùng xQueueSendFromISR() hoặc các hàm tương tự không block.

void vCallback(TimerHandle_t xTimer)
{ int data = 123; xQueueSendToBackFromISR(xQueue, &data, NULL); // Non-blocking
}

6.4 Nếu cần delay, hãy tách thành task

Nếu không thể tránh delay hoặc chờ đợi, hãy thiết kế một task chuyên biệt để thực hiện điều đó. Tuyệt đối không dùng Timer Callback cho mục đích đó.

7. Tình huống thực tế và bài học

Ví dụ thực tế:

Một ứng dụng IoT thu thập dữ liệu cảm biến mỗi 100ms, truyền về máy chủ. Lập trình viên đặt timer với chu kỳ 100ms và trong callback, thực hiện:

• Đọc sensor.
• Tạo chuỗi JSON.
• Gửi lên server bằng HTTP (qua socket).

Điều này làm callback mất 300–500ms, gây nghẽn tất cả các timer khác, dẫn đến:

• Cảnh báo nhiệt độ chậm.
• Watchdog không reset đúng lúc.
• Hệ thống bị treo không rõ nguyên nhân.

Giải pháp:

• Trong callback chỉ set flag hoặc notify.
• Tạo một task chuyên đọc sensor và gửi HTTP.
• Đảm bảo task đó có ưu tiên phù hợp.

8. Kết luận

Việc để callback function của Software Timer trong FreeRTOS rơi vào trạng thái block là một lỗi thiết kế nghiêm trọng. Nó không chỉ ảnh hưởng đến một timer cụ thể, mà còn có thể khiến toàn bộ hệ thống mất tính thời gian thực, gây treo, sai lệch hành vi, hoặc thậm chí chết hẳn hệ thống.

Nguyên tắc cần nhớ:

• Callback phải ngắn, gọn, không block.
• Không thực hiện xử lý logic phức tạp trong callback.
• Hãy dùng callback như một trigger cho các task chính.

Tuân thủ những nguyên tắc này sẽ giúp hệ thống FreeRTOS hoạt động ổn định, đúng thời gian và đáng tin cậy — một yếu tố sống còn trong các hệ thống nhúng thời gian thực.