Learn why Lua and LSP provide the best web framework to use for web enabling your VxWorks, QNX, or embedded Linux.
You may be convinced that using C alone is the best way to write code for embedded applications. However, when you're creating an embedded web application requiring a rich, responsive, and easily adaptable user interface like that which you enjoy in your favorite Smartphone, there is a smarter, more efficient development path than using C alone.
You may not be aware of it, but if you've ever used Adobe's Lightbox program, played World of Warcraft, or run any number of other Web-based programs, you've experienced a scripting language known as Lua.
Making use of the Lua scripting language instead of C alone lets developers:
Let's look at how Lua delivers these two factors, and then examine the "how-to" of it all.
Smartphones have made life difficult for developers of small, connected embedded systems. Users have become accustomed to the rich and attractive user interface that such phones provide, and they now expect all small web-based, embedded devices to provide a web based GUI just as attractive as the apps on a smart phone. The problem is most small devices don't have the processing power and the amount of memory required to run standard application servers and their high end server side scripting environments. Your customers don't know or understand this, but they do expect modern, great looking user interfaces, and they want their user interaction to be fast - just like they find on their Smartphone.
In addition, as these small, web-based devices are expanding into areas such as industrial or building controls, medical devices, and more, companies are finding they need to address user expectations to remain competitive in delivering such user interfaces.
Until now, those user expectations have presented a massive challenge. Conventional wisdom among engineers dictates that using C code is best for small web based devices, rather than considering the use of a scripting language, because scripting languages require "desktop computers and performance."
However, there is another answer. Enter the Barracuda Application Server by Real Time Logic. The Barracuda Application Server makes the use of a scripting language possible - and the Lua scripting language is the reason why. So just why does this make such a big difference?
To figure that out, let's look at what work needs to be done.
Development work can be broken down into the following categories:
With C, structures can't be entered into lightly: everything must be strictly typed. When managing server side web applications developed in C, memory must be explicitly reserved and released as needed.. Parsing isn't rocket science, but it's tedious and extremely easy to get wrong. It requires incredible attention to every detail, making maintenance difficult. Assembling the page requires string concatenation on a grand scale, which is also time consuming and error prone in C code.
With application servers and scripting environments, on the other hand, much of this work has already been done for you. An application server is a compact middle layer that abstracts the web server details, giving you access to request and response objects and their associated APIs. This means that your application has only to deal with high-level behavior and data. The application server handles the time consuming and tedious low-level parsing and page-building details.
Because scripts are more free-form and are compiled just-in-time, a single line of script can implement the entire string concatenation. The lower-level machinations are automatically handled for you by Lua's virtual machine. Scripts also let you access and manipulate data without worrying about whether you've defined the right data type or organization.
Furthermore, not even the most ardent C advocate would identify text handling as easy when writing C code, and web applications require extensive text handling. So the bottom line becomes clear. You can develop your web application in Lua in as little as 1/30th the time of C coders by using scripts and pre-built infrastructure, instead of relying entirely on custom written C.
Lua doesn't totally eliminate C from the equation - it is retained for what it does best. Scripting environments intentionally restrict scripts from getting down to the hardware level, so C routines, working similarly to drivers, are used to connect your hardware to your web application.
In essence, the particular focus of web based embedded applications means that their optimal development environment differs from that of other embedded applications. With today's users of small, web-based device applications demanding, and expecting, a rich user interface, Lua fits the bill.
Scripts are compiled just-in-time and executed on an embedded virtual machine. Although that virtual CPU brings additional overhead to the CPU, compared to compiled C code, it is not noticeable because the main overhead is in the network connection. Lua web applications typically respond lightning fast, even when run in small, web-based embedded devices.
Running together, as shown in Figure 1, the Barracuda Application Server and Lua scripting engine deliver applications that uses much less resources than they would in standard application server frameworks.
As shown in Figure 1, the system services, application server, SSL stack, and Lua virtual machine allow you to focus on your application logic using high-level data structures in Lua scripts. Unlike most other languages, Lua is easily extended not only with software written in Lua itself, but also with software written in other languages. It is therefore straightforward to use C for low-level access to your hardware.
To develop such a system, you write your C functions and compile them using your standard C tools. Depending on the requirements of your OS, you either compile them into a monolithic system, or you build a separate executable process. In order to connect Lua to your C functions, you create Lua bindings (either manually or using an automation tool such as our online binding generator that you include in the C project when it is compiled.
The Lua scripts themselves are written using a straightforward, easy-to-learn procedural syntax (Figure 2).
local gpioNum=25 -- The ESP32 GPIO (pin) number local SERVO_MIN_PULSEWIDTH=1000 --Minimum pulse width in microsecond local SERVO_MAX_PULSEWIDTH=2000 --Maximum pulse width in microsecond local SERVO_MAX_DEGREE=90 --Maximum angle in degree upto which servo can rotate local function servo_per_degree_init( degree_of_rotation) return (SERVO_MIN_PULSEWIDTH + (((SERVO_MAX_PULSEWIDTH - SERVO_MIN_PULSEWIDTH) * (degree_of_rotation)) / (SERVO_MAX_DEGREE))); end local function servo() esp.mcpwm_gpio_init(esp.MCPWM_UNIT_0, esp.MCPWM0A, gpioNum); local cfg=esp.mcpwm_config_t() cfg.frequency = 50; --frequency = 50Hz, i.e. for every servo motor time period should be 20ms cfg.cmpr_a = 0; --duty cycle of PWMxA = 0 cfg.cmpr_b = 0; --duty cycle of PWMxb = 0 cfg.counter_mode = esp.MCPWM_UP_COUNTER; cfg.duty_mode = esp.MCPWM_DUTY_MODE_0; esp.mcpwm_init(esp.MCPWM_UNIT_0, esp.MCPWM_TIMER_0, cfg); --Configure PWM0A & PWM0B with above settings while true do for count=0, SERVO_MAX_DEGREE do local angle = servo_per_degree_init(count); printf("Angle of rotation: %d, pulse width: %dus", count, angle); esp.mcpwm_set_duty_in_us(esp.MCPWM_UNIT_0, esp.MCPWM_TIMER_0, esp.MCPWM_GEN_A, angle); coroutine.yield(true) -- Sleep end end end
Lua's just-in-time compiler executes while the system is operating. Whenever you navigate or refresh the browser, the virtual machine will compile any changed script before it sends the requested response to the browser, thereby automating the script compilation and execution. This is in stark contrast to a C program that requires cross compilation on a desktop computer, linking, and finally uploading the executable to the device. Figure 3 illustrates the development process.
Lua to C/C++ access is called a Lua binding and can be created manually or by using our automatic Lua Binding Generator.
Roberto Ierusalimschy, the designer of Lua, explains the benefit in using Lua on small resource constrained devices in the following video:
In the end, what really matters is that users experience your system in a way that includes the high end graphics and attractive visual standards that they expect and demand. The last thing you want to provide is a dated, tired, and mediocre web based user interface that looks like it was designed in 1990. However, you don’t want to spend unnecessary effort and development time on the user interface by using tools that take your focus away from your own technology. By using a web environment that supports fast prototyping/development, one that’s designed to work on small embedded systems, and doing this along with a scripting language like Lua, you can focus on high-level design while also giving your users the interface they want. The Barracuda Application Server with the Lua module is specifically designed to enable embedded computer programmers to rapidly design the user interfaces and IoT required by end-users of today.
The Barracuda App Server provides a high level development environment that enables full-stack developers to design web based user interfaces for devices. This is possible thanks to the scripting language integrated in the Barracuda App Server. A full-stack developer can design web interfaces for devices -- something that they would normally not be able to do since they are not C programmers. Your embedded engineers can then focus on your device and only need to provide a device API for the full-stack developer(s).