Close

The Lua Development Environment

A project log for Screvle - Lua Web IDE

ARM Cortex-M4 with browser-based Lua Development Environment. Provides an ideal software and hardware platform for your next project.

ronald-vanschorenRonald Vanschoren 08/18/2014 at 20:360 Comments

After getting Lua up and running it was still rather inconvenient to develop applications. It required moving files to and from the SD card frequently only to discover a small typo kept it from running. Also, to get feedback from the Lua Runtime a serial port or some other way of communication was required. Time for something new...

I already developed a basic webserver, called microWebServer, so I started to extend it to support a json based REST API to store and run Lua applications. In its initial (simple) form, sending { "cmd":"run", "filename":"..." } to /lua/command started executing the referenced Lua script. I got some help with the actual web page designs (not my expertise) and many iterations later Screvle got the current intuitive, user-friendly webinterface shown in the screenshots and demonstrated in the video. Using the CodeMirror library, advanced features like code coloring and auto completion could be added.

Console Feedback

One issue remained, how was Screvle going to report back information and errors to the webinterface? Several options were investigates before settling for a long-polling scheme. In the future I hope to include WebSockets in microWebServer.

There would potentially be several (web-)clients connected to Screvle, but I only wanted to buffer the console information once to conserve memory. Additionally, because the data is polled, it is possible to lose data as it gets overwritten before it is read back and that needs to be detected by the webinterface (otherwise, how can you trust the console output?). This let me to implement a special circular buffer.

CBuffer is a circular buffer like we all know and used, but keeps track of the total amount of bytes written into the buffer. More specifically, it keeps an absolute value (in number of bytes) for the "tail" of the buffer. When the console first polls the buffer, the tail index is returned. Subsequent polls from JavaScript will include the tail value so the buffer knows which byte index was previously returned to this webclient. If there is more recent data available, that is returned, together with a new tail value. If there is no new data the connection is kept open for a certain timeout period before returning an empty message.

Based on the amount of data that is received, the previous tail value and the new tail value, the webinterface knows if any data was lost and reports this if it happened. That way the developer knows the console output is incomplete.

If for whatever reason the webinterface did not receive a reply from the console within a timeout the connection is considered to be lost and this is reported to the user by a red light. Next the webinterface automatically tries to restore the connection.

And so the Lua Development Environment was created and allows to write Lua applications from any browser without installing a single tool, driver or application. It even works from your smartphone or tablet. Screvle only requires power and a network connection. You don't even need to be near Screvle to develop, it can be done from across the world if you like. Very useful for remote installations.

Discussions