We covered Real Time Logic’s open-source lightweight Minnow Server for microcontrollers last year, and now the company has released another project: Barracuda App Server for ESP32.
This project is more complex and requires an ESP32 board with PSRAM to run such as boards based on ESP32-WROVER module with 4 to 8MB PSRAM. The Barracuda App server (BAS) comes with a Lua VM, and in complement with the LSP App Manager that facilitates active development on the ESP32 by providing a web interface.
The Barracuda App Server runs on top of FreeRTOS real-time operating system part of Espressif free ESP-IDF development environment.
The video above shows how you can flash the LSP App Manager demo code to the board to control a server. After the initial setup, everything can be done in the web browser from editing Lua code to control the servo via WebSockets, to loading a trusted TLS certificate from Let’s Encrypt.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
10 Replies to “Barracuda App Server for ESP32 Let You Easily Develop Lua Apps via Your Web Browser”
Although I recently started playing with MicroPython, I am still very skeptical that scripting languages requiring an interpreter like Python or Lua are the best choice for constrained devices. Probably super useful for web developers interested in making some quick automations but imho not for anything serious.
One of the great benefits I have learned from the Lua founders and by reading the Lua book is simply: Use Lua for what it is good at. Unlike how many other non C languages are used for embedded, such as Java, Lua developers in general do not try to solve everything using Lua. I think this design pattern is the main reason for why Lua has been so successful in the gaming Industry, where Lua is used extensively. Modern embedded systems have a tendency to be very complicated, especially when IoT and cloud connectivity is added. These non real time components are much easier and safer to design in a high level language, assuming the language comes with IoT support. With the Barracuda App Server as an example, a C coder could do all the real time components in C code and use Lua to control these C components. I think it is important to realize that Lua and other high level languages do not exclude C coding; Lua should only be used as a tool for simplifying higher level design. BTW, what is a constrained device, is it the CPU or the memory? Most modern microcontrollers are more than fast enough for Lua, but it would be foolish to use it in a device with only SRAM. However, when a microcontroller based device includes PSRAM, your options are endless 🙂
seen rust on esp32 yet ? I wonder if people made this work
thought it was done already
Precisely my thoughts. In my head, embedding http/s server in an MCU is a bit backwards.. Using https to send data is fine, but usually unnecessary (hmac usually is enough).
MicroPython on the ESP32 is fine for quick prototypes. The bigger issue than memory consumption etc is that it gives people are false impression that it works like normal python i.e. the TLS support actually validates certificates.
I cannot speak for MicroPython, but with the Barracuda App Server, you can validate the chain of trust, however, it is up to the developer to add the required CA certificates. You cannot expect an embedded device to have a certificate store as large as you have on a desktop computer. The following is a good read for anyone dealing with certificates in devices: https://realtimelogic.com/articles/Certificate-Management-for-Embedded-Systems
When you write validate the chain of trust are you sure that validation actually means what you expect it does?
As far as I remember for micropyrhon hostname validation, cert type checks, basic checks for validity period etc are missing so you only know the certificate was/is maybe valid for something maybe. So it’s only really usable with a private root cert and even then every cert you ever issue will be valid forever for any host and any purpose so you better never ever leave a test cert in a git repo by mistake because revoking it is basically impossible.
Yes! MicroPython != “the product in this article”
The comment being replied to referenced micropython.