Getting Started with JavaScript/WebGL

Question

What are the necessary steps to get my first Embedded Wizard UI application up and running within a web browser?

Answer 1

Meanwhile we have a dedicated article in our knowledge base: Getting Started with JavaScript/WebGL.

Answer 2

The following article explains all necessary steps in order to create an Embedded Wizard UI application that can be executed within a browser as Javascript application using WebGL.

Prerequisites

First of all, you need the following items:

• Embedded Wizard Studio (evaluation or full license) 
• Embedded Wizard JavaScript/WebGL Platform Package
• Optional: Local web server, e.g. from http://www.rejetto.com/hfs/

Installing Tools and Software

1. Install the latest version of Embedded Wizard Studio. If necessary, activate your dongle (see article 'Dongle Activation').
2. Install the Embedded Wizard JavaScript/WebGL Platform Package.

Creating the UI Application

In order to make the first UI application up and running within a browser, we recommend the following steps:

1. Open one of the examples from the directory \Examples_Mosaic20 (e.g. AnimationEffects).
2. Create a new profile within your project, rename it to 'WebGL', set the attribute 'PlatformPackage' to the value 'Tara.WebGL.RGBA8888' and change the attribute 'ScreenSize' to a size which corresponds to the size of the application (e.g. <800,480>). The attribute 'Optimization' should be set to 'high'. The attribute 'ApplicationClass' refers to the class of the application (e.g. Example::Application).
3. Select the new profile 'WebGL' within the profile selection box (the combo-box between Composer window and menu bar).
4. Now you can generate the code for your browser:
   To start the code generator, select the menu items 'Build' - 'Build this profile'. Within the subdirectory \Examples_Mosaic20\AnimationEffects\WebGL you will find the generated JavaScript files and an HTML page that can be launched within a browser.

Launching the UI Application

Since most browsers don't allow access to local files (for security reasons), please copy all files to a web server. Alternatively, you can use a local web server, e.g. from http://www.rejetto.com/hfs/

If you want to provide the generated code to your customers, please remove the file "_debug_only_dont_deploy.txt" which is generated into the subdirectory \code. This is only for debugging purposes.

Comments

Hi Gents, I'm just starting off wtih WebGL as well.

 I got EW's Hello_World running off LwIP's httpd server. And I've read EW's docs. But it's unclear to me how this generated WebGL code accesses the DeviceClass/DeviceDriver to use I2C etc.

Could you provide some guidance and clarification on how this intergrates?

Thanks

/ms

---

Hi Mike,

the principles of Integrating with the device are also applicable in case of JavaScript/WebGL - however, the native code has to be written in JavaScript instead of 'C'. This article describes the integration for both languages.

I hope this helps.

Best regards,

Manfred.

---

Ok... But what I still don't understand is how the inline Native Code JS would communicate with my DeviceDriver.c and I2C-BSP written in C. Or don't they? Do I now need a DeviceDriver.js|DeviceClass:: pairing along with a I2C-BSP written in JS?

---

Yes - the native language in case of JavaScript/WebGL is JavaScript - this means, the underlying system (whatever APIs) has to be accessed via JavaScript code.

---

Understood, thank you. Subsequent question... Having two I2C-BSP codebases, both trying to be I2C masters, sounds difficult and problematic. How do people typically accomplish a WebGL UI running alongside a C LCD UI, DeviceDriver.c and I2C-BSP.c? Do they let the I2C-BSP in C handle all the I2C and have JavaScript interact with it, as a proxy, over a Socket? Any example projects out there?

---

In fact, the 'DeviceDriver.js' will be executed and processed within your (remote) web browser. Hence you'll need to establish some kind of transportation layer. Usually, I would recommend relying on WebSockets or frameworks that use WebSockets as their base. That means that you would also need some kind of 'proxy' within your WebServer environment that manages those incoming web requests accordingly and route that to your I2C-BSP code base, which should be able to manage multiple sessions (local and remote). This is usually implemented within a dedicated middleware layer. Hope this helps...

---

Ah, very good, as WebSockets is what I was thinking too. ... It looks like LwIP has a patch for WebSockets. And Mongoose supports it outright. As I want to keep things bare metal. And, from what I understand Node.JS and Socket.IO require an OS...?