Lua Fast-Tracks Embedded Web Application Development

Introducing Lua

Lua (not LUA - it's not an acronym) is a general purpose scripting language. It is powerful, fast, lightweight, and embeddable. Lua combines simple procedural syntax with powerful data description constructs based on associative arrays and extensible semantics. Lua is dynamically typed, runs by interpreting byte code for a register-based virtual machine, and has automatic memory management with incremental garbage collection.

Although not specifically designed for use in embedded applications, its status as the smallest and fastest scripting language available makes it ideally suited for that purpose. In addition, Lua is designed as a C library that can easily be linked into any type of application.

You may be convinced that using C alone is the best way to write code for embedded applications. As long as those applications aren't web based, you may be right. 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:

  • Focus resources on higher-level elements of device design
  • Quickly and easily design and deliver rich, responsive, high-performance user interfaces for web-based embedded applications, and reduce time to market from as much as many months to only days.

Let's look at how Lua delivers these two factors, and then examine the "how-to" of it all.

Developers can focus on high-level design

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:

  • Managing data (which is hopefully structured)
  • Parsing requests
  • Assembling responses

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.

In the past, websites were developed via a Common Gateway Interface (CGI) interface. The problem was that CGI necessitated a full-blown operating system such as Linux, equipped with external program loading capabilities, which prevented CGI from being compatible with embedded monolithic systems. The CGI was also difficult to manage and required you to write code that handled the HTTP request headers and the HTTP response headers.

Standard web servers equipped with CGI often use Perl scripting. However, C is required in most embedded environments since Perl is typically not supported. In lieu of using CGI, a popular, more up-to-date methodology melds a Linux OS, an Apache web server, a MySQL database and a PHP scripting environment - the combination of these is known as a "LAMP" bundle.

A LAMP bundle is ideally suited for full scale web server setups. On the other hand, a major problem in using a LAMP setup for small, embedded, web-based devices is that they require far more memory than the average embedded system provides.

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.

Lua delivers the user experience

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 run as much as 20 times faster than they would in a typical LAMP setup (Sidebar).

Barracuda Application Server

Figure 1. You can write your applications as Lua scripts that interact with the application server and other blocks, including custom C routines. This saves many months of development time and can run up to 20 times faster than LAMP.

Lua development how-to

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).

-- Markov Chain Program in Lua
    
    function allwords ()
      local line = io.read()    -- current line
      local pos = 1             -- current position in the line
      return function ()        -- iterator function
        while line do           -- repeat while there are lines
          local s, e = string.find(line, "%w+", pos)
          if s then      -- found a word?
            pos = e + 1  -- update next position
            return string.sub(line, s, e)   -- return the word
          else
            line = io.read()    -- word not found; try next line
            pos = 1             -- restart from first position
          end
        end
        return nil            -- no more lines: end of traversal
      end
    end
    
    function prefix (w1, w2)
      return w1 .. ' ' .. w2
    end
    
    local statetab
    
    function insert (index, value)
      if not statetab[index] then
        statetab[index] = {n=0}
      end
      table.insert(statetab[index], value)
    end
    
    local N  = 2
    local MAXGEN = 10000
    local NOWORD = "\n"

Figure 2. This code snippet illustrates the legibility of Lua script and its similarity with other procedural programming languages such as C, C++ and Java.

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.

LSP development flow

Lua to C/C++ access is called a Lua binding and can be created manually or by using our automatic Lua Binding Generator.

LSP development cycle

Figure 3. The development flow. C code is compiled ONLY once. The Lua scripts are compiled just-in-time in the embedded device when requested by the browser.

Conclusion

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 M2M 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).

The term full-stack means developers who are comfortable working with both back-end and front-end technologies. To be more specific, it means that the developer can work with LSP, HTML, CSS, JavaScript and everything in between, including Ajax and REST.

Barracuda App Server

Try the Barracuda App Server by downloading your own copy or try our online interactive tutorials.

Related Articles:
What is an Embedded Application Server?
CGI vs. Application Server
Embedded Web for Maintenance and Control

References:
http://www.lua.org/
Programming in Lua
by Roberto Ierusalimschy
Lua.org, August 2016
ISBN 8590379868

Posted in Whitepapers