- Trong phát triển hệ thống nhúng, Lua mang lại độ ổn định và khả năng mở rộng cao hơn MicroPython
- Lua có cấu trúc dễ tích hợp với C, nhẹ và mang tính quyết định, đồng thời cho thấy nhiều lợi thế hơn về khả năng bảo trì mã và giảm chi phí dài hạn
- MicroPython phù hợp cho tạo mẫu nhanh, nhưng dễ chạm tới giới hạn trong các dự án quy mô lớn hoặc môi trường production
- Lua có thể được build thành tệp thực thi nhỏ gọn và hiệu quả, vận hành mà không cần tính năng dư thừa, đồng thời có khả năng mở rộng và bảo trì cao từ giai đoạn tạo mẫu đến thương mại hóa sản phẩm
- Xedge Framework tối ưu hóa Lua cho hệ thống nhúng, cung cấp mạnh mẽ các tính năng IoT và web
Lua vs. MicroPython trong môi trường nhúng chuyên nghiệp
- Trong các dự án nhúng chuyên nghiệp như tự động hóa công nghiệp, thiết bị y tế, IoT thương mại, xu hướng ngày càng ưu tiên một môi trường cấp cao nhưng gọn nhẹ
- MicroPython có thế mạnh ở tạo mẫu nhanh và triển khai tại hiện trường, nhưng hệ sinh thái chủ yếu xoay quanh các bo mạch dành cho người chơi/học tập
- Các thư viện lớn như NumPy, pandas vốn là thế mạnh của Python không có trong MicroPython, và thư viện chuẩn cũng bị cắt giảm đáng kể
- Việc tích hợp với các extension C trong MicroPython cũng tương đối phức tạp
- Lua lấy tích hợp với ứng dụng C làm triết lý cốt lõi
- Cung cấp C API ổn định, tối giản và máy ảo bytecode
- Có thể dễ dàng đưa các hàm và cấu trúc dữ liệu C/C++ vào Lua
- Thư viện Lua ANSI C được thiết kế cho nhúng nên có cấu trúc gọn, nhẹ, mang tính quyết định
- MicroPython là bản hiện thực lại của Python 3, vẫn mang các giả định của một ngôn ngữ hướng desktop, nên giới hạn bộc lộ nhanh hơn trong môi trường tài nguyên hạn chế
Kết nối C liền mạch là cốt lõi của Lua
- Ưu điểm lớn nhất của Lua là tích hợp mượt mà với C
- API ổn định và tối giản, đồng thời có thể dễ dàng đưa các hàm C/C++ và cấu trúc dữ liệu riêng vào Lua
- MicroPython cũng hỗ trợ extension C, nhưng cần build firmware tùy biến và quy trình làm việc phức tạp hơn
- Với Lua, khả năng liên kết với C chính là triết lý thiết kế
- Có thể dùng thủ công Lua C API hoặc tận dụng các công cụ binding tự động như SWIG để gọi hàm/cấu trúc C từ Lua
- Logic cần hiệu năng của C có thể viết bằng C, còn logic nghiệp vụ cấp cao viết bằng Lua để tăng khả năng bảo trì và mở rộng
Dung lượng tối thiểu và khả năng mở rộng
- Lua có trình thông dịch lõi rất nhỏ, và có thể dễ dàng loại bỏ các tính năng không cần thiết
- MicroPython cũng được tối ưu cho nhúng, nhưng ảnh mặc định lớn hơn, và dung lượng còn tăng khi bật các module cần thiết
- Cả hai đều phù hợp cho tạo mẫu nhanh, nhưng Lua có khả năng mở rộng tốt hơn tới production
- Lua giúp dễ thiết kế cấu trúc tách biệt giữa tầng cấp cao và cấp thấp, nên sau khi phát triển prototype nhanh có thể tiến hóa thành kiến trúc hybrid dễ bảo trì
- Ngay từ đầu, Lua có thể kết hợp với mã C để scale up tự nhiên mà không làm đứt gãy luồng phát triển
- Với MicroPython, sau giai đoạn prototype có thể phải viết lại logic lõi hoặc sớm chạm giới hạn
Hệ sinh thái và khả năng tiếp cận thư viện - Quality Over Quantity
- MicroPython có hệ sinh thái sôi động xoay quanh phần cứng cho người chơi/học tập như bo Wi‑Fi, nhưng thiếu các thư viện chủ lực của hệ sinh thái Python lớn
- Lua tuy ít thư viện hơn, nhưng có thể mở rộng dễ dàng bằng C, nên ít vướng vào giới hạn hệ sinh thái hơn
Lợi thế về bảo trì và chi phí
- Lua có codebase nhỏ, dễ kiểm thử, debug và bàn giao
- Khi dự án mở rộng, việc duy trì tách lớp giữa script Lua và lõi C giúp thuận lợi cho bàn giao và cộng tác
- MicroPython cũng dễ đọc, nhưng khi dự án lớn dần, mã hệ thống và tầng script có xu hướng trộn lẫn, khiến chi phí bảo trì tăng lên
Kết luận: Choose What Scales
- Nếu mục tiêu là giáo dục và tạo mẫu, MicroPython vẫn là một lựa chọn rất tốt
- Với các sản phẩm nhúng mà bảo mật, độ tin cậy và khả năng bảo trì là quan trọng, Lua thực tế hơn và đồng thời mang lại khả năng mở rộng, tính linh hoạt và độ ổn định
- Lua không chỉ là một ngôn ngữ script đơn thuần, mà là một chiến lược phát triển nhúng
Cách tích hợp thư viện Lua C trên thiết bị nhúng
- Thư viện Lua C nhẹ, tương thích ANSI C, và hầu như không phụ thuộc ngoài thư viện chuẩn C
- Phù hợp với hệ thống bare-metal và RTOS, tuy nhiên một số thành phần như stdin/stdout của C chuẩn cần được lưu ý khi port
-
Xedge Framework của Real Time Logic
- Xedge Framework cung cấp runtime Lua và bộ API được tối ưu cho môi trường nhúng
- Tích hợp sẵn các tính năng IoT/web như giao tiếp bảo mật với TLS, MQTT5, WebSocket, dịch vụ web RESTful, xử lý dữ liệu thời gian thực, cùng các giao thức Modbus/OPC UA
- Vẫn giữ được tính linh hoạt và gọn nhẹ của Lua, đồng thời cung cấp một framework nhúng hoàn chỉnh có thể đưa vào thực chiến
- Nếu muốn nhúng Lua vào sản phẩm nhúng, Xedge là lựa chọn thực tiễn nhất: đơn giản hóa tích hợp, tăng tốc phát triển và giúp tập trung vào logic khác biệt
2 bình luận
Ngay từ đầu, các nhà sản xuất linh kiện làm ra thiết bị vốn đã không hỗ trợ tốt cả Lua lẫn Python. Cùng lắm là mức C?
Ý kiến trên Hacker News
Khi quyết định làm một game engine và viết toàn bộ trò chơi bằng ngôn ngữ kịch bản, tôi đã cân nhắc giữa ba lựa chọn: JavaScript(QuickJS), Python(Boost.Python) và Lua(Sol2)
Việc nhúng Lua thực sự rất dễ, và dùng cùng wrapper C++ cũng cực kỳ thuận tiện
Chỉ sau không lâu đã có được một engine ở mức "có thể dùng ngay được"
Hơn nữa, Lua VM rất nhẹ
Có thể xem chi tiết trong dự án carimbo
Tôi thích ở chỗ nếu thấy engine hay ứng dụng nào hỗ trợ Lua làm scripting thì có thể dùng Fennel
Fennel là một ngôn ngữ transpile sang Lua
Liên kết chính thức của Fennel
Cá nhân tôi thấy Boost.Python không phù hợp lắm làm công cụ scripting
Điều này cũng có thể ảnh hưởng tới nhận định
Tôi tò mò không biết Sol2 có phải là một Lua VM hay chỉ đơn thuần là wrapper cho Lua VM tiêu chuẩn
Tôi thấy khó đồng tình với câu kiểu "Lua không chỉ là một ngôn ngữ bậc cao đơn giản mà là một chiến lược phát triển nhúng"
Những bài viết dùng kiểu diễn đạt như vậy khá khó để tiếp nhận một cách nghiêm túc
Tổng thể thì đây là kiểu bài mang cảm giác "tôi đã dùng Lua lâu năm nên giờ có thể kết luận"
Nhưng có vẻ tác giả không có nhiều trải nghiệm thực tế với MicroPython mà lại đưa ra một số phê phán hơi cường điệu
Ví dụ như nhận định "dự án MicroPython trộn lẫn mã hệ thống và lớp script nên khó bảo trì" là khá thiếu cơ sở
Có thể đó là ảnh hưởng từ ngôn ngữ, hoặc từ cách quản lý dự án/cấu trúc thiết kế, nên nguyên nhân cần được đánh giá chặt chẽ hơn
Bài này tạo cảm giác giống quảng cáo cho framework Xedge Lua hơn là một bài viết thực sự
Nói thẳng ra thì chỉ là quảng cáo
Nhìn chung bài viết có phong cách rất giống chatgpt
Với một bài quảng cáo thì do con người hay LLM viết có lẽ cũng chẳng khác biệt gì
Như các bình luận khác cũng đã nói, nó có cảm giác chatgpt nên đọc không mấy thú vị
Trong danh sách PLDB Top 1000, Lua xếp hạng cao hơn MicroPython
Trong bài so sánh này, người dùng Github SkipKaczinksi cho rằng Lua nhìn chung nhanh hơn
Michael Polia trong bài trên Hackaday cũng nhắc rằng Lua nhỏ và nhanh
Ngôn ngữ Toit tuyên bố nhanh hơn MicroPython 30 lần
Nhà sáng lập Toit từng là người phụ trách phát triển giai đoạn đầu của V8
Cần phân biệt giữa khái niệm "embedded" và "embeddable"
MicroPython được dùng trên các nền tảng nhúng, nhưng không phải là một "runtime có thể nhúng" vào ứng dụng sẵn có như Lua
Mục tiêu của MicroPython là thay thế runtime C truyền thống: chỉ cần khởi tạo bằng một wrapper C tối thiểu, rồi viết phần logic nghiệp vụ còn lại bằng script MicroPython
Nó không có cấu trúc như
lua_Statecủa Lua để chạy đồng thời nhiều interpreter hay làm sandboxNói cách khác, MicroPython tối ưu cho kiểu "đọc dữ liệu cảm biến bằng Python trên bo mạch IoT" hơn là "lặp phát triển nhanh bằng script trong game engine"
Không thể dùng hoàn toàn nguyên hộp, và vẫn cần một ít glue code
Có thể tham khảo ví dụ cổng embed
Tôi nghĩ Lua là một ngôn ngữ rất tốt cả cho mục đích nhúng
Tôi cũng đánh giá cao các sản phẩm dựa trên Lua, nhưng bài này không thuyết phục được về chuyện "vì sao Lua thắng MicroPython"
Việc mở rộng MicroPython bằng C dễ hơn nhiều người nghĩ, chỉ cần phát triển mô-đun ngoài theo đúng cách mà các mô-đun chính thức được làm
Vì vậy có thể thêm vào khá dễ khi custom build firmware
Và dù có ý kiến rằng không dùng được các thư viện hệ Python như numpy, thực tế vẫn có thư viện ulab tái hiện một phần của numpy và scipy
Những gì tôi nghe được mang nặng màu sắc tiếp thị
Nếu vi điều khiển có đủ tài nguyên thì tôi dùng micropython
Nếu điện năng, bộ nhớ và kiểm soát CPU thực sự quan trọng thì cuối cùng vẫn dùng C/C++
Phát triển liên quan đến mạng trong C/C++ vốn khó, và trước đây thiếu các lựa chọn vừa nhanh vừa an toàn để làm việc đó (gần đây chắc hỗ trợ TLS tích hợp cũng đã tốt hơn)
Lua cho cảm giác như một lớp bọc mượt hơn quanh C
Nếu hệ thư viện phong phú thì rất tốt, nhưng gánh nặng là phải tự port toàn bộ toolchain Lua, toolchain vi điều khiển và các thư viện cần thiết
Vì thế nếu đây là bài tiếp thị thì tôi nghĩ thông điệp là hãy dùng sản phẩm Xedge rồi thuê ngoài
chỉ nhắc ngắn gọn rằng nó vẫn chạy tốt cả trên 2350
Tôi tự hỏi liệu có ai thực sự dùng micropython hay lua cho phát triển nhúng một cách "nghiêm túc" không
Tôi đã làm sản phẩm nhúng freelance xoay quanh Lua gần 20 năm
Tôi đã dùng Lua trong nhiều lĩnh vực như thiết bị VOIP, tự động hóa gia đình, router công nghiệp, đầu ghi hình số v.v.
Thông thường hệ thống gồm Linux kernel, libc, Lua interpreter và một vài thư viện bên ngoài
Mã nguồn ứng dụng Lua khoảng 30.000~100.000 dòng; theo tiêu chuẩn ngày nay thậm chí có những sản phẩm được xem là "nhỏ" (flash 8MB, RAM 64MB, v.v.)
Lua hoạt động rất tốt trong những môi trường như vậy
Tất cả đều là sản phẩm đang vận hành thực tế và vẫn tạo ra doanh thu cho khách hàng
Việc kết nối Lua với C rất dễ, và trong xử lý bất đồng bộ, Lua đã giải quyết từ lâu những vấn đề mà các ngôn ngữ hiện đại vẫn còn đang loay hoay
Ngôn ngữ này đơn giản nhưng mạnh mẽ, và với coroutine, closure, metatable v.v. có thể áp dụng nhiều mô hình lập trình khác nhau
Với các dự án ở quy mô này, tôi vẫn sẽ chọn kết hợp Lua + C/C++
Tôi cũng đã thử các hệ sinh thái khác như Elixir, Rust, Nim, nhưng chưa thấy ngôn ngữ nào mạnh và linh hoạt như Lua
Chúng tôi thậm chí còn đang phát triển thiết bị y tế class B bằng MicroPython
Thế giới embedded có phạm vi rất rộng
Nếu liên quan đến an toàn thì có thể bị cấm theo quy định, nhưng thiết bị kiểm thử chẳng hạn thì không bị ràng buộc như vậy nên người ta dùng thứ gì tiện nhất
Ngay cả trong lĩnh vực IoT cũng có thể xem như ai cũng dùng thứ mình thấy thuận tiện
MicroPython thực sự còn được dùng cả trong các nhiệm vụ vệ tinh như cubesat
Cũng có các ví dụ liên quan trong hội nghị và podcast
Hàng nghìn sản phẩm đang dùng Lua ở bên trong, hoặc ít nhất là ở một phần nào đó
Gần đây tôi cũng tìm hiểu LuaJIT và thấy nó bị đánh giá thấp
Tôi nghĩ phần lớn "nhà phát triển embedded nghiêm túc" đều dùng ngôn ngữ biên dịch
Làm hobby thì tôi cứ dùng Arduino(Platformio)
Trên vi điều khiển, việc biên dịch rồi nạp flash diễn ra nhanh nên không thực sự cần interpreter
Một ngày nào đó tôi cũng muốn thử một ngôn ngữ biên dịch khác có thể thay thế C++
Không biết có ngôn ngữ nào chạy tốt trên Raspberry Pi Pico để gợi ý không
Tôi không đến mức chuyên gia, nhưng cảm giác Rust là một trong những lựa chọn thay thế phổ biến nhất
Nó hợp xu hướng, sửa được nhiều vấn đề của C++, và tooling cũng khá ổn
Zig cũng có vẻ thú vị nên tôi muốn thử
Raspberry Pi có cấu hình khá tốt nên ngay cả ngôn ngữ không phải system language cũng có thể chạy được
Tôi cũng thích Kotlin; về cơ bản cần JVM nhưng có thể build native
Tuy vậy trên Pico, để điều khiển GPIO có thể phải thao tác trực tiếp với filesystem (nói thêm là tôi cũng không chắc Kotlin có được hỗ trợ trên Pico hay không)
Nim có vẻ là một lựa chọn khá ổn
Có thể tham khảo hỗ trợ Nim của picostdlib
Lua về bản chất là một ngôn ngữ đơn giản hơn rất nhiều
Python đề cao niềm tin "chỉ có một cách để làm", nhưng trên thực tế lại mang cảm giác như một "dao đa năng" nhét đủ thứ vào
Điều này khiến nó dễ bắt đầu hơn, thư viện cũng phong phú nên phát triển dễ hơn
Nhưng nó không thực sự hợp với môi trường tài nguyên hạn chế
Một chiếc ghế cầu kỳ cũng chỉ có thể biến thành ghế Eames bằng ván gỗ tới một mức nào đó thôi
Python thì dễ, còn Lua thì đơn giản
Vấn đề của "dễ" là sự phức tạp bên trong bị che đi, còn "đơn giản" nghĩa là người dùng phải tự bỏ ra nhiều công sức hơn
Python có tính tương thích phiên bản khá yếu, nên khi chuyển từ 3.x sang 3.x+1 thường hay phát sinh vấn đề
Lua cũng không hoàn hảo, nhưng vẫn có lợi thế là nhiều trường hợp hỗ trợ được nhiều phiên bản Lua khác nhau nên không bị ép nâng cấp phiên bản quá đột ngột