TAPIT - AIoT Learning

5 LÝ DO EDGE AI ĐANG ĐỊNH HÌNH THIẾT BỊ THÔNG MINH

Trong hệ thống nhúng, gửi toàn bộ dữ liệu cảm biến lên cloud không phải lúc nào cũng là kiến trúc tối ưu. Edge AI đưa quá trình inference xuống cảm biến, MCU, MPU hoặc gateway — ngay tại nơi dữ liệu được tạo ra. Theo STMicroelectronics, hướng tiếp cận này mang lại năm lợi ích chính:

1. Độ trễ thấp hơn
Loại bỏ thời gian truyền dữ liệu lên cloud giúp thiết bị phản hồi nhanh hơn. Tuy nhiên, muốn đáp ứng thời gian thực vẫn phải đo toàn bộ pipeline: thu nhận dữ liệu, tiền xử lý, inference, hậu xử lý và điều khiển đầu ra.

2. Giảm dữ liệu truyền và chi phí cloud
Thay vì gửi liên tục hình ảnh, âm thanh hoặc dữ liệu rung thô, thiết bị chỉ cần gửi kết quả như “phát hiện người” hoặc “xuất hiện bất thường”.

3. Tối ưu năng lượng
Giảm thời gian hoạt động của Wi-Fi, cellular hoặc radio có thể kéo dài thời lượng pin. Nhưng inference cũng tiêu thụ năng lượng, vì vậy cần so sánh năng lượng mỗi lần suy luận với năng lượng truyền dữ liệu trong điều kiện vận hành thực tế.

4. Hoạt động khi mất kết nối
Thiết bị vẫn có thể phát hiện, cảnh báo hoặc điều khiển mà không phụ thuộc liên tục vào cloud. Đây là lợi thế quan trọng trong công nghiệp, nông nghiệp và các hệ thống triển khai ngoài hiện trường.

5. Hạn chế dữ liệu nhạy cảm rời khỏi thiết bị
Xử lý cục bộ giúp giảm lượng hình ảnh, giọng nói hoặc dữ liệu sinh trắc học phải truyền qua mạng. Tuy nhiên, quyền riêng tư vẫn cần được bảo vệ bằng secure boot, firmware update có xác thực, bảo vệ khóa và kiểm soát truy cập.

Trong hệ sinh thái ST, workload đơn giản có thể chạy trên cảm biến tích hợp MLC hoặc ISPU; các bài toán phân loại và phát hiện bất thường có thể triển khai trên STM32 thông dụng. Với computer vision hoặc audio phức tạp hơn, STM32N6x7 tích hợp Neural-ART Accelerator đạt tối đa 600 GOPS theo công bố của ST.

STM32Cube AI Studio hỗ trợ tối ưu mô hình và sinh mã C, NanoEdge AI Studio hướng đến AutoML từ dữ liệu, còn ST Edge AI Developer Cloud cho phép benchmark trên phần cứng.

Nhưng cũng cần làm rõ rằng Edge AI không thay thế hoàn toàn cloud. Kiến trúc hiệu quả thường cũng có thể là hybrid — thiết bị xử lý tác vụ cần phản hồi tức thời, còn cloud đảm nhiệm huấn luyện, quản lý và phân tích dài hạn.

Nguồn: STMicroelectronics
TAPIT chúc các bạn thành công!

AI TRONG CCSTUDIO 21: CODEX KHÔNG CHỈ GỢI Ý MÃ NGUỒN

Một trợ lý AI có thể viết C/C++. Nhưng nếu không biết cấu trúc project, không nhìn thấy kết quả biên dịch, debugger, SysConfig hay dữ liệu UART, nó vẫn đứng ngoài phần quan trọng nhất của quy trình phát triển hệ thống nhúng.

Đây là điểm đáng chú ý trong CCStudio 21: Texas Instruments đã bổ sung hỗ trợ chính thức cho Codex Agent và cho phép trợ lý AI tương tác với môi trường phát triển thông qua Model Context Protocol – MCP.

Cần hiểu đúng rằng TI không phát triển một mô hình AI mới. CCStudio đóng vai trò cầu nối giữa trợ lý AI bên ngoài và các công cụ phát triển cục bộ trên máy tính.

Kiến trúc tích hợp gồm bốn MCP server chính:

• ccs-project: cung cấp khả năng làm việc với project và quy trình build.

• ccs-debug: kết nối trợ lý AI với các thao tác và trạng thái debug.

• ccs-sysconfig: cho phép làm việc với cấu hình phần cứng trong SysConfig.

• ccs-serial: cung cấp khả năng giám sát và tương tác với giao tiếp serial/UART.

Nhờ đó, một agent không chỉ tạo đoạn mã độc lập mà còn có thể tiếp nhận phản hồi từ chuỗi công cụ phát triển. Ví dụ, agent có thể đề xuất thay đổi mã nguồn, chạy build, đọc lỗi compiler, điều chỉnh cấu hình rồi kiểm tra lại kết quả.

Đây là bước chuyển quan trọng từ “AI code completion” sang một quy trình có vòng phản hồi:

Yêu cầu kỹ thuật → chỉnh sửa mã → build → kiểm tra lỗi → debug hoặc quan sát UART → tiếp tục hiệu chỉnh.

CCStudio hiện hỗ trợ sẵn Claude Code và Codex. Claude Code được TI hỗ trợ từ nhánh 20.5.x, còn Codex được hỗ trợ chính thức từ CCStudio 21.0.0. Các trợ lý tương thích MCP khác có thể được cấu hình thủ công, nhưng chưa được TI kiểm thử đầy đủ như hai lựa chọn trên.

Để dùng Codex, máy tính cần có CCStudio 21 trở lên, Git, tài khoản hoặc API của nhà cung cấp AI và cấu hình sandbox phù hợp. Các MCP server chỉ hoạt động khi CCStudio đang chạy và workspace đã được cấu hình cho AI.

CCStudio còn tự tạo tệp AGENTS.md để cung cấp cho Codex thông tin về vị trí công cụ, thiết bị đang sử dụng và những quy tắc cần tuân thủ. Người dùng có thể bổ sung chỉ dẫn riêng vào phần được dành cho nội dung tùy chỉnh.

Tuy nhiên, “MCP chạy cục bộ” không đồng nghĩa toàn bộ dữ liệu luôn nằm trên máy. TI cho biết phần tích hợp và MCP server chạy local, nhưng prompt, mã nguồn được tham chiếu, thông tin project, kết quả build, trạng thái debug hoặc lịch sử hội thoại có thể được gửi trực tiếp đến nhà cung cấp AI đã cấu hình. Chính sách lưu trữ và sử dụng dữ liệu khi đó phụ thuộc vào nhà cung cấp này.

AI cũng có thể tạo mã sai hoặc chưa hiểu đầy đủ các vi điều khiển mới. Những phần liên quan đến clock, linker, memory map, thanh ghi, timing, điện áp và an toàn hệ thống vẫn cần kỹ sư kiểm chứng trên tài liệu và phần cứng thực tế.

Theo bạn, tính năng nào hữu ích nhất: tự sửa lỗi build, hỗ trợ debug hay phân tích dữ liệu UART?

Cộng đồng Kỹ thuật TAPIT

🔋 TÍNH DÒNG TRUNG BÌNH CỦA THIẾT BỊ IoT QUA 3 BƯỚC

Dòng ngủ thấp là một phần của bài toán tiết kiệm pin. Mỗi lần thiết bị thức dậy để đọc cảm biến, xử lý hoặc truyền dữ liệu đều tiêu tốn thêm điện lượng.

Dưới đây là cách tính cho thiết bị có hoạt động lặp đều.

① ĐO DÒNG NGHỈ VÀ XÁC ĐỊNH CHU KỲ
f
• I_idle: dòng khi toàn bộ thiết bị ở trạng thái nghỉ ổn định.
• T: thời gian từ đầu một lần thức dậy đến đầu lần tiếp theo, gồm cả thời gian hoạt động và nghỉ.

Đo các đại lượng tại cùng điểm cấp nguồn, cùng điện áp và cấu hình. Nếu cần đánh giá mức tiêu thụ từ pin, hãy đo tại đầu pin.

② ĐO ĐIỆN LƯỢNG MỖI LẦN THỨC DẬY

Dùng công cụ đo dòng theo thời gian, chọn cửa sổ từ lúc dòng rời mức nghỉ đến khi trở lại ổn định.

Ghi lại điện lượng tổng Q_event và độ dài cửa sổ T_event, rồi trừ phần điện lượng nền:

ΔQ_event = Q_event − I_idle × T_event

ΔQ_event là điện lượng tăng thêm do sự kiện. Nếu công cụ đã trừ nền, không trừ lần nữa.

③ TÍNH DÒNG TRUNG BÌNH

I_avg = I_idle + ΔQ_event / T

Dùng điện lượng theo µC, thời gian theo giây sẽ được dòng theo µA, vì 1 µC/s = 1 µA.

Giả sử I_idle = 2,84 µA và ΔQ_event = 6,8 µC:

• Thức dậy mỗi 1 giây:
I_avg = 2,84 + 6,8/1 = 9,64 µA.

• Thức dậy mỗi 100 ms:
I_avg = 2,84 + 6,8/0,1 = 70,84 µA.

Giữ nguyên dòng nghỉ và điện lượng mỗi sự kiện, thức dậy thường xuyên gấp 10 lần khiến dòng trung bình bằng khoảng 7,35 lần ban đầu.

📌 ĐO KIỂM LẠI

Với hoạt động tuần hoàn ổn định, chọn cửa sổ đo chứa số nguyên chu kỳ để đối chiếu. Nếu có sự kiện bất chợt hoặc truyền lại, hãy đo đủ lâu để phản ánh hoạt động thực tế.

🛠 Muốn tiết kiệm pin, hãy tối ưu cả dòng nghỉ, điện lượng mỗi lần thức dậy và tần suất — đồng thời đáp ứng yêu cầu của ứng dụng.

Tham khảo: Nordic Developer Academy. Bài chia sẻ này TAPIT dùng ΔQ để phân biệt điện lượng tăng thêm với điện lượng tổng của sự kiện.

Cộng đồng Kỹ thuật TAPIT

ARDUINOCORE-ZEPHYR 1.0.0: KHI SKETCH KHÔNG CÒN LÀ TOÀN BỘ FIRMWARE

Arduino đang thay đổi cách một sketch tồn tại bên trong thiết bị.

Ngày 3/9/2026, Arduino giới thiệu ArduinoCore‑Zephyr 1.0.0. Cùng TAPIT phân tích kiến trúc bên trong tại bài viết này.

Với nhiều Arduino Core truyền thống, sketch, thư viện và core được liên kết thành một firmware hoàn chỉnh rồi ghi xuống vi điều khiển. Ứng dụng gần như chính là toàn bộ chương trình đang chạy trên thiết bị.

ArduinoCore‑Zephyr đi theo mô hình khác.

Một firmware Zephyr được biên dịch sẵn và cài trên bo mạch, đóng vai trò “loader”. Sketch Arduino được tạo thành một tệp ELF độc lập và lưu trong phân vùng `user_sketch`. Khi thiết bị khởi động, loader sử dụng cơ chế LLEXT của Zephyr để nạp ELF, xử lý relocation, phân giải symbol và thực thi chương trình.

Có thể hình dung luồng hoạt động như sau:

SKETCH ELF → ZEPHYR LOADER → PHẦN CỨNG

Kiến trúc này tạo ra ba thay đổi quan trọng.

- Thứ nhất, hệ điều hành nền và logic ứng dụng được tách tương đối rõ. Khi loader hiện tại còn tương thích, hệ thống có thể cập nhật sketch mà không phải thay toàn bộ firmware Zephyr. Nếu phiên bản không khớp, Arduino Core sẽ đồng bộ lại loader trong quá trình nạp chương trình.

- Thứ hai, lập trình viên vẫn có thể sử dụng `setup()`, `loop()`, `digitalWrite()`, SPI hoặc I²C, nhưng bên dưới đã có scheduler, thread, semaphore, timer và driver model của Zephyr. Điều này phù hợp với những ứng dụng phải đồng thời lấy mẫu cảm biến, điều khiển cơ cấu chấp hành, truyền dữ liệu và chạy suy luận Edge AI.

- Thứ ba, phần cứng được mô tả bằng Devicetree và Kconfig. Các chân Arduino như D0, A0, bus UART, SPI, I²C và vùng flash được ánh xạ qua cấu hình của từng bo thay vì gắn chặt toàn bộ logic vào core. Đây là cơ sở để mở rộng sang các nền tảng MCU mới có Zephyr hỗ trợ.

Trong bản 1.0.0, Arduino cập nhật nền tảng lên Zephyr 4.4.1, bổ sung VENTUNO Q và cho phép Nicla Vision thu nhận, xử lý hình ảnh thông qua Zephyr Core. Với VENTUNO Q, phần MCU STM32H5F5 có thể đảm nhiệm điều khiển thời gian thực bên cạnh SoC Qualcomm Dragonwing IQ‑8275 phụ trách khối lượng tính toán lớn hơn.

Tuy nhiên, ArduinoCore‑Zephyr không dành cho toàn bộ bo Arduino. Danh sách hiện tại tập trung vào UNO Q, VENTUNO Q, Portenta H7/C33, Opta, GIGA R1 WiFi, Nano Matter, Nano RP2040 Connect, Nano 33 BLE, Nicla Sense ME và Nicla Vision. UNO R3, UNO R4, Mega 2560 hay các bo ESP32 thông thường vẫn sử dụng core riêng.

Cũng cần lưu ý thêm rằng có RTOS không đồng nghĩa ứng dụng tự động trở thành hệ thống thời gian thực. Độ trễ vẫn phụ thuộc vào cách chia thread, mức ưu tiên, interrupt và driver. Các thư viện truy cập trực tiếp thanh ghi MCU, phụ thuộc Mbed OS hoặc yêu cầu driver chưa được bật trong loader cũng có thể không tương thích.

Theo các bạn, kiến trúc loader–ELF này có đủ sức đưa Arduino từ môi trường thử nghiệm nhanh sang các hệ thống nhúng phức tạp hơn không?

---
Cộng đồng Kỹ thuật TAPIT

Qualcomm Dragonwing Q-2390 và IQ-2390 — kiến trúc AIoT tích hợp CPU, NPU và RISC-V MCU

Một bộ xử lý chạy Linux cho HMI và machine vision, đồng thời có một MCU riêng cho tác vụ thời gian thực — đây là hướng kiến trúc Qualcomm đang đưa xuống phân khúc AIoT chi phí và kích thước hạn chế.

Ngày 01/09/2026, Qualcomm công bố Dragonwing Q-2390 cho thiết bị thương mại/tiêu dùng và IQ-2390 cho hệ thống công nghiệp. Hai nền tảng kết hợp bốn nhân CPU Kryo — một Arm Cortex-A78 và ba Cortex-A55, tốc độ tối đa 1,9 GHz — với GPU Adreno 704, NPU Hexagon và một RISC-V MCU dành cho xử lý thời gian thực.

Kiến trúc này phép phân tách workload rõ hơn: Linux, Ubuntu hoặc Android đảm nhiệm giao diện, kết nối và ứng dụng cấp cao; Zephyr có thể chạy trên RISC-V MCU để xử lý điều khiển hoặc I/O cần tính xác định. Cách tổ chức này phù hợp với HMI công nghiệp, gateway, machine vision, PLC/CNC và hệ thống quản lý năng lượng cần cả giao diện phong phú lẫn phản hồi thời gian thực.

Với IQ-2390, Qualcomm công bố dual Gigabit Ethernet có Time-Sensitive Networking (TSN), NPU 1,1 TOPS, ECC cho bộ nhớ, dải nhiệt độ vận hành từ -30°C đến +115°C và chương trình tuổi thọ sản phẩm đến năm 2036. Q-2390 hướng đến POS, kiosk, thiết bị nhà thông minh và robot gia dụng; biến thể Q-2390M bổ sung LTE Cat 4 và GNSS để triển khai ngoài mạng LAN.

Q-2390 và IQ-2390 hiện thuộc chương trình early access; evaluation kit dự kiến có vào đầu năm 2027. Các ứng dụng mới ngày càng yêu cầu kỹ sư có năng lực thiết kế, tích hợp hệ thống cao hơn phải không các bạn?

Cộng đồng kỹ thuật TAPIT.

Giới thiệu Qualcomm IMSDK 2.0 – Công cụ phát triển sản phẩm AI và đa phương tiện trên các nền tảng Edge AI của Qualcomm

Một camera AI chạy được mô hình chưa có nghĩa là đã trở thành sản phẩm. Thách thức có thể nằm ở bất kỳ vị trí nào trên toàn bộ pipeline: thu hình, tiền xử lý, suy luận trên NPU/GPU, hậu xử lý, hiển thị kết quả, phân tích sự kiện và kết nối hệ thống bên ngoài.

Qualcomm IMSDK 2.0 được xây dựng để hợp nhất chuỗi công việc này trên các nền tảng Edge AI Dragonwing và Qualcomm Linux. Kiến trúc dựa trên GStreamer, kết hợp plugin tăng tốc phần cứng, xử lý đa luồng và đường truyền dữ liệu zero-copy nhằm giảm việc sao chép buffer không cần thiết giữa các khối phần cứng.

Phiên bản 2.0 bổ sung Pipeline API và app builder cho Python, C++, giúp mô tả luồng xử lý ở mức cao hơn. Lập trình viên có thể lựa chọn QAIRT, ONNX Runtime hoặc TensorFlow Lite cho khâu suy luận, trong khi camera, video, âm thanh, tiền xử lý, overlay và analytics vẫn hoạt động trong cùng một kiến trúc. IMSDK 2.0 cũng cung cấp các microservice dạng container, hỗ trợ kết nối Kafka, MQTT, AWS IoT và Azure IoT để xây dựng hệ thống Edge AI hoàn chỉnh.

IMSDK không tự động làm mọi mô hình chạy nhanh. Hiệu năng vẫn phụ thuộc vào phần cứng, kiến trúc mô hình, runtime, mức lượng tử hóa và cách tổ chức pipeline. Lợi ích khi sử dụng IMSDK 2.0 là rút ngắn khoảng cách từ một bản demo AI đến camera, robot hoặc edge gateway có thể triển khai thực tế.

Theo bạn, nút thắt lớn nhất của Edge AI hiện nay nằm ở mô hình hay khâu tích hợp?

TAPIT chúc các bạn thành công!

🛰️ IoT ngoài vùng phủ sóng: Cellular và Satellite trên cùng một nền tảng

Nordic Semiconductor vừa công bố embedded modem MTC2-N9151 của LooUQ đã đạt chứng nhận Skylo NTN, dựa trên nền tảng nRF9151. MTC2-N9151 cho phép thiết bị IoT sử dụng:
+ LTE-M / NB-IoT → mạng mặt đất Terrestrial Networks (TN) ) và mạng phi mặt đất
+ NB-NTN → mạng vệ tinh theo chuẩn 3GPP, Non-Terrestrial Networks
với khả năng tự động chuyển giữa cellular và dịch vụ vệ tinh Skylo tùy vùng phủ sóng mà không yêu cầu thay đổi phần mềm ứng dụng.

Nền tảng nRF9151 tích hợp Arm Cortex-M33 64 MHz, 1 MB Flash, 256 KB RAM, GNSS và modem hỗ trợ LTE-M, NB-IoT, NB-NTN cùng DECT NR+. Trong đó, DECT NR+ là công nghệ vô tuyến riêng cho các mạng NR+/mesh, không phải kết nối vệ tinh.

LooUQ đóng gói nRF9151 thành module MTC2-N9151 kích thước 40 × 30 mm, với 32 I/O, giúp đơn giản hóa việc tích hợp vào sản phẩm. Nordic cho biết thiết kế mới chỉ cần thêm hai linh kiện ngoài và có thể sử dụng chung một giải pháp antenna cho LTE mặt đất và các băng NB-NTN.

Đã có ứng dụng thực tế triển khai áp dụng là HydroProxy của Remsight: các sensor node chạy năng lượng mặt trời giám sát hạ tầng tưới tiêu ở miền Tây nước Mỹ, nơi mạng cellular chưa ổn định.

👉 Để thiết kể một giải pháp IoT phải hoạt động nhiều năm ngoài hiện trường, các bạn phải thực hiện chọn modem, tối ưu đồng thời kết nối TN/NTN, antenna, năng lượng tiêu thụ và chứng nhận thiết bị.

TAPIT Chúc các bạn thành công!