Wavecom now offers scripting with Open AT Lua

Legacy Open AT
1

Wavecom announced that easy scripting of its Q26 and WMP series is now publicly available, in alpha delivery:

wavecom.com/openatlua

This release is performed in a new way for Wavecom: open source (MIT license), with primary support from a dedicated Wiki (wavecom.com/lua/wiki/tiki-index.php) and from this forum. This dramatically simplified delivery process is expected to bring many advantages, one of them being a stronger open AT Developers community. We’ll do our bets to support Open AT Lua users through the wiki and the forum. Since you have the sources and the rights to do so, we encourage you to hack in the library as much as you want, and to contribute your improvements back to the community (although the MIT license doesn’t force you to, unlike GPL would).

I have been following the Open AT Forum for quite some time, and I believe that many problems described here find a fast and easy solution through Open AT Lua. I encourage you to give it a try. Among the stuff you might like:

  • as opposed to AT commands, you not only send individual commands but whole programs. Plus, Lua code is human readable. For instance, opening the GPRS bearer and fetching the Google homepage would simply be:
wip.bearer_client("GPRS", { apn      = 'orange-mib',
                            pin      = 1234,
                            login    = 'mportail',
                            password = 'mib' })
x=wip.client_create ("www.google.com", 80)
x:write ("GET / HTTP/1.0\r\n\r\n")
print(x:read())
x:close()

And you can simply type it in a telnet shell, no need for a compile/download/reboot cycle.

  • multiple threads and blocking I/Os: no more mandatory state machines and callbacks to handle network events. This example, fetching a file from an FTP server from raw TCP into variable ‘data’, without relying on WIP FTP, should give an idea of how much simpler we’re talking about:
x, y = wip.tcp_client ("192.168.1.5", 21), nil
z = wip.tcp_server (1024, function(client) y=client; z:close() end)
if not y then z:wait "accept" end
x:write "USER anonymous\r\n"
x:write "PASS lua@wavecom.com\r\n"
x:write "PORT 192,168,1,4,4,0\r\n"
x:write "RETR data.txt\r\n"
data = y:read "*a"
x:write "QUIT\r\n"
y:close()
x:close()

You’ll also find in the samples a 100-ish lines web server, extensions giving it AJAX capabilities, RSS feeds, an FTP server, rerouting of AT commands from a TCP/IP connection, etc.

  • as opposed to C development, no more save/compile/download/reboot/fetch-traces cycle: you type “l’foobar.lua’” in a telnet shell running on the wireless microprocessor, and it downloads the source file from the FTP server runnning on your PC, compiles it, and runs it. Without rebooting. At any time, you can inspect and modify global variables, sockets, bearers, threads, all this through TCP/IP. If you’re not satisfied, change a couple of lines, re-type “l()”, see if you’ve fixed your issue. When you’re satisfied by your program, just type “save’foobar’” and your function is committed in flash memory.

  • most important, Lua is designed to interact perfectly with C code: legacy code in C and stuff that require C’s realtime performances can be integrated with Lua seamlessly, so you keep the best of both worlds.

So in short:

  • if you’re using a Q26 or WMP based solution, have a look at Open AT Lua, it might help you with many of your issues.
  • if you have difficulties with it, ask in this section, we’ll do our best to help you.
  • don’t hesitate to annotate/improve/change the wiki, it’s yours!
2

There seem to have been a glitch in the Forum server’s config, preventing some users from accessing this section. It’s fixed now!

3

While it may be useful for quick prototyping or smaller projects, I can’t see that it would be of much use for larger projects.

Guess I’ll look at it some day when I have time.

4

Larger projects are the typical cases where:

  • memory management becomes harder to get right. A proper garbage collector saves you bugs and development time.

  • there are trickier algorithmic parts. Easily designing advanced data structures, proper string handling, error throwing and catching, blocking I/Os etc. all contribute to keep such algorithms as simple as possible.

  • you want to do several things concurrently. Cheap collaborative threads help you do that without encoding unmaintainable state automatons.

  • you’re going to spend a lot of time debugging. Interactive inspection, modification, debug of a running program, possibly remotely, change a developer’s life at this stage.

  • you’re going to discover some issues on field. Taking control of a wireless CPU remotely allows you to fix them faster and more accurately.

The legitimate reasons to stick to C are limited resources and/or hard realtime constraints (and even in such cases, Lua’s C-friendliness allows you to mix both approaches). These criteria are independent from your project’s size. If you’ve ever worked with Python, Ruby or even TCL/Tk on a PC, you should be familiar with the development and maintenance time saved by higher level languages, and with the resulting improvements on code clarity.

5

When you’re dealing with a large project and have limited hardware resources, adding yet another layer (in this case a script interpreter that consumes additional RAM and flash) isn’t really a good option, imo.

6

We agree that resource limitations can force you to accept more development/maintenance/reliability costs in exchange for a lower strain on hardware, and indeed, this can force you to fall back to C or even assembler. Case in point, if you’re working with a Q24 as your main CPU, C is your only option.

But again, being resource constrained is not induced by your project’s size. Quite the opposite, if your project requires you to have a higher-end CPU with at least 16Mb of RAM, you’ve got no reason to stick to C and its inherent R&D and front-office costs for those 90% of your code that aren’t realtime. The current Q26’s 8Mb RAM are enough for many significant apps (You can run a dynamic web server, an FTP server, an RRS feeds server and a telnet shell in parallel on it, all written in pure Lua, if you strip debug info). And AFAIK the new Q26 are now produced with 16Mb RAM anyway.

From a certain level of complexity/size, low level issues are such a burden that they prevent you from shipping reasonably bug-free code at all. I don’t think you’d ever ear a seasoned PC software developer saying “gosh, that project is so huge and complex that I’d better do it in malloc-free C rather than Python or C#”.

[EDIT: added some considerations about Q26 RAM resources]

7

Since this thread was about LUA for OpenAT, my posts were made with Q24/Q26 modules in mind, and I viewed project size relative to what resources are available.
If you view project size as a constant regardless of what resources are available, it’s another matter of course.

It would indeed be quite pointless to stick to C/asm for projects where you’re less resource constrained.

8

Out of the standard 8Mb RAM, you only get access to 2Mb (256kB) for use in your application…
I don’t currently have any 16Mb Q26 but I was using a Q24PL with 16Mb of RAM for a short time and if that’s any indication Q26 with 16Mb gives access to 10Mb of RAM (1MB+256kB).
For new projects (targeted at Q26/16Mb), it may be useful to look at LUA.

9

indeed, these are the conditions under which the setup mentioned above has been tested. To be completely fair, some care had to be taken with memory usage and fragmentation, for it to run. 16Mb would have allowed to simplify it, by handling files as “dumb” strings, not requiring a compilation cache system for dynamic web pages, etc. And some even deeper changes would have been required to get production-grade stability on those “2Mb out of 8”.

This would have run Open AT Lua perfectly, especially for programs where the bottleneck is network speed rather than CPU cycles.

For the record, in the “default comfortable” setup (compiler, VM, extensive ADL bindings, telnet shell server, and automated source fetching through FTP), Open AT Lua takes 60KB of heap RAM (add WIP RAM usage to get the global figure). By trimming some optional ADL bindings and falling back to a dumber telnet server, you can go down to 40KB. Running a web server will typically eat an additional 20KB.

Some other embedded scripting and VM-based solutions have convinced people that embedded interpreted platforms are resources black holes, and only give a limited control on the platform, to the point of quasi-uselessness. It isn’t necessarily so!

10

I’ve only just started to look at Lua myself. My application is done in C and already in an advanced development stage. But what excites me about Lua is the possibility to do remote debugging. I’m wondering if is possible to load a light version of Lua shell funtions in combination with my regular C app, just to do remote diagnostics and troubleshooting. Can this be done and is it advisable to use Lua in this way?

11

Yes you can load a lighter version of Lua: it comes as an ADL library, which can be linked to your application. If you look at the samples, they’re just minimalist applications which launch the Lua VM and start a telnet server. in the main file, you’ll find a table “initializers” which lists the modules loaded in the VM. You can remove some of them (lualightsample offers a reduced features set wrt luasample by reducing this list, and relying on a more minimalist shell whose sources are in oatlua/src_lua/shell_ligth.lua).

Lua’s original purpose, by design, is to bring dynamic features in a C application; the typical way Lua becomes central in an application is that people first use it for a minor purpose (e.g. handling config files, or the UI…), then realize that dynamism would save them a lot of time in many other cases, and progressively make it central to their architecture. A couple of years ago, Mark Hamburg gave a great presentation about how Lua made it to the core of Adobe Photoshop Lightroom: lua.org/wshop05/Hamburg.pdf

So definitely, your use case is quite typical of Lua first-stage adoption :slight_smile:

12

Thank you very much for the feedback. This is pretty exciting stuff! I’ll definetely spend some time to go through the samples and documentation. :smiley: