- ในการพัฒนา ระบบฝังตัว นั้น Lua มอบทั้งความเสถียรและความสามารถในการขยายระบบได้ดีกว่า MicroPython
- Lua มีโครงสร้างที่ ผสานกับ C ได้ง่าย มีขนาดเบา และเป็นแบบกำหนดผลลัพธ์ได้แน่นอน จึงให้ข้อได้เปรียบมากกว่าในด้าน การดูแลรักษาโค้ด และ การลดต้นทุนระยะยาว
- MicroPython เหมาะกับการทำต้นแบบอย่างรวดเร็ว แต่เมื่อเป็น โปรเจกต์ขนาดใหญ่หรือสภาพแวดล้อมระดับโปรดักชัน ก็จะเริ่มเจอข้อจำกัด
- Lua สามารถคอมไพล์เป็น ไฟล์รันไทม์ขนาดเล็กและมีประสิทธิภาพ ทำงานได้โดยไม่มีฟีเจอร์ส่วนเกิน และมีทั้งความสามารถในการขยายและการบำรุงรักษาที่ดีตั้งแต่ การทำต้นแบบไปจนถึงการพัฒนาเป็นผลิตภัณฑ์
- Xedge Framework ปรับแต่ง Lua ให้เหมาะกับระบบฝังตัว พร้อมมอบความสามารถด้าน IoT และเว็บที่ทรงพลัง
Lua vs. MicroPython ในสภาพแวดล้อม Embedded ระดับมืออาชีพ
- ใน โปรเจกต์ embedded ระดับมืออาชีพ เช่น ระบบอัตโนมัติภาคอุตสาหกรรม อุปกรณ์การแพทย์ และ IoT เชิงพาณิชย์ แนวโน้มคือหันมาใช้ สภาพแวดล้อมระดับสูงที่ยังคงน้ำหนักเบา มากขึ้น
- MicroPython เด่นเรื่องการทำต้นแบบอย่างรวดเร็วและการนำไปใช้งานภาคสนาม แต่ ระบบนิเวศยังเน้นบอร์ดสายงานอดิเรก/การศึกษาเป็นหลัก
- ไลบรารีขนาดใหญ่ที่เป็นจุดแข็งของ Python อย่าง NumPy, pandas ไม่มีใน MicroPython และ แม้แต่ไลบรารีมาตรฐานก็ถูกลดทอนลงอย่างมาก
- การผสานกับ C extension ก็ยังค่อนข้างซับซ้อนสำหรับ MicroPython
- Lua ยึดถือ การผสานเข้ากับแอปพลิเคชัน C เป็นปรัชญาหลักตั้งแต่ต้น
- มี C API ที่เสถียรและมินิมัล พร้อมเครื่องเสมือนแบบไบต์โค้ด
- สามารถเปิดเผยฟังก์ชันและโครงสร้างข้อมูลของ C/C++ ให้ Lua ใช้งานได้อย่างง่ายดาย
- ไลบรารี Lua ANSI C ถูกออกแบบมาเพื่อ embedded โดยเฉพาะ จึงมีโครงสร้างที่ กระชับ เบา และกำหนดพฤติกรรมได้แน่นอน
- MicroPython เป็นการนำ Python 3 มาสร้างใหม่ จึงยังคงสมมติฐานของภาษาที่ออกแบบมาเพื่อเดสก์ท็อปอยู่ ทำให้ ข้อจำกัดในสภาพแวดล้อมที่ทรัพยากรจำกัดปรากฏชัดได้เร็วกว่า
การเชื่อมต่อกับ C แบบไร้รอยต่อคือหัวใจของ Lua
- จุดแข็งที่สุดของ Lua คือ การผสานกับ C ได้อย่างลื่นไหล
- API มีความ เสถียรและเรียบง่าย และสามารถ เปิดเผยฟังก์ชัน C/C++ และโครงสร้างข้อมูลของตัวเองให้ Lua ใช้ได้อย่างง่ายดาย
- แม้ MicroPython จะรองรับ C extension เช่นกัน แต่ต้อง คอมไพล์เฟิร์มแวร์แบบกำหนดเอง และเวิร์กโฟลว์ก็ซับซ้อนกว่า
- สำหรับ Lua นั้น การเชื่อมต่อกับ C คือส่วนหนึ่งของปรัชญาการออกแบบ
- สามารถใช้ Lua C API แบบ เขียนเองโดยตรง หรือใช้เครื่องมือสร้าง binding อัตโนมัติอย่าง SWIG เพื่อให้ เรียกใช้ฟังก์ชัน/struct ของ C จาก Lua ได้
- ลอจิกที่ต้องการประสิทธิภาพสูงสามารถเขียนด้วย C ส่วนลอจิกธุรกิจระดับสูงเขียนด้วย Lua เพื่อเพิ่มทั้ง ความสามารถในการดูแลรักษา และ การขยายระบบ
ฟุตพรินต์ขนาดเล็กและความสามารถในการขยาย
- Lua มี ตัวอินเทอร์พรีเตอร์แกนกลางขนาดเล็กมาก และสามารถตัดฟีเจอร์ที่ไม่จำเป็นออกได้ง่าย
- แม้ MicroPython จะถูกปรับให้เหมาะกับ embedded เช่นกัน แต่ อิมเมจพื้นฐานมีขนาดค่อนข้างใหญ่ และเมื่อเปิดใช้โมดูลจำเป็นก็ยิ่งกินพื้นที่มากขึ้น
- ทั้งคู่เหมาะกับ การทำต้นแบบอย่างรวดเร็ว แต่ Lua ขยายต่อไปถึงระดับโปรดักชันได้ดีกว่า
- Lua ออกแบบโครงสร้าง แยกส่วนระดับสูง-ระดับต่ำ ได้ง่าย จึงสามารถพัฒนาต้นแบบได้เร็ว แล้วค่อยต่อยอดเป็น สถาปัตยกรรมไฮบริดที่ดูแลรักษาได้จริง
- Lua สามารถผสานเข้ากับโค้ด C ได้ตั้งแต่แรก ทำให้ การสเกลอัปเป็นไปอย่างเป็นธรรมชาติและโฟลว์การพัฒนาไม่สะดุด
- ส่วน MicroPython หลังผ่านช่วงต้นแบบไปแล้ว อาจต้องเขียนลอจิกหลักใหม่หรือเริ่มเจอข้อจำกัด
การเข้าถึงระบบนิเวศและไลบรารี - Quality Over Quantity
- MicroPython มีระบบนิเวศที่คึกคักในกลุ่ม ฮาร์ดแวร์สายงานอดิเรก/การศึกษา เช่น บอร์ด Wi‑Fi แต่ ขาดไลบรารีสำคัญจากระบบนิเวศ Python ขนาดใหญ่
- Lua แม้จะ มีจำนวนไลบรารีน้อยกว่า แต่ขยายด้วย C ได้ง่าย จึงชนเพดานของระบบนิเวศน้อยกว่า
ข้อดีด้านการบำรุงรักษาและต้นทุน
- Lua มี โค้ดเบสขนาดเล็ก ทดสอบ ดีบัก และส่งต่องานได้ง่าย
- เมื่อโปรเจกต์ขยายตัว ก็ยังสามารถรักษา การแยกเลเยอร์ระหว่างสคริปต์ Lua กับแกน C เอาไว้ได้ดี ซึ่งเป็นประโยชน์ต่อการส่งต่องานและการทำงานร่วมกัน
- แม้ MicroPython จะอ่านโค้ดได้ง่ายเช่นกัน แต่ เมื่อโปรเจกต์ใหญ่ขึ้น มักมีแนวโน้มที่โค้ดระบบและเลเยอร์สคริปต์จะปะปนกัน ทำให้ต้นทุนการบำรุงรักษาสูงขึ้นได้
บทสรุป: Choose What Scales
- หากมีเป้าหมายเพื่อ การศึกษาและการทำต้นแบบ MicroPython ก็ยังเป็นตัวเลือกที่ยอดเยี่ยม
- แต่สำหรับ ผลิตภัณฑ์ embedded ที่ให้ความสำคัญกับความปลอดภัย ความน่าเชื่อถือ และการบำรุงรักษา Lua ใช้งานได้จริงมากกว่า และ มอบทั้งการขยายระบบ ความยืดหยุ่น และความเสถียรในเวลาเดียวกัน
- Lua ไม่ได้เป็นเพียงภาษา scripting แต่เป็นกลยุทธ์สำหรับการพัฒนา embedded
วิธีผสาน Lua C library เข้ากับอุปกรณ์ embedded
- Lua C library มีคุณสมบัติ น้ำหนักเบา เข้ากันได้กับ ANSI C และแทบไม่พึ่งพาสิ่งอื่นนอกจากไลบรารีมาตรฐานของ C
- เหมาะกับระบบ bare-metal และระบบที่ใช้ RTOS แต่ระหว่างการพอร์ตต้องระวังองค์ประกอบบางอย่างของมาตรฐาน C เช่น stdin/stdout
-
Xedge Framework ของ Real Time Logic
- Xedge Framework มอบทั้ง Lua runtime และชุด API ที่ปรับแต่งมาเพื่อสภาพแวดล้อม embedded
- มีความสามารถด้าน IoT/เว็บ ในตัว เช่น การสื่อสารแบบปลอดภัยด้วย TLS, MQTT5, WebSocket, เว็บเซอร์วิสแบบ RESTful, การประมวลผลข้อมูลแบบเรียลไทม์ และโปรโตคอล Modbus/OPC UA
- ยังคงรักษา ความยืดหยุ่นและความเบาของ Lua พร้อมมอบ เฟรมเวิร์ก embedded แบบพร้อมใช้งานจริงในงานภาคสนาม
- หากต้องการฝัง Lua ลงในผลิตภัณฑ์ embedded, Xedge คือ ตัวเลือกที่ใช้งานได้จริงที่สุด ช่วยให้การผสานระบบง่ายขึ้น เร่งความเร็วการพัฒนา และทำให้นักพัฒนามุ่งเน้นกับลอจิกที่สร้างความแตกต่างได้
2 ความคิดเห็น
ตั้งแต่แรกแล้ว ผู้ผลิตชิ้นส่วนที่ทำอุปกรณ์ก็มักจะไม่ค่อยรองรับทั้ง Lua หรือ Python ดีเท่าไร อย่างมากก็ระดับ C?
ความคิดเห็นจาก Hacker News
ตอนที่ตัดสินใจว่าจะสร้างเกมเอนจินและเขียนทั้งเกมด้วยภาษา scripting กำลังชั่งใจอยู่ระหว่าง JavaScript(QuickJS), Python(Boost.Python) และ Lua(Sol2)
การ embed Lua นั้นง่ายมาก และถึงจะใช้ร่วมกับ C++ wrapper ก็ยังสะดวกมาก
ใช้เวลาไม่นานก็ได้เอนจินที่รู้สึกว่า "ระดับนี้พร้อมใช้งานได้เลย"
แถม Lua VM ก็เบามาก
รายละเอียดดูได้ที่ โปรเจกต์ carimbo
ชอบตรงที่ถ้าเห็นว่าเอนจินหรือแอปพลิเคชันรองรับ Lua เป็นสคริปต์ ก็หมายความว่าสามารถใช้ Fennel ได้
Fennel เป็นภาษาที่ transpile ไปเป็น Lua
ลิงก์ทางการของ Fennel
ส่วนตัวคิดว่า Boost.Python ไม่ค่อยดีนักในฐานะเครื่องมือสคริปต์
จุดนี้อาจมีผลต่อการตัดสินใจก็ได้
สงสัยว่า Sol2 เป็น Lua VM เอง หรือเป็นแค่ wrapper ของ Lua VM มาตรฐาน
รู้สึกวลีที่ว่า "Lua ไม่ใช่แค่ภาษาระดับสูงที่เรียบง่าย แต่เป็นกลยุทธ์การพัฒนาแบบ embedded" ฟังไม่ค่อยน่าเชื่อ
บทความที่ใช้ถ้อยคำแบบนี้ทำให้รู้สึกยากจะรับอย่างจริงจัง
โดยรวมแล้วเป็นบทความแนว "ฉันใช้ Lua มานานพอแล้ว เลยสรุปได้"
แต่ดูเหมือนจะมีประสบการณ์กับ MicroPython จริง ๆ ไม่มากนัก แถมมีคำวิจารณ์ที่ดูเกินจริงอยู่หลายจุด
เช่นคำพูดว่า "โปรเจกต์ MicroPython ทำให้โค้ดระบบกับชั้นสคริปต์ปะปนกันจนดูแลรักษายาก" ก็ดูมีหลักฐานรองรับน้อย
มันอาจเป็นผลจากตัวภาษาเอง หรือจากการจัดการโปรเจกต์/การออกแบบโครงสร้างก็ได้ ดังนั้นควรประเมินสาเหตุอย่างเคร่งครัดกว่านี้
บทความนี้ให้ความรู้สึกเหมือนโฆษณาเฟรมเวิร์ก Xedge Lua มากกว่าจะเป็นบทความจริง ๆ
มันก็แค่โฆษณา
โดยรวมแล้วสไตล์บทความเหมือน chatgpt
ถ้าเป็นบทความโฆษณา จะเขียนโดยคนหรือ LLM ก็ดูไม่ต่างกันเท่าไร
อย่างที่คอมเมนต์อื่นพูดไว้ มันให้ความรู้สึกแบบ chatgpt เลยทำให้อ่านแล้วไม่ค่อยเพลิน
ในลิสต์ PLDB Top 1000 Lua อยู่สูงกว่า MicroPython
ในบทความเปรียบเทียบนี้ ผู้ใช้ Github ชื่อ SkipKaczinksi มองว่าโดยทั่วไป Lua เร็วกว่า
Michael Polia ในบทความของ Hackaday ก็พูดถึงว่า Lua เล็กและเร็ว
ภาษา Toit อ้างว่าเร็วกว่า MicroPython 30 เท่า
ผู้ก่อตั้ง Toit เคยเป็นหัวหน้าฝ่ายพัฒนาช่วงแรกของ V8
ควรแยกความต่างระหว่าง "embedded" กับ "embeddable"
MicroPython ใช้บนแพลตฟอร์ม embedded ก็จริง แต่ไม่ใช่ "runtime ที่ embed ได้" เพื่อเอาไปรวมกับแอปพลิเคชันเดิมแบบ Lua
เป้าหมายของ MicroPython คือแทนที่ C runtime แบบดั้งเดิม โดยให้มี C wrapper ขั้นต่ำเพื่อเริ่มต้นระบบ แล้วเขียน business logic ที่เหลือเป็นสคริปต์ MicroPython
มันไม่มีโครงสร้างแบบ lua_State ของ Lua ที่เปิดให้ใช้ interpreter หลายตัวพร้อมกันหรือทำ sandboxing ได้
พูดอีกแบบคือ MicroPython เหมาะกับ "อ่านข้อมูลเซนเซอร์บนบอร์ด IoT ด้วย Python" มากกว่า "ทำ iterative development อย่างรวดเร็วด้วยสคริปต์ภายในเกมเอนจิน"
มันไม่ใช่ของที่หยิบออกมาใช้นอกกรอบได้ทันทีทั้งหมด และยังต้องมี glue code อยู่บ้าง
ดูตัวอย่างได้จาก embed port example
คิดว่า Lua เป็นภาษาที่ยอดเยี่ยมสำหรับงาน embedded เช่นกัน
และผลิตภัณฑ์ที่ใช้ Lua ก็เป็นเรื่องที่ดี แต่บทความนี้อธิบายได้ไม่ค่อยน่าเชื่อว่าทำไม "Lua ถึงชนะ MicroPython"
การขยายความสามารถของ MicroPython ด้วย C นั้นจริง ๆ แล้วง่ายกว่าที่คิด และถ้าพัฒนา external module แบบเดียวกับโมดูลทางการก็ทำได้
ดังนั้นเวลา custom build เฟิร์มแวร์ก็ใส่เพิ่มเข้าไปได้ไม่ยาก
และแม้จะมีคนบอกว่าใช้ไลบรารีฝั่ง Python อย่าง numpy ไม่ได้ แต่ในความเป็นจริงก็มีไลบรารี ulab ที่ reimplement บางส่วนของ numpy และ scipy อยู่แล้ว
สิ่งที่ผมเคยได้ยินฟังดูเหมือนคำพูดทางการตลาด
ถ้าบนไมโครคอนโทรลเลอร์มีทรัพยากรพอ ก็จะใช้ micropython
แต่ถ้าพลังงาน หน่วยความจำ และการควบคุม CPU สำคัญจริง ๆ สุดท้ายก็ใช้ C/C++
งานด้านเครือข่ายใน C/C++ ทำได้ยาก แต่ก็เคยมีตัวเลือกที่ทำได้เร็วและปลอดภัยไม่มากนัก (ช่วงหลังนี้การรองรับ TLS ในตัวก็น่าจะดีขึ้นแล้ว)
Lua ให้ความรู้สึกเหมือนการห่อ C ให้นุ่มนวลขึ้น
ถ้ามีไลบรารีพร้อมก็ดี แต่ภาระในการพอร์ต Lua toolchain, toolchain ของไมโครคอนโทรลเลอร์ และไลบรารีที่ต้องใช้ทั้งหมดนั้นค่อนข้างมาก
เพราะงั้นถ้านี่เป็นบทความการตลาด ผมก็เข้าใจสารที่ซ่อนอยู่ว่าให้ใช้ผลิตภัณฑ์ Xedge แล้วจ้างคนนอกมาทำให้
ก็มีคนตอบสั้น ๆ ว่ามันรันบน 2350 ได้สบาย
สงสัยว่ามีคนที่ใช้ micropython หรือ lua กับงาน embedded แบบ "จริงจัง" อยู่จริงไหม
ผมทำผลิตภัณฑ์ embedded ที่ใช้ Lua เป็นหลักในฐานะฟรีแลนซ์มาเกือบ 20 ปี
ใช้ Lua กับอุปกรณ์ VOIP, ระบบโฮมออโตเมชัน, เราเตอร์อุตสาหกรรม, เครื่องบันทึกวิดีโอดิจิทัล และอีกหลายด้าน
โดยทั่วไประบบจะประกอบด้วย Linux kernel, libc, Lua interpreter และไลบรารีภายนอกอีกไม่กี่ตัว
ซอร์สโค้ดแอปพลิเคชัน Lua มีราว 30,000 ถึง 100,000 บรรทัด และตามมาตรฐานปัจจุบันก็ยังมีผลิตภัณฑ์ที่ถือว่า "เล็ก" อยู่ด้วย (แฟลช 8MB, RAM 64MB เป็นต้น)
Lua ทำงานได้ดีในสภาพแวดล้อมแบบนี้
ทั้งหมดเป็นผลิตภัณฑ์ที่ยังใช้งานจริง และยังสร้างรายได้ให้ลูกค้า
การเชื่อมต่อ Lua กับ C ทำได้ง่ายมาก และในเรื่องงานแบบ asynchronous นั้น Lua แก้โจทย์ที่ภาษาสมัยใหม่จำนวนมากยังพยายามหาทางจัดการมาตั้งนานแล้ว
ภาษานี้เรียบง่ายแต่ทรงพลัง และใช้แนวคิดได้หลากหลายผ่าน coroutine, closure, metatable ฯลฯ
ถ้าเป็นโปรเจกต์ขนาดประมาณนี้ ผมก็ยังจะเลือก Lua + C/C++ อยู่ดี
ผมเคยลอง ecosystem อื่นด้วย เช่น Elixir, Rust, Nim แต่ยังไม่เจอภาษาที่ทั้งทรงพลังและยืดหยุ่นได้เท่า Lua
เรากำลังพัฒนาอุปกรณ์การแพทย์ class B ด้วย MicroPython อยู่ด้วย
โลกของ embedded กว้างมาก
ถ้าเป็นงานที่อ่อนไหวด้านความปลอดภัยอาจใช้ไม่ได้เพราะข้อกำหนด แต่ถ้าเป็นอุปกรณ์ทดสอบก็ไม่เกี่ยวกับกฎระเบียบ จึงใช้สิ่งที่สะดวกได้
แม้แต่ในกลุ่ม IoT เอง แต่ละคนก็ใช้สิ่งที่ตัวเองถนัดและสะดวก
MicroPython ถูกใช้จริงในภารกิจดาวเทียมอย่าง CubeSat ด้วย
มีทั้งกรณีศึกษาจากคอนเฟอเรนซ์และพอดแคสต์ที่เกี่ยวข้อง
มีผลิตภัณฑ์นับพันที่ใช้ Lua ภายใน หรืออย่างน้อยก็ใช้บางส่วน
ช่วงหลังผมยังไปดู LuaJIT มาและคิดว่ามันถูกประเมินค่าต่ำไป
คิดว่า "นักพัฒนา embedded แบบจริงจัง" ส่วนใหญ่ยังใช้ภาษาคอมไพล์
ถ้าทำเป็นงานอดิเรก ผมใช้ Arduino(Platformio) ไปเลย
บนไมโครคอนโทรลเลอร์ การคอมไพล์แล้วแฟลชขึ้นอุปกรณ์ใช้เวลาไม่นาน จึงไม่ได้รู้สึกว่าจำเป็นต้องมี interpreter
วันหนึ่งก็อยากลองภาษาแบบคอมไพล์อื่นที่อาจมาแทน C++ ได้เหมือนกัน
อยากรู้ว่ามีภาษาไหนแนะนำที่ทำงานบน Raspberry Pi Pico ได้ดีบ้าง
ผมไม่ถึงกับเป็นผู้เชี่ยวชาญ แต่รู้สึกว่า Rust เป็นหนึ่งในทางเลือกยอดนิยมที่สุด
มันทันสมัย แก้ปัญหาหลายอย่างของ C++ และ tooling ก็ค่อนข้างดี
Zig ก็ดูน่าสนุกและอยากลองเหมือนกัน
Raspberry Pi มีสเปกค่อนข้างดี จึงอาจรันอะไรที่ไม่ใช่ system language ก็ได้
ผมก็ชอบ Kotlin และแม้ปกติจะต้องใช้ JVM แต่ก็ build แบบ native ได้
เพียงแต่บน Pico การควบคุม GPIO อาจต้องไปแตะ filesystem โดยตรง (และพูดเพิ่มอีกหน่อยคือผมก็ไม่แน่ใจเรื่องการรองรับ Kotlin บน Pico)
Nim ดูเป็นตัวเลือกที่ดีพอสมควร
ดูข้อมูลได้ที่ การรองรับ Nim ของ picostdlib
Lua เป็นภาษาที่เรียบง่ายกว่ามากในเชิงแก่นแท้
Python มีแนวคิดว่า "ควรมีวิธีที่ชัดเจนเพียงหนึ่งเดียว" แต่ในทางปฏิบัติมันกลับเหมือนเครื่องมือสารพัดประโยชน์ที่ยัดทุกอย่างมาให้
นี่อาจทำให้เริ่มต้นง่ายกว่าและมีไลบรารีเยอะ จึงพัฒนาได้สะดวก
แต่ก็ไม่ค่อยเหมาะกับสภาพแวดล้อมที่ทรัพยากรจำกัดมากนัก
จะเอาเก้าอี้หรูไปดัดให้กลายเป็นเก้าอี้ Eames ที่ทำจากไม้กระดานก็มีข้อจำกัดอยู่
Python นั้นง่าย ส่วน Lua นั้นเรียบง่าย
ปัญหาของ "ความง่าย" คือมันซ่อนความซับซ้อนภายในไว้ ส่วน "ความเรียบง่าย" หมายถึงผู้ใช้ต้องออกแรงมากกว่า
Python มีปัญหาเรื่องความเข้ากันได้ระหว่างเวอร์ชันค่อนข้างเปราะ จนการขยับจาก 3.x ไป 3.x+1 มักเกิดปัญหาได้บ่อย
Lua เองก็ไม่ได้สมบูรณ์แบบ แต่ก็ยังมีกรณีที่รองรับ Lua หลายเวอร์ชันอยู่มาก จึงมีข้อดีตรงที่ไม่ถูกบังคับให้ต้องอัปเกรดเวอร์ชันแบบก้าวกระโดดบ่อย ๆ