Differences

This shows you the differences between two versions of the page.

--- blog [2013/08/13 22:23]
jap [Let's get started with Embedded JavaScript [2013-08-13]]
+++ blog [2013/08/15 00:45]
jap [WebSocket experimentation with BeagleBone [2013-08-14]]
@@ Line 5: / Line 5: @@
 **[[http://embeddedexperience.blogspot.com/]]**
+===== WebSocket experimentation with BeagleBone [2013-08-14] =====
+I really like the concept of BeagleBone and Cloud9 IDE. I have my board connected directly to my local intranet with Ethernet cable, so I can access the IDE and my saved project, and continue working at any PC in my household, no matter whether it’s the ChromeBook, my company Windows Ultrabook, or my wife's MacBook. The very same user experience available with zero-installation needed. And my project is secured, as it is stored locally at the mass memory of the board itself. No one can access it from outside of my intranet. Of course, in case of professional software development, version control, collaboration, backups, etc. needs to be considered separately.
+The default Ångström Linux image installed on BeagleBone, does not have the WebSocket Javascript library socket.io installed by default. At [[https://github.com/lgxlogic/BoneScript-SocketIO|GitHub BoneScript Socket.IO]] page there are instructions how to install socket.io.  The whole project was initially committed only two weeks ago. There is also a nice, but rather complex example of using WebSocket to remote control LEDs, which needs to be externally attached to the BeagleBone board. NB! Some hardware hacking required.
+I wrote a canonical code example demonstrating how to control an onboard LED at BeagleBone. So, no hardware hacking is needed to test the code.  JavaScript uses JSON (JavaScript Object Notation) to exchange data. In this example, very simple JSON messages are delivered over the WebSocket connection to control and confirm the LED state. BoneScript functions are used for hardware access.
+JSON messages in this example have the following simple syntax:
+{"name":"led","args":["on"]}
+The demo consists of [[http://ala-paavola.fi/Programming/BeagleBone/Socket.IO/sockserv/|two files]] located in sockserv folder. [[http://ala-paavola.fi/Programming/BeagleBone/Socket.IO/sockserv/socketserver.js|Socketserver.js]], which is the Node.JS executed at BeagleBone, and [[http://ala-paavola.fi/Programming/BeagleBone/Socket.IO/sockserv/socketclient.html|socketclient.html]] which is the web page delivered to web browser upon request, containing HTML and JavaScript code for communication with the Beagle. The architecture equals to the scenario #1, presented in my previous posting.
+ Let’s take a closer look at few key functions.
+**Server side**
+This is how the "web server" is implemented. Whenever a client is connected and sends any GET command, the static socketclient.html file is read from local the flash disk at beagle, and send to the browser.
+  function httpserver (req, res) {
+    fs.readFile('sockserv/socketclient.html',
+    function (err, data) {
+      if (err) {
+        res.writeHead(500);
+        return res.end('Error loading index.html');
+      }
+      res.writeHead(200);
+      res.end(data);
+    });
+  }
+When WebSocket connection is established, and some data received, the following callback will parse the message, whether the LED should be switched ON or OFF. As an acknowledgement, the same message is transmitted back to the client.
+  io.sockets.on('connection', function (socket) {
+    socket.on('led', function (data) {
+      console.log(data);
+      if (data == 'on'){
+          b.digitalWrite(led, b.HIGH);
+          socket.emit('led', 'on');
+      }else{
+          b.digitalWrite(led, b.LOW);
+          socket.emit('led', 'off');
+      }
+    });
+  });
+**Client side**
+At the socketclient.html page, there is one button to toggle the state of the LED. When the button is clicked, this function transmits JSON message over WebSocket to server.
+  function toggleLed(){
+    if ( document.getElementById("ledButton").value == "Switch On" ) {
+        socket.emit('led', 'on');
+    } else {
+        socket.emit('led', 'off');
+    }
+  }
+If acknowledgement is received, it it processed by this callback function, which changes the state of the button, confirming successful operation to user. If you see the label of the button changed, you know the message has travelled back and forth.
+  socket.on('led', function (data) {
+    console.log(data);
+    if (data == 'on'){
+        document.getElementById("ledButton").value= "Switch Off";
+    } else {
+        document.getElementById("ledButton").value= "Switch On";
+    }
+  });
+There is one flaw in beauty in this code. Once the page is loaded, the button is not initially synchronized with the actual state of the physical LED. Only after clicking the button for the first time, the UI and the LED are in sync. I made this decision by purpose, as I want to keep the example as simple as possible.
+{{:websocket_ui.png?300|}}\\
+//Web UI of the demo.//
+**Disclaimer:** I’m not a professional JavaScript programmer, actual this was my first Node.JS code written ever, and only few times tried JavaScript before. Thus, the code may not be optimal, and something I may have understood wrong. I warmly welcome any feedback to correct faults, and to make it pedagogically more correct. Well, it just looks like working OK.
+===== WebSocket connectivity for Embedded [2013-08-14]=====
+[[http://en.wikipedia.org/wiki/WebSocket|WebSocket]] is not only for web pages, but is good for embedded M2M connectivity as well.
+WebSocket is often called as the TCP socket of the Web. And that’s pretty much correct. WebSocket provides full-duplex communication channel in between WS client and WS server. Roles of client and server are relevant only when establishing connection, when communicating it’s irrelevant, as both sides can transmit independently, just like in traditional TCP/IP sockets.
+What’s the added value of WebSocket over conventional TCP socket then?  It’s the browser integration. With WebSocket, browser can open a socket connection easily as instructed by JavaScript code. Opening traditional TCP socket at client side is not trivial at all. Secondly, WebSocket supports TSL/SSL security by nature, no separate security function needs to be implemented.
+What makes WebSocket good for Embedded M2M? Well, first of all, it’s standardized, free, and open. It reduces your code size, in case of having both human interface and machine interface, as the same communication module can be utilized for purposes. Most importantly, it gives new freedom in constellation of functionality.
+In the old school web architecture, specific application logic was only accessible to client through web server. This means the server must be capable enough to handle that kind of communication, and provide an interface of some sort for application logic integration. Generally speaking, in order to run such a capable web server, a proper CPU w/MMU and a real operating system is needed. We’re talking about something like Espotel Jhumar platform or similar, a device with ARM9 CPU running Linux.
+Traditional web architecture.
+{{:old_web_architecture.png?300|}}\\
+//Traditional web architecture//
+Thanks to WebSocket, web server and application logic can be totally separated from each other. No need for any interfacing, and they can be located in separate hardware even. In this scenario, web server only needs to provide static HTML/JavaScript code when requested, which makes server implementation super lightweight. One can implement such a server from scratch in matter of hours, with minimal memory footprint.  By instructions given in JavaScript code, the client can then establish WebSocket connection directly to application logic only, for application specific data exchange.
+Our engineers have demonstrated running web server and an application logic with WebSocket support in a Cortex-M0 MCU. I have done that same by myself with Arduino platform. That’s the proof of simplicity. Even the most low-end hardware can do Internet-of-Things, with help of HTML5 technology. If strong authentication and security is needed, then HW requirement is upgradedup  to Cortex-M4 or higher, depending on availability of cryptographic subsystem.
+I have recognized 4 different scenarios how to distribute web server and application logic, illustrated in the picture below.
+Different WebSocket architecture options
+{{:new-web-architectures.png?600|}}\\
+//Different WebSocket architecture options//
+. Integrated - Both server and application logic resides in the same hardware. Stand-alone all-in-one solution.\\
+. Pre-loaded – HTML/JS code is pre-loaded in client side, sort of Apps approach. Most lightweight.\\
+. Cloud wed – Web service is located in cloud, and data is exchanged directly with embedded device. Easy deployment of new UI features.\\
+. Cloud hub – All traffic is routed through cloud. Access through firewalls, and in case of mobile and non-static IP end-points.
 ===== Let's get started with Embedded JavaScript [2013-08-13] =====