Using AJAX to create the WEB-interface of embedded systems

The key technology for creating user interfaces for embedded devices today is the creation of WEB-applications. The advantage of this solution is platform-independence and no need for user software. Requires only a computer of any system with an already installed web browser. Necessary interfaces in the form of HTML-page templates are contained directly in the memory of your device and are “compiled” on requests from the browser and given by the built-in HTTP server.

It must be said right away that this is a normal approach and it does work, although it lacks some of the conveniences that have come with the new generation of browsers. These innovations have led to the emergence of AJAX-approach in WEB-programming, today quite equipped and provided with the means of debugging.

Can we get something for ourselves from the new technology? In this case, we can do something.

There is such a difficult task – to parse HTML-template, look for labels among text stream, where we have to substitute calculated values (imagine report as a table – rows, columns), interpret them – substitute text instead of labels, and send the flow on – to the server itself. And it is up to the server to manage this parser, depending on the received request. And the size of the request depends, in turn, on the complexity and number of fields in the HTML-form of the page from which the request is sent, and this size can be significant for the resources of your MC.

Consider an alternative implementation based on AJAX.

The basic idea is to use almost unlimited (compared to the capabilities of the MK) resources of the browser. At the request of the browser server gives static files, not interested in their content. Once loaded, the pages are interpreted by the browser, generating a stream of short requests to the server. These requests are generated by javascript to the address of the virtual file (backend), in which the relevant information is written or read. To each such request the server responds with a short answer, nothing extra. You can give binary data at all, though usually the response is a string in the JSON format native to javascript. The handler parses the string (javascript has powerful built-in text handling tools) and the results are inserted where you want them – table cells, for example.

On the other hand, if the user wants to change a single settings field, it’s done without using cumbersome forms, with a single short query without reloading the page.

The number one gain is that there is no HTML parser, the server is racing static pages without looking at them. Therefore, it may be profitable to store large files in a zipped state and give them away directly in this form, prefacing the transfer with an appropriate header. Remember – all dynamic content is created on the computer side.
Gain number two – the bulky request is split into several shorter ones, each of which sends only the changed information. The length of the requests is reduced, you have complete control over it. On the other hand, the number of simultaneously opened connections increases, but you can control that. You can execute the script to fill in the data fields after the page loads, like this:

<body onload=”init()”>
….
</body>

This will load static content first, and only then will run the script.
Gain number three – by avoiding page reloading, the window information (e.g. form content) is not lost and you don’t need to save anything on the server side. In addition, traffic is not wasted and does not heat up windows unnecessarily.
Gain number four is the complete separation of markup (static HTML files) and javascript-code, which lets you divide interface and device development completely and conduct them in parallel. Both parts can be written and debugged separately by different programmers.
The disadvantage is one, but big – it is necessary to learn AJAX.
It should be noted that the scope of AJAX is objectively limited by the response time of the communication line. If in the local network, this time is negligible, but in GRPS networks, the time from sending a request to get a response can be up to 2 seconds.

Of the non-obvious things to keep in mind is the ability to connect custom javascript files. Imagine that your interface allows you to print directly from your browser window a payment form that differs from region to region. So, this form can easily be changed by a custom script.