Chapter 10. JavaScript and constrained hardware

In the first half of this book, electronics fundamentals were demonstrated by using a tethered Arduino Uno—a host-client setup. In the past few chapters, though, you’ve met the Tessel 2, which has the oomph to run Node.js natively within its OpenWrt operating system—that’s a single-board-computer (SBC) setup.

Now we’re going to take a look at a third class of JavaScript-controlled platforms: constrained embedded hardware with native support for JavaScript (or, often, something that’s JavaScript-like). To accomplish this feat with such limited hardware resources, these platforms tend to rely on highly optimized custom JavaScript engines.

These devices are evolving quickly, entering (and exiting) the market more rapidly than can be captured well in print. At this very moment, the Espruino platform—we’ll be looking at the Espruino Pico shortly—seems to be maintaining robust momentum (figure 10.1). The Kinoma Element—also on-deck for our investigations—has been in prerelease for quite some time. Although Kinoma’s embedded runtime has been held up as an early pioneer in supporting most ECMAScript 6 features, the Element product may not end up taking off. It’s hard to say with things moving so quickly.

Obsolescence is pretty much guaranteed for IoT hardware and software information committed to print, which is why this chapter focuses more on tasks and puzzles common across embedded JavaScript platforms. Specific products and platforms come and go, but there are a bunch of common research steps that can help you get up to speed, quickly, on whichever product you choose.

10.1. The Espruino Pico platform

The Espruino Pico has less memory and less computational power than the Tessel 2. There’s no WiFi and no USB peripheral support, so why use it? Because it shines at other things: it’s cheaper, it’s tiny, it’s reliable, and it’s power-efficient—hallmarks of low-power embedded platforms.

Espruino describes both the hardware family itself and the firmware runtime interpreter that comes preflashed on Espruino devices. Espruino-the-interpreter supports most JavaScript features, but not all of them. You can’t get away with omitting semicolons, for example, and regular expressions aren’t supported.

It’s important to differentiate JavaScript and JavaScript-esque from Node.js: this isn’t Node.js, so you can’t use Johnny-Five or any npm modules.

Instead, Espruino provides its own JavaScript API for interacting with the hardware I/O (www.espruino.com/Reference#software). You’ve got enough experience under your belt now that aspects of the API likely ring familiar—there’s an analogRead function, for example, that takes a pin number as an argument. There are also Espruino-specific modules that encapsulate the behavior of specific electronic components, as you’ll see.

Before examining the Pico in more depth, you’ll get it set up and take a Hello World LED-blinking script for a spin.

10.1.1. Setting up the Pico

The Pico needs to be soldered onto header strips (figure 10.2). Your Pico may have come with header strips, but if not you’ll need two strips of nine pins each.

The Pico plugs right into a USB port. Some versions of the Pico have an additional USB micro connection, but you may well be stuck with just the USB A connection. This can be convenient, because you can plug your Pico right into your computer, but if you want to use the Pico on a breadboard—which is necessary when you want to try out any of the I/O pins—it gets a little tricky. The Pico is designed to connect to a USB A female connector. You can use the kind of cable marketed as a USB extension cable to get the USB A to USB A female connections the Pico needs (figure 10.3).

Things are evolving quickly enough in the Espruino family that including exhaustive setup instructions here would be foolish. Instead, head to https://espruino.com to get started.

These are the basic steps, after plugging your Pico into USB:

For the purposes of experimenting with the Pico, you’ll be using Espruino’s web-based IDE (Chrome app)—that means you’ll connect to, communicate with, and deploy code to the Pico from within the Chrome app.

On the left side of the app’s interface, you’ll see a terminal-like console area. Once you’re connected to a Pico, you can type expressions here directly, sort of like a Node.js interpreter or the Johnny-Five REPL. On the right side is an area where you can compose scripts.

10.1.2. Hello World LED blink

Let’s try it out with the requisite blinking of an LED. For this experiment, you’ll be using one of the Pico’s onboard LEDs, so you can plug the Pico into your USB port directly or stick it on a breadboard with a USB extension cable: the choice is yours.

An assortment of variables are available at a global level in Espruino scripts, pertaining to platform features and pins. This includes the variables LED1 and LED2 for the Pico’s built-in red and green LEDs, respectively (figure 10.5).

Fire up the Espruino IDE Chrome app and connect to the Pico. Enter the code shown in the following listing into the code-composition area of the screen (the right side) and click the Send to Espruino icon in the center (figure 10.6).

This example uses Espruino’s digitalWrite function to alternately set LEDs HIGH and LOW. Once you deploy the code to the Pico, you should see the Pico’s red and green LEDs blinking, one at a time. You’ll also see some output on the left side of the IDE window.

10.2. Learning about new platforms

Now that you’ve gotten hands-on, let’s back up a bit. How do you know that the Pico has two built-in LEDs (red and green), and how do you know that there are variables LED1 and LED2? By now, conventions like digitalWrite being a name for a function that writes logic levels to digital outputs probably seems sensible. But it may still seem somewhat magical or random. Where does one start?

There are a series of sleuthing steps you can apply when facing a new platform to get you scooting along in short order. You’ll tackle these to learn about the Pico specifically now, but you can reuse them to evaluate different embedded platforms in the future:

Let’s look at each of these.

10.2.1. Discovering a platform’s core features

Before you even get your hands on a new dev board or platform, you’ll probably want an overall sense of what it can do.

Often the key details are summarized on the manufacturer’s or supplier’s web site. In the Pico’s case, a list of features the Pico’s web page gives us the scoop: it’s a 3.3 V device, petite in form factor (33 mm x 15 mm), it’s powered by a STM32F401CDU6 microcontroller (no, my cat didn’t just walk on my keyboard; ST—the manufacturer—has naming conventions that are unromantic, but quite precise), and it uses an ARM Cortex M4 processor (www.espruino.com/Pico).

Also in the key features list are bullet points about power consumption (figure 10.7). Even if the specific numbers cited here don’t hit home, you can see that they’re making noise about being power efficient.

There are 22 GPIO pins on the device, including 3 I²C interfaces and 3 (hardware) SPI interfaces—not shabby for something so small. If you click through to the microcontroller’s datasheet (http://mng.bz/i7r8), you can see that you have the STM32F401D/E family to thank for that (there’s a section about communication interfaces on the front page).

A couple of other features jump out. One is a nice nod to the ubiquity of 5 V logic—”All GPIO is 5 volt tolerant (Arduino compatible)”—a kindness to those of us who have to swap between the two a lot. Output will always be 3.3 V, but 5 V input won’t give the Pico heartburn.

Another detail worth noting: although 18 pins (two rows of 9) are at a breadboard-standard 0.1″ pin pitch, 8 pins on one short end are only 0.05″ apart (figure 10.8). You won’t be using those pins in your explorations, as they don’t slot easily into a breadboard, but there are physical shims you can get to make it possible.

Granted, this particular list of features doesn’t mention that this a JavaScript-powered device, which is kind of key, but you can certainly glean that from Espruino’s home page (www.espruino.com).

Another thing that’s handy to understand is the platform’s financial and licensing model. Is the hardware or software (or both) open source, or are they proprietary? This can be relevant if you’re considering using a platform commercially, extending hardware or software, or otherwise making contributions to a platform. (Espruino platforms are fully open source.)

10.2.2. Finding a pinout diagram

Maybe it’s because I have a love for maps, but finding and analyzing a board’s pinout diagram is usually when things really click home. These diagrams show you which pins can do what: communication interfaces, PWM, power pins, and so on.

From the Pico’s diagram (figure 10.9), we can note a few things (see it in a larger size with more detail on Espruino’s Pico documentation page: www.espruino.com/Pico). For one, pin numbers aren’t sequential; they jump around a bit, and you’ll find both A and B pins on both of the two sides you’ll be using. You can also see that there’s PWM support on nearly every GPIO pin. Finally, you can see which pins have hardware support for I²C and SPI, and which can support ADC (analog-to-digital conversion).

A combination of sensible overall pin layout (hardware design) and high-quality pinout diagrams can make for a better development experience.

10.2.3. Learning about configuration and workflow

How is code written? Deployed? How is the device managed, configured, and updated? Is it supported for your operating system? Is the configuration process overwhelming and tedious? That could be a sign of an ongoing headache.

In the Pico’s case, we’ve taken the recommended route of using the Chrome app IDE. This can be convenient—code authoring, device management, and deployment are in one place—but if you’re the kind of person who has an attachment to your own editor or IDE for writing JavaScript, it might drive you nuts.

Get a sense of the high-level software constructs: are there plugins or other modularized components? Is there a general hardware-oriented API? Espruino has both of these.

10.2.4. Finding examples and tutorials

Stepping through some Hello World examples is next, and you’ve already done that with the Pico. When experimenting with a new platform, figure out how to accomplish some common tasks, such as blinking LEDs, reading data from an analog sensor, working with displays, and controlling I²C devices. Ideally, you’ll get hands-on at this step, getting a sense for how it really feels to interact with the platform during development.

Once you’ve got your head around the big picture, and seen (and tried) a few applied examples, hitting up reference documentation can help fill in the details.

10.2.5. Using reference API documentation

If you glance at Espruino’s API documentation (10.10), you’ll see familiar JavaScript classes—String, Math, Boolean, JSON—along with Espruino-specific classes relevant to hardware stuff: I2C, SPI, WLAN. The Globals section lists hardware functions like digitalWrite() available to Espruino scripts, and also some standard JavaScript global goodies like setTimeout() and eval().

There’s also a page that lists available modules for Espruino and how to use them (www.espruino.com/Modules). More on that as we explore the Pico more fully.

As you learn more about a platform and gain experience with it, you’ll find yourself moving from a learning phase, where you’re seeking out prebaked examples, concepts, and tutorials, to a reference phase, where you’re searching for details on how to accomplish specific tasks.

10.3. Experimenting with the Pico

Next, you’ll take the Pico for a spin and try out a few experiments. First, you’ll revisit the BMP180 weather multisensor, but you’ll be combining it with a Nokia 5110 LCD display component to build a nice-looking, self-contained mini weather station.

10.3.1. The Pico and the BMP180 multisensor

Because you’re using the Web IDE, working with Espruino modules is as easy as using a require() statement in the Espruino code with the name of the module you’re after. These modules provide encapsulated support for different types of components. And, huzzah, there’s an existing module for your trusty BMP180 temperature and pressure multisensor. The module’s called BMP085 because it’s also compatible with the similar BMP085 sensor. Once the module is imported, you can use the API it provides to interact with the BMP180 sensor. Let’s see what that looks like.

The BMP085 Espruino module

This experiment will log the current temperature (in Celsius) and pressure (in pascals) as obtained from the I²C BMP180 sensor.

The code required to log readings from a BMP180 isn’t too dense, as you’ll see in listing 10.2. It makes use of the exposed I2C1 global to configure an I²C interface that it then passes to the connect method of the BMP085 module.

As you’ve seen, Johnny-Five provides several constructs for performing continuous, periodic actions like sensor reads—board.loop, for example. But you’re not using Johnny-Five here. Instead, you’ll follow Espruino convention, which makes use of setInterval for repeated I/O.

How do you know that pins B6 and B7 support I²C SCL and SDA respectively? From the pinout (figure 10.11).

Building the BMP180 circuit

To construct this, you’ll want to put the Pico on a full-size breadboard and use a USB extension cable. Construct the circuit shown in figure 10.11.

The setup may seem a bit cockamamie at the moment. “Why stick the BMP180 sensor so far away from the Pico?” you may reasonably be wondering. There’s a method to this madness: the resulting gap will allow for the expansion of this circuit to accommodate the Nokia 5110 LCD component in upcoming experiments.

Deploying the code

Enter the code from listing 10.2 into the right side of the IDE, and click the Send to Espruino up-arrow icon to execute the code on the Pico. The logged pressure and temperature will appear on the console/terminal (left) side of the IDE window (figure 10.13).

10.3.2. The Pico and the Nokia 5110 LCD

The Nokia 5110 48x84 pixel display (figure 10.14) was originally used in the popular Nokia 51xx family of phones, which date from the late 1990s (great phones, by the way—they were known for their durability, excellent battery life, and ease of use). Nokia 5110 LCD units can be found online for as little as $6, but they’re easier to find at around $10 each. They’re great little components: 48x84 pixels isn’t infinite real estate, but it’s a lot more than the 16x2 we’ve seen so far. There’s room to draw, animate, and do fun things.

The display is controlled by a Philips Semiconductor driver named, in that non-memorable way that such components often have, the PCD8544. The PCD8544 provides an SPI interface to the display, and (yay!) there’s an Espruino module for this controller.

You’ll start by creating a visual countdown timer using the Nokia 5110 on its own, and then you’ll combine it with the BMP180 to make a little weather station.

Connecting the LCD to the Pico

Leave the BMP180 connected from the previous experiment—you’ll use it again in a minute—and connect the Nokia 5110 to a free section of the full-sized breadboard as shown in figure 10.15 (and summarized in table 10.1).

Making a visual countdown timer with the Nokia 5110

To get acquainted with the Nokia 5110 and Espruino’s Graphics capabilities, this experiment creates a 10-second timer that shows its progress using an animated progress bar on the LCD (figure 10.16). You can, of course, adjust the timer’s duration in the code. The timer is started by pressing the Pico’s itty-bitty built-in button.

The Espruino PCD8544 module

To write a program for the timer, you’ll use the Espruino PCD8544 module. The code first sets up some variables and creates an initialization function to set up the timer (10.3), as shown in the next listing.

Next, you need to find a way for a user to activate the timer. You can use the Pico’s onboard push button as a trigger to start the timer by making use of some Espruino global goodies: the setWatch(function, pin, options) function and the virtual BTN pin.

The setWatch() function provides interrupt-like behavior, allowing you to register a callback that’s invoked when the watched pin’s value changes. In listing 10.4, setWatch() is used to watch BTN continuously. Before starting the timer, the code makes sure there isn’t another timer already running, and then it resets the timer’s progress and kicks things off.

The timer runs by repeatedly invoking a function named draw at a calculated interval. But what is the draw function? You’ll need to write it! Your draw function’s tasks will include incrementing the timer’s progress and rendering its proportional progress onto the LCD screen.

The object returned by the PCD8544 module’s connect method—assigned in your code to the variable lcd—provides a few LCD-specific methods like flip(), which takes the current contents of a buffer and displays them on the screen, and setContrast()—that method does what it sounds like it would do. In addition, the object inherits from Espruino’s Graphics library (www.espruino.com/Graphics), giving you tools to render text strings as well as draw lines and shapes.

The draw function in listing 10.5 uses the drawRect(x1, y1, x2, y2) method to draw the outline of a box representing the total timer duration. Then fillRect(x1, y1, x2, y2) is used to draw a filled-in progress bar at a width representative of the time elapsed so far. The only real math the draw function needs to do is determine how wide that filled rectangle should be—how many of the LCD’s available 84 horizontal pixels represent the proportion of time that has elapsed. That’s calculated and assigned to the rightEdge variable. To summarize: an empty rectangle—the progress bar’s outline—is drawn, vertically centered on the screen, and then a filled rectangle of the calculated width is drawn inside of it.

Paste the timer code into the right side of the Espruino IDE, connect to the Pico, and upload the code. Press the Pico’s button to start the timer.

You can make adjustments to the code if you’d like. You could change the timer’s duration, or you could make the LCD display a message when the timer is complete, for example.

10.3.3. Building a power-efficient weather gadget with the Pico

You’re getting to be rather an expert at building mini weather gadgets, and here’s another one to add to the arsenal. By combining your old friend the BMP180 sensor with the Nokia 5110 display, you can cobble together an independent, nicely formatted, low-power weather device (figure 10.17).

If you followed along through the previous two experiments, you already have the circuit you need: the BMP180 and the Nokia 5110 connected to the Pico on a full-sized breadboard (figure 10.18). You’ll rely on some more features of the Espruino Graphics library to allow you to draw vector fonts and more shapes to format the display of the data, and you’ll deploy the resulting code to the Pico’s flash memory so that the Pico will independently run the program any time it’s provided with power.

As with the timer, you’ll start by setting up some variables and an initialization function, shown in listing 10.6. Pressure readings on the BMP180 are considerably more accurate if you adjust them for your local altitude (in meters). The getSeaLevel method, available on objects returned by the BMP085 module’s connect() function, gives you a handy way to perform that altitude correction. Note that the getPressure method is used here to read both pressure and temperature at the same time. Make sure to adjust the value of the altitude variable in the next listing to your local altitude (in meters).

Lines, circles, and text with Espruino Graphics

As with the timer, you need to write the draw function. The code in listing 10.7 makes use of more shape-drawing methods from the Graphics library: drawLine(x1, y1, x2, y2) and drawCircle(x, y, radius) (figure 10.18). It also avails itself of some methods for deriving dimensions: getWidth() and getHeight(), for example, which return the display’s usable area, in pixels, for the x and y axes, respectively. Finally, stringWidth(str) calculates the pixel width of the given string, using the current font settings.

Let’s talk fonts. There’s a tiny bitmap font available whose characters are 4 x 6 pixels in size. To use the bitmap font, you use the setFontBitmap() method to make that font active. In this example, however, you’ll use a vector font. The vector font can be used at various sizes—it scales. The setFontVector(size) method will set the active font to a scaled vector font with a height of size pixels.

There are a lot of numbers in the following draw function. It’s a bit finicky-looking, but everything here is unsophisticated pixel arithmetic to position elements of text and shapes. Note that the string “mb” in the drawing function (the abbreviation for millibars) is “hand-kerned,” because I found that drawing the string in one go at that font size ran the letters together illegibly.

Put all of the code for the weather gadget into the code side of the Espruino IDE, and use the Send to Espruino icon to run the code on the Pico. It’ll show the temperature and pressure until it’s unplugged from the USB port of your computer.

But you can do a little better! On the left side of the IDE, type the command save() and press Enter. This will flash the code to the Pico. Now, anytime the Pico has power, it will resume running this code. Try it out by plugging the Pico into a USB power source, like a phone charger.

10.4. Experimenting with the Kinoma Element platform

To rinse and repeat the process of platform exploration, we’ll take a brief look at another embedded-JavaScript platform: the Kinoma Element.

The Element is a small, JavaScript-powered IoT platform with 16 programmable pins (figure 10.19). Like the Espruino Pico, it’s inexpensive—an Element will set you back about $20 or maybe a little more. Also like the Pico, it lacks the bells and whistles of its more beefy (and costly) brethren—you won’t find onboard USB, Ethernet, SDCard, or other peripheral goodies—but it has the basic bits needed for IoT products in an efficient little package. Also, it has built-in WiFi support.

10.4.1. The Element’s core features

Chipmaker Marvell produces the Element (http://mng.bz/w1lR), which features its Marvell MW302 System-on-a-Chip (SoC), which in turn uses a 200 MHz ARM Cortex M4. The board, enclosure, JavaScript runtime, and framework software are open source.

To run JavaScript natively with only 512 KB RAM, the Element uses a technology called XIP (execute in place). The Element runs FreeRTOS, a streamlined and minimal open source operating system. The board’s operating voltage is 3.3 V.

The Element comes packaged in an enclosure, which makes it look less like a board and more like a finished device (the enclosure design is open source too). Instead of having dedicated power pins, you configure any of the Element’s 16 pins (8 on each side of the board) as 3.3 V or ground as needed.

Kinoma uses its own (Apache-licensed) JavaScript engine, XS6, which, with minor exceptions, claims ES6 compatibility. Note that the Element’s IDE software is available for Mac and Windows (beta), but it doesn’t have Linux support.

10.4.2. Pinout and hardware diagram

The Element’s pin layout is rather straightforward (figure 10.20). It’s a simpler device than the Pico in terms of I/O feature support; for example, there are two I²C interfaces but no support for SPI. On the flip side, it’s less complex to figure out which pins do what, and the numbering is easy to follow.

10.4.3. Configuration, management, workflow

The Element is a tidy, self-contained package that won’t require any soldering or prep. Jumper wires can plug right into it directly.

The configuration and workflow is similar to the Pico in that there’s an IDE for configuring, authoring, and deploying. If you have an Element on hand, you can head over to the quick-start guide for details (http://mng.bz/84cS), but these are the general steps:

Code projects for the Element, developed in the Kinoma Code IDE (figure 10.21), can be deployed over USB or WiFi b/g/n. Setup involves getting the Element on your local WiFi network. It will be assigned its own IP address.

Application projects for the Element have some structure to them. For example, each must contain a project.json file, which defines an entry point—the script that will get executed on the device. The entry point defaults to main.js.

As with Espruino, Kinoma provides some global objects to help you interact with hardware, and there is the notion of modules for the encapsulation of component behavior. Kinoma modules for controlling hardware components are known as Blinking-Light Libraries (BLLs) and they involve interacting with the hardware through a (built-in) Pins module. You can use CommonJS style require statements to pull other JS files into your projects and any built-in or custom BLL modules (but remember, this isn’t Node.js: you can’t use npm modules).

10.4.4. Examples and tutorials

Kinoma’s site has some code examples for the Element: http://mng.bz/1BaB. Looking at the blinking-LED example code (http://mng.bz/5t61), it’s immediately evident that the structure of Kinoma projects is more formal than that of some other platforms (figure 10.22). Blinking an LED involves a project.json file to define the project, a main.js (entry point) to initialize the board and configure the pin for the LED, and an led.js BLL module that provides the logical support for blinking via a toggle method. (The .project file and the XML file in the project appear to be for Kinoma-site-specific build and metadata support.)

You’ll also need to bring your own LED and resistor to the party, as there’s no evident onboard LED you can use. The code inside of this project’s main.js file assumes you’re using pins 9 and 10 (ground), but there’s no wiring diagram provided.

You’ll learn more about what the code in a Kinoma main.js script looks like in just a bit.

10.4.5. API reference

Kinoma modules provide the API for hardware interaction. The most immediately relevant module is Pins, which provides basic I/O support for the kinds of things you’d expect: digital and analog input and output; pulse-width modulation (PWM); serial (I²C, for example). You can find a programmer’s guide on the Kinoma site (http://mng.bz/w1lR).

10.4.6. Case-study project: live-updating compass readings

The Element, with its onboard WiFi and web utility libraries, lends itself to acting as a web server a little more obviously than the Pico.

In this experiment, you’ll take a look at the high-level process of creating a project with the Element, crafting a custom BLL to support the HMC5883L I²C magnetometer (compass). you’ll use Kinoma’s available WebSocket module to run a WebSocket server on the Element that can emit changes when the compass heading changes. Finally, you’ll construct an HTML document that will connect to the Element’s WebSocket server and update as the compass heading changes (figure 10.23).

The HMC5883L module will be connected to a breadboard. By rotating the breadboard, you can change the magnetometer’s orientation and see the updated heading within the browser—in real time.

Building the circuit

Place the HMC5883L on a breadboard and connect it to the Element as shown in figure 10.24. The SDA and SCL pins on the breakout board connect to the Element’s pins 13 and 14, which, as shown in the pinout in figure 10.20, have support for I²C. Any pin on the Element can be configured as power or ground; pins 11 and 12 are used here because of their proximity to the I²C pins.

Structuring the project

The Element live-compass project consists of four files (figure 10.25):

First, create the package.json file and enter some metadata, as shown in the next listing.

Creating the application’s structure

Kinoma project application modules—main.js in this case—have a general structure. They need to export a default function that implements some event handlers, such as onLaunch() and onQuit(). The launch handler configures the board’s pins and kicks things off.

The module’s basic structure is as follows.

Once the custom HMC5883L module is ready, you’ll come back and fill in the blanks in main.js.

A custom BLL for the HMC5883L

A BLL, or blinking-light library, encapsulates Kinoma-compatible component behavior in a module. A BLL module needs to do certain things. According to the Kinoma documentation, a BLL must export at minimum a pins object defining the type of pins it uses, a configure function, and a close function.

The following listing shows an excerpt from the completed HMC5883L BLL module.

Listing 10.10 only shows a portion of the completed BLL. The complete version of the 5883L BLL can be found in the book’s code repository. You’ll need it if you want to build this experiment: place it in the same directory as the other project files.

Finishing the application code

With the BLL sewn up, the bits in main.js that rely on on the BLL can be filled in. As shown in the following listing, the onLaunch handler sets up the compass sensor on the Element by passing a settings object to Pins.configure().

You also pass a callback function as a second argument to Pins.configure().

Within that callback, you first need to get a WebSocket server going, as shown in the next listing. This code uses the API of the built-in Kinoma WebSocketServer (WebSocketServer was required in listing 10.9).

The code in listing 10.12 emits an initial compass reading when a client connects, but how are compass readings obtained in the first place, and how does the client receive updates when the readings change? The last bits of code for main.js, shown in the following listing, take care of those things.

Client code (HTML)

Finally, you’ll need an HTML page to serve as a WebSocket client and to show the compass headings in real time. This page can be viewed in a browser.

Deploying the compass code

Code is deployed to the Element via the Kinoma Code IDE. Note that the index.html file isn’t served from the Element in this example. Instead, you open that file in a browser once the Element is running the compass application. See the Element quick-start guide (http://mng.bz/84cS) for step-by-step instructions about how to connect to and deploy code to your Element from the Kinoma Code IDE, if you haven’t done so already.

Once the code is deployed and running, you can open up the index.html file in a browser and rotate the breadboard with the attached compass to see the display update in real time.

Summary