4.1 address

an identifier for interfacing with a specific component, device, or board

4.2 baud rate

the rate at which information is transferred, measured in bits per second

4.3 bus

a communications system that transfers data. A "Bus" includes hardware, software, and the protocol

4.4 connected sensing device

a sensing device that communicates with a remote endpoint

4.5 direct measurement

a sample that has been captured from a configured sensor without alteration

4.6 expander

a device that provides additional inputs and/or outputs

4.7 instance

an object that has been created by a function constructor, class constructor, or function factory

4.8 IO

an abbreviation for "Input and Output"

4.9 microcontroller

a single integrated circuit with one or more CPUs, memory, and programmable IO

4.10 protocol

a system of rules that define how data is exchanged between systems

4.11 register

locations in a device's memory that can be written to or read from. These memory locations may contain configuration settings or the current state of the device.

4.12 remote endpoint

a computing system in communication with the microcontroller

4.13 sensing device

a system comprising an embedded controller with at least one attached sensor

4.14 sensor

a device that detects and responds to some type of input from the physical environment, attached to a microcontroller used to capture data

4.15 sensor classification

sensor type, as determined by the real quantity that is, or quantities that are, subject to measurement, e.g. mass, power, or humidity. Uses names of Sensor Classes defined by this Standard. If a sensor measures real quantities defined as properties in multiple unique Sensor Classes, the name of any applicable Sensor Class may be used.

4.16 sensor configuration

user-defined parameters impacting the sampling, processing, representation, and/or transmission of peripheral data

4.17 synthetic measurement

a direct measurement that has been modified in some form so as to potentially lose accuracy, precision, or fidelity

6.1 ECMAScript

This Standard builds on the ECMAScript Standard as defined in ECMA-262. As of this writing, that is ECMAScript 2025.

This Standard is not an extension or subset of ECMAScript Standard. It is a set of APIs to use with that standard. The relationship between ECMA-419 and ECMA-262 is analogous to the relationship between ECMA-402 (ECMAScript Internationalization API) and ECMA-262.

This Standard is intended to be used in strict mode only. Sloppy mode has known issues that detract from building a robust system. Sloppy mode is maintained primarily for web compatibility and provides no benefit to embedded systems.

6.2 Class patterns

A Class Pattern, as used in this Standard, is a combination of requirements and guidelines for a class. For example, the IO Class Pattern defines behaviours for all IO classes.

The standard defines classes in terms of Class Patterns. In the future, there may be true formal classes as found in the ECMAScript Language.

The requirements of a Class Pattern are behaviours defined by this Standard and must be adhered to for a conformant implementation. A Class Pattern can be seen as similar to a collection of Abstract Operations in the ECMA-262.

Guidelines are primarily for extensibility. Extensibility is essential to this Standard as it must be possible to access unique hardware capabilities. Extensibility is problematic because of the potential for collisions. This Standard provides requirements for how extensibility may be implemented.

Unless stated, there are no requirements about class inheritance. An implementation of a class pattern may inherit from Object or any other class, so long as it conforms.

6.3 Independent implementations

This Standard is intended to facilitate multiple independent implementations of the APIs. A given API may warrant an entirely different implementation depending on a variety of factors that include the host hardware, operating system, and ECMAScript engine.

6.4 Self-hosting

The ECMAScript language is defined in terms of a host that provides the runtime environment for the execution of scripts. This Standard does not change that. The APIs defined herein are provided by a host. However, this Standard does anticipate that portions of the runtime environment provided by the host may themselves be implemented in ECMAScript. This Standard refers to a host that includes ECMAScript code in its implementation as self-hosting.

One challenge of self-hosting is fully separating host scripts from hosted scripts to eliminate security, robustness, and compatibility problems. The Compartment model in the Hardened JavaScript proposal is a tool to separate host scripts from hosted scripts. Compartments also allow separation of modules within a host which mitigates supply-chain attacks.

Self-hosted implementations must ensure that no internal properties or methods are visible to client scripts using the implementation. Private fields and private methods as defined by ECMA-262 are one way to shield internal properties and methods from client code.

6.5 Module specifiers

This Standard defines classes which are accessed through modules. Because many embedded systems lack a file system, using file paths to access modules is impractical and contrived. Instead, modules are accessed using bare module specifiers. While such specifiers are currently forbidden in a web browser, they are permitted in other environments.

A namespace prefix is used to minimize the chance of name collisions with other bare module specifiers. This Standard uses the namespace prefix embedded:.

import Digital from "embedded:io/digital";

The "embedded:" namespace prefix is registered as a URI scheme with IANA to reduce the possibility of collisions.

The use of module namespaces in this Standard is intended to be compatible with the Built In Modules Proposal.

For the avoidance of doubt, the use of bare module specifiers by this Standard does not prevent a host from also supporting other kinds of module specifiers for modules not defined by this specification.

6.6 Hardened JavaScript

The Hardened JavaScript proposal extends the ECMAScript language to support provably secure execution of scripts in an environment that includes both trusted and untrusted scripts. The two foundations of Hardened JavaScript are immutability and compartments. Hardened JavaScript makes all primordials immutable prior to the execution of any untrusted script code. This ensures built-in objects behave as defined by the language and disables common attack vectors including prototype poisoning. Compartments allow scripts to sandbox other scripts to limit the globals and modules that are available in the sandbox.

The security guarantees provided by Hardened JavaScript reduce vulnerabilities in systems that combine code from multiple sources, some of which may contain security flaws. The mechanisms proposed by Hardened JavaScript allow for an efficient implementation. Further, the immutability requirement for Hardened JavaScript allows primordials to be stored in read-only memory, reducing RAM use and enabling them to be securely shared by multiple virtual machines.

This Standard is designed to be used with Hardened JavaScript when a runtime security solution is required. If and when the Hardened JavaScript proposal is an approved standard, this Standard will reference it normatively.

Hardened JavaScript consists of two major execution phases — pre-lockdown and post-lockdown. Prior to lockdown, primordials are mutable; afterwards, they are immutable. A host is not required to support pre-lockdown on an embedded system. It may instead complete lockdown during the build process, for example.

6.7 Multitasking

On embedded systems capable of multitasking, this Standard recommends Web workers from the HTML Living Standard for the ECMAScript API. The HTML Living Standard describes workers as "relatively heavy-weight," noting that they "are not intended to be used in large numbers." Consequently, an embedded project may have just a single worker to augment the main task, allowing it to use the full CPU power of a dual-core microcontroller.

Implementations of this Standard must manage resource contention between workers and ensure hardware operations are executed atomically.

A Web worker is not required to provide the same functionality as the main virtual machine: a host may attenuate the functionality available to a worker. One consequence of this attenuation is that the host provider instance and corresponding device global variable may differ between the main task and workers.

6.8 Naming

This Standard uses the lower camel case naming convention (e.g. exampleProperty) for property names.

It follows the ECMAScript convention of naming classes with upper camel case (e.g. ExampleClass) and methods with lower camel case (e.g. exampleMethod).

Callback function names begin with on (e.g. onExampleCallback).

Words are preferred over abbreviations and acronyms (e.g. address instead of addr, clock instead of scl, receive instead of rx), though common acronyms are acceptable (e.g. hz instead of hertz).

6.9 IP address

This Standard represents an IP address value as a string.

An IPv4 address has the form x.x.x.x, where x is a decimal value from 0 to 255 and the values are separated by periods.

An IPv6 address has the form y:y:y:y:y:y:y:y, where y is a four-digit hexadecimal value from 0x0000 to 0xFFFF, encoded with lowercase letters and left-padded with "0" as necessary. The values are separated by colons.

6.10 MAC address

This Standard represents a media access control address (MAC address) value as a string. The value has the form zz:zz:zz:zz:zz:zz, where zz is a two-digit hexadecimal value from 0x0000 to 0xFF, encoded with lowercase letters and left-padded with "0" as necessary. The values are separated by colons.

6.11 Byte Buffer

This Standard uses the term "Byte Buffer" to mean an instance of the following ECMAScript types: ArrayBuffer (resizable or not, immutable or not), SharedArrayBuffer (growable or not), Uint8Array, Int8Array, and DataView.

6.12 Disposable Buffer

This Standard uses the term "Disposable Buffer" to mean an instance of a Byte Buffer with a close method which immediately releases the memory used by the backing buffer. After invoking close, the buffer shall behave as a detached buffer.

6.13 UUID

UUIDs are represented by strings using hexadecimal encoding with lowercase letters, left-padded with "0"as necessary. A 128-bit UUID uses the form "01234567-0000-1000-8000-00805f9b34fb". An abbreviated 16-bit UUID uses the form "180d"; an abbreviated 32-bit, "01234567".

8.1 Asynchronous methods

By default, methods are synchronous: they consume their inputs, perform their work, and generate their result by the time they return. A class may provide asynchronous methods.

Asynchronous methods take an optional final argument which is a completion callback function. A completion callback function is called once, at the completion of the operation to indicate success or failure and deliver the result of the operation.

The first argument to the completion callback is always a result code. A value of null indicates success; an Error object indicates failure. Additional arguments may be specified by the method.

Whether or not a completion callback is provided, the method is performed asynchronously.

If an instance provides any asynchronous methods, it should provide an asynchronous close method.

8.2 constructor

The constructor of the Base Class Pattern takes an options object as its first argument.

The target property is the only property the Base Class Pattern defines in the options object.

Typically there are no other arguments as additional configuration options can and should be added to the options object. However, additional arguments are not prohibited.

It is an error to invoke the constructor without the options object. An exception will be thrown.

The implementation of the constructor should validate all supported option properties before allocating any resources. This behaviour avoids enabling or changing the state of any hardware should the constructor fail due to invalid parameters.

The implementation must ignore any unrecognized properties on the options object.

If the constructor fails to complete execution successfully, it must release any resources allocated prior to exiting.

The constructor must not modify the options object. It must accept an immutable options object.

Once the instance has been successfully constructed, it must not be eligible for garbage collection until it is explicitly released by calling close. This is done so scripts do not need to maintain a reference to the object to prevent it from being collected, similar to setInterval/clearInterval and the W3C Generic Sensor specification.

8.3 close method

The close method releases all resources associated with the instance before completing.

Once the close operation, an Error exception is thrown if any other instance methods are called. It is not an error to call the close method more than once.

Once the close operation completes, the object is eligible for garbage collection.

Once close has been called, calling other methods on the instance throws an exception. The sole exception is close itself which is safe to call multiple times.

For synchronous close:

• the close operation is complete when it returns
• no callbacks may be invoked after the close method is called

For asynchronous close:

• the close operation completes some time after it returns
• the completion callback, if provided, is invoked after close completes
• callbacks may be invoked after close is called and before the completion callback is invoked
• if possible, pending asynchronous operations should be cancelled

8.4 target property

The target property is opaque to the object's implementation. It may be initialized by the constructor using the target property in the options object. Scripts may both read and write the target property, though it is typically only set at construction.

8.5 Callbacks

Instances of the Base Class Pattern typically use function callbacks to deliver asynchronous events.

Callback functions are provided to the instance as properties in the options object.

new Button({
    onPush() {
    },
    onRelease() {
    }
});

Callback functions are invoked with this set to the instance. This can be overridden using standard ECMAScript features, such as arrow functions:

new Button({
    onPush: () => {
    },
    onRelease: () => {
    }
});

The callbacks are stored internally by the implementation. They are not public methods. The callback functions cannot be read and are only set using the constructor's options object.

A callback function may only be invoked when no script is running in its host virtual machine to respect the single-thread evaluation semantics of ECMAScript. This means that callbacks may not be invoked by the instance from within its public method calls, including the constructor.

Callbacks must be invoked in the same virtual machine in which they were created.

9.1 Pin specifier

A pin specifier is an ECMAScript value used by IO classes to refer to hardware connections represented by pins. Typically these pins correspond to a particular connection point on the hardware package, although this is not required.

The value of a pin specifier is host-dependent. It is often a number corresponding to the logical GPIO pin number as per the hardware data sheet (e.g. GPIO 5), but it may be a string ("D1") or even an object ({port: 1, pin: 5}).

9.2 Port specifier

A port specifier is an ECMAScript value used by IO classes to refer to a hardware interface. Port specifier values are defined by the host and are usually either a number or string.

For example, consider a microcontroller may support two serial connections, each with different capabilities that may be configured to be available on a set of pins. The port specifier indicates which serial connection to use.

9.3 constructor

The options object contains the specification of the hardware resources to be used by the instance. For example, the digital class indicates the physical pin to use with a pin property that has a pin specifier value.

If the constructor requires a resource that is already in use — whether by a script or the native host — an Error exception is thrown.

This Standard allows but does not require, an implementation to open multiple instances for the same hardware resource if the instances cannot interfere with each other's operation. For example, this can work for a digital input but would not for a digital output.

The IO Class Pattern is designed to be used both with IO types that have only a current value (e.g. Digital, analog, PWM) and IO types that use streams of data (e.g. serial, SPI).

The IO Class Pattern reserves the io property name in the options object. If present, it must be ignored by IO implementations.

9.4 read method

The read method returns data from the IO instance. If no data is available, it returns undefined. The type of the data returned depends on the value of the format property.

The read method may take any number of arguments, including zero. The arguments are defined by the specific IO type.

If the instance does not support reading (because the IO type is inherently unreadable or because it is configured for write-only) an exception is thrown.

When the format property is "buffer", the read method accepts a data argument that is a Number or Byte Buffer. When it is a Number, read allocates the result as an ArrayBuffer with up to as many bytes as the Number argument. When it is a Byte Buffer, read fills in as many bytes as possible and the result is the number of bytes read as a Number.

For synchronous read, the result is the return value. For asynchronous read, the result is passed to the completion callback as the second argument.

If a resizable Byte Buffer is passed to an asynchronous read and the buffer shrinks so that it cannot hold the number of bytes requested at the time the operation is queued, an error is passed to the completion callback. It is implementation dependent if and how the content of the buffer is modified.

9.5 write method

The write method sends data to the IO instance.

The following conditions cause an Error exception to be thrown: the device cannot accept the data because its buffers are full, the data is incompatible, or a hardware error.

The write method may take any number of arguments, including zero. The arguments are defined by the specific IO type. The type of data accepted by write depends on the value of the format property.

If this instance does not support writing (because the IO type cannot be written or because it is configured for read-only) an Error exception is thrown.

When the format property is "buffer", the write method accepts a data argument that is a Byte Buffer.

Calls to write must write all the data provided. If all the data cannot be output, write must not output any data and instead must throw an exception.

If a non-shared Byte Buffer is passed to an asynchronous write method, the implementation sends the contents of the buffer from the time the operation is queued. If a shared buffer is passed, the implementation may read from the buffer at any time; the caller is responsible for ensuring that the bytes are not modified until the completion callback is invoked.

9.6 format property

The format property is a string that indicates the type of data used by the read and write methods. It is initialized by the constructor to the default defined for its IO type. The format property may be set by the script at any time to change how it reads and writes data.

The following values are defined by the IO Class Pattern for the format property. IO types may choose to support one or more and may define others.

The format property is implemented as a getter and setter. Attempting to set the format property to an unsupported value does not change the value and instead throws an Error exception.

9.7 Callbacks

The IO Class Pattern specifies three callbacks which are set by the options object passed to the constructor. Most IO types operate with or without these callbacks installed, but a particular IO type may require one or more callbacks.

10.1 Digital

The Digital IO class is used for digital inputs and outputs.

import Digital from "embedded:io/digital";

See Annex A for the formal algorithms of the Digital IO Class.

10.2 Digital bank

The DigitalBank class provides simultaneous access to a group of digital inputs or outputs.

import DigitalBank from "embedded:io/digitalbank";

See Annex A for the formal algorithms of the DigitalBank bank IO Class.

10.3 Analog input

The Analog IO class represents an analog input source.

import Analog from "embedded:io/analog";

See Annex A for the formal algorithms of the Analog IO Class.

10.4 Pulse-width modulation

The PWM IO class provides access to the pulse-width modulation capability of pins.

import PWM from "embedded:io/pwm";

See Annex A for the formal algorithms of the PWM IO Class.

10.5 I²C – synchronous IO

The I2C class implements an I²C Initiator to communicate with an I²C Peripheral over I²C bus. The I2C class performs synchronous IO.

import I2C from "embedded:io/i2c";

If synchronous IO is not supported, the constructor throws.

See Annex A for the formal algorithms of the I2C IO Class.

10.6 I²C – asynchronous IO

The I2C.Async class implements an I²C Initiator to communicate with an I²C Peripheral over I²C bus using asynchronous IO.

import I2C from "embedded:io/i2c";

The I2C class provides an implementation using asynchronous IO through the I2C.Async constructor. The I2C.Async constructor is only present if asynchronous IO is supported.

Asynchronous operations occur serially in the order issued.

See Annex A for the formal algorithms of the I2C.Async IO Class.

10.7 System management bus (SMBus) – synchronous IO

The SMBus class extends the I2C class with additional methods to communicate with devices that implement the SMBus protocol. The SMBus class performs synchronous IO.

import SMBus from "embedded:io/smbus";

If synchronous IO is not supported, the constructor throws.

See Annex A for the formal algorithms of the SMBus IO Class.

10.8 System management bus (SMBus) – asynchronous IO

The SMBus.Async class extends the I2C.Async class with additional methods to communicate with devices that implement the SMBus protocol using asynchronous IO.

import SMBus from "embedded:io/smbus";

The SMBus class provides an implementation using asynchronous IO through the SMBus.Async constructor. The SMBus.Async constructor is only present if asynchronous IO is supported.

Asynchronous operations occur serially in the order issued.

See Annex A for the formal algorithms of the SMBus.Async IO Class.

10.9 Serial

The Serial class implements bi-directional serial (UART) communication.

import Serial from "embedded:io/serial";

See Annex A for the formal algorithms of the Serial IO Class.

10.10 Serial Peripheral Interface (SPI)

The SPI class implements a Serial Peripheral Interface (SPI) controller to communicate with a single SPI peripheral.

import SPI from "embedded:io/spi";

See Annex A for the formal algorithms of the SPI IO Class.

10.11 Pulse count

The PulseCount class implements a bi-directional counter typically used with a rotary encoder.

import PulseCount from "embedded:io/pulsecount";

See Annex A for the formal algorithms of the PulseCount IO Class.

10.12 TCP socket

The TCP network socket class implements a general-purpose, bi-directional TCP connection.

import TCP from "embedded:io/socket/tcp";

The TCP socket is not a TCP listener, as in some networking libraries. The TCP listener is a separate class.

See Annex A for the formal algorithms of the TCP IO Class.

const payload = new Float32Array(sensorReading1, sensorReading2, sensorReading3);
const header = Uint8Array.of(0x80, 0x01);
const length = Uint8Array.of(payload.length >> 8, payload.length);
tcp.write(header, {more: true, byteLength: header.byteLength + length.byteLength + payload.byteLength});
tcp.write(length, {more: true});
tcp.write(payload);

10.13 TCP listener socket

The TCP Listener class listens for and accepts incoming TCP connection requests.

import Listener from "embedded:io/socket/listener";

See Annex A for the formal algorithms of the Listener IO Class.

10.14 UDP socket

The UDP network socket class implements the sending and receiving of UDP packets.

import UDP from "embedded:io/socket/udp";

See Annex A for the formal algorithms of the UDP IO Class.

10.15 TLS Client socket

The TLSClient network socket class implements a logical subclass of the TCP class that secures the connection using Transport Layer Security (TLS).

import TLS from "embedded:io/socket/tcp/tls";

A TLS implementation may use certificates from a certificate store. The certificate store is implementation dependent and not specified by this Standard.

All certificate and key data use DER (binary) format, not PEM (Base64 encoded text).

10.16 Audio Input – synchronous IO

import AudioIn from "embedded:io/audio/in";

See Annex A for the formal algorithms of the Audio Input Class.

10.17 Audio Input – asynchronous IO

import AudioIn from "embedded:io/audio/in";

The AudioIn class provides an implementation using asynchronous IO through the AudioIn.Async constructor. The AudioIn.Async constructor is only present if asynchronous IO is supported.

Asynchronous operations occur serially in the order issued.

See Annex A for the formal algorithms of the Audio Input Class Asynchronous.

10.18 Audio Output – synchronous IO

import AudioOut from "embedded:io/audio/out";

See Annex A for the formal algorithms of the Audio Output Class.

10.19 Audio Output – asynchronous IO

import AudioOut from "embedded:io/audio/out";

The AudioOut class provides an implementation using asynchronous IO through the AudioOut.Async constructor. The AudioOut.Async constructor is only present if asynchronous IO is supported.

Asynchronous operations occur serially in the order issued.

See Annex A for the formal algorithms of the Audio Output Class Asynchronous.

10.20 Image Input – synchronous IO

The Image Input provides access to image input sources including cameras. The Image Input conforms to the Peripheral Class Pattern.

import ImageIn from "embedded:io/image/in";

See Annex A for the formal algorithms of the Image Input Class Pattern.

10.21 Image Input – asynchronous IO

import ImageIn from "embedded:io/image/in";

The ImageIn class provides an implementation using asynchronous IO through the ImageIn.Async constructor. The ImageIn.Async constructor is only present if asynchronous IO is supported.

Asynchronous operations occur serially in the order issued.

See Annex A for the formal algorithms of the Image Input Class Asynchronous.

11.1 constructor

Following the Base Class Pattern, the constructor has a single options object argument. The options object defines the hardware connections of the sensor. These use the same properties as the IO types corresponding to the hardware connection. As in the Peripheral Class Pattern, the IO properties in the Provider Class Pattern are grouped to avoid collisions.

The options object is not limited to IO connection information and must contain all information needed by the implementation to establish the connection.

11.2 close method

In addition to releasing all resources as required by the Base Class Pattern, the close method causes the onError callback to be invoked on all open instances. Note that onError may not be invoked from within close (see Callbacks section).

A class may specify that close accepts an optional callback function to invoke after the close operation completes. The callback must the last argument to close. The first argument to the callback is a Number with 0 indicating success and other values indicating failure. Pending callbacks from other operations are invoked before the callback passed to close.

11.3 Callbacks

onReady()

The onReady callback is invoked once the IO Provider instance is ready for use.

The IO provider may not know what IO resources are available until it has successfully established a connection to the remote resource. For this reason, a provider may not have any IO constructors on its instance until the onReady is invoked.

The IO constructors of an IO Provider, if present on the instance, may be used prior to onReady being invoked.

onError()

The onError callback is invoked on a non-recoverable error to indicate that the provider instance can no longer be used.

When a provider fails, its IO instances also become unusable, and consequently onError must also be invoked on each instance.

12.1 constructor

Following the Base Class Pattern, the constructor has a single options object argument. The options object defines the hardware connections of the peripheral. These use the same properties as the IO types corresponding to the hardware connection. For example, an I²C peripheral:

import I2CPeripheral from "embedded:example/i2cperipheral";
import I2C from "embedded:io/i2c";

let t = new I2CPeripheral({
    io: I2C,
    data: 4,
    clock: 5,
    address: 0x30
});

The io property specifies the constructor for the IO Class.

If the peripheral has multiple hardware connections, the options object separates them to avoid collisions. For example, here the peripheral has an I²C connection for primary communication and a digital connection for an interrupt:

import I2CPeripheralWithInterrupt from "embedded:example/i2cperipheralwithinterrupt";
import I2C from "embedded:io/i2c";
import Digital from "embedded:io/digital";

let t = new I2CPeripheralWithInterrupt({
    communication: {
        io: I2C,
        data: 4,
        clock: 5,
        address: 0x30
    },
    interrupt: {
        io: Digital,
        pin: 5
    }
});

The constructor must reset the peripheral hardware to a consistent initial state so the peripheral's behaviour is not dependent on a previous instantiation. This reset may include calling the instance's configure method.

12.2 close method

The close method, as required by the Base Class Pattern, releases all IO connections in use by the instance.

12.3 configure method

The configure method modifies how the peripheral operates. It has a single argument, an options object.

The configure method follows the same rules regarding the options argument as the constructor and therefore may not modify its content.

Because peripherals have many features, the configure method may implement support for many properties. A given call to the configure method should only modify the features specified in the options object.

The Peripheral Class Pattern does not require a script call the configure method to use the peripheral, however specific implementations may require configure to be called.

The configure method may be called more than once to allow scripts to reconfigure the peripheral.

12.4 Accessors for configuration

Classes that follow the Peripheral Class Pattern may choose to provide accessors, e.g. setters and getters, for configuration properties. A setter should behave in the same way as the configure method invoked with a single property. For example, a setter for a property named resolution could be implemented as follows:

class ExamplePeripheral {
    ...
    set resolution(value) {
        this.configure({resolution: value});
    }
}

A getter for the same property could be implemented as follows:

class ExamplePeripheral {
    ...
    get resolution() {
        this.configuration.resolution;
    }
}

13.1 constructor

Following the Peripheral Class Pattern, the constructor has a single options object argument. The options object defines the hardware connections of the sensor.

For example, here the temperature sensor has an interrupt on a Digital pin:

import I2C from "embedded:io/i2c";
import Digital from "embedded:io/digital";

let t = new Temperature({
    sensor: {
        io: I2C,
        data: 4,
        clock: 5,
        address: 0x30
    },
    interrupt: {
        io: Digital,
        pin: 5
    }
});

The constructor must reset the sensor hardware to a consistent initial state so the sensor's behaviour is not dependent on a previous instantiation.

13.2 configure method

The configure method is inherited from the Peripheral Class Pattern. For sensors, it modifies how the sensor operates. This may include the hardware's sampling interval, what data is sampled, and the range of the data sampled.

13.3 sample method

The sample method returns readings from the sensor. The Sensor Class Pattern defines no arguments for the sample method, though individual sensor types may.

The sample method returns an object containing one or more properties. The returned object is mutable. The implementation must return a different object on each invocation to allow callers to accumulate multiple sensor readings.

If the sample data includes timestamps (e.g. when the sample was collected), those timestamps in the returned sample object should conform to the time or ticks properties of the Sample Object specified by the Provenance Sensor Class Pattern.

13.4 Callbacks

The Sensor Class Pattern specifies one callback that is set by the options object passed to the constructor. Individual sensor classes may provide additional callbacks, for instance, to indicate when a sample is available or a sensed condition has been met.

onError()

The onError callback is invoked on a non-recoverable error to indicate that the sensor instance can no longer be used. The only method that should be called is close.

14.1 Compound sensors

A single physical sensor may provide more than one kind of sensor reading. For example, a single sensor package may include both a temperature sensor and a humidity sensor. When a single physical sensor contains two or more logical sensors, the Sample object returned by the sample method must contain a sub-object for each logical sensor. For example, a physical sensor that includes both temperature and humidity sensors would return a Sample object with the following properties:

{
    hygrometer: {
        humidity: 0.5
    },
    thermometer: {
        temperature: 23
    }
}

The name of the property that contains the sub-object is defined by the sensor class. Here thermometer is defined by the Temperature sensor class and hygrometer is defined by the Humidity sensor class. Each sub-object contains a Sample object as defined by its sensor class.

14.2 Accelerometer

The Accelerometer class implements access to a three-dimensional accelerometer. The property name accelerometer is used when part of a compound sensor.

See Annex A for the formal algorithms of the Accelerometer sensor class.

14.3 Ambient light

The AmbientLight class implements access to an ambient light sensor. The property name lightmeter is used when part of a compound sensor.

See Annex A for the formal algorithms of the AmbientLight sensor class.

14.4 Atmospheric pressure

The AtmosphericPressure class implements access to an atmospheric pressure sensor or barometer. The property name barometer is used when part of a compound sensor.

See Annex A for the formal algorithms of the AtmosphericPressure sensor class.

14.5 Carbon Dioxide

The CarbonDioxide class implements access to a sensor that detects the amount of carbon dioxide in air. The property name carbonDioxideDetector is used when part of a compound sensor.

See Annex A for the formal algorithms of the CarbonDioxide sensor class.

14.6 Carbon Monoxide

The CarbonMonoxide class implements access to a sensor that detects the amount of carbon monoxide in air. The property name carbonMonoxideDetector is used when part of a compound sensor.

See Annex A for the formal algorithms of the CarbonMonoxide sensor class.

14.7 Dust

The Dust class implements access to a sensor that detects the amount of dust suspended in air. The property name dustDetector is used when part of a compound sensor.

See Annex A for the formal algorithms of the Dust sensor class.

14.8 Gyroscope

The Gyroscope class implements access to a three-dimensional gyroscope. The property name gyroscope is used when part of a compound sensor.

See Annex A for the formal algorithms of the Gyroscope sensor class.

14.9 Humidity

The Humidity class implements access to a humidity sensor. The property name hygrometer is used when part of a compound sensor.

See Annex A for the formal algorithms of the Humidity sensor class.

14.10 Hydrogen

The Hydrogen class implements access to a sensor that detects the amount of hydrogen in air. The property name hydrogenDetector is used when part of a compound sensor.

See Annex A for the formal algorithms of the Hydrogen sensor class.

14.11 Hydrogen Sulfide

The HydrogenSulfide class implements access to a sensor that detects the amount of hydrogen sulfide in air. The property name hydrogenSulfideDetector is used when part of a compound sensor.

See Annex A for the formal algorithms of the HydrogenSulfide sensor class.

14.12 Magnetometer

The Magnetometer class implements access to a three-dimensional magnetometer. The property name magnetometer is used when part of a compound sensor.

See Annex A for the formal algorithms of the Magnetometer sensor class.

14.13 Methane

The Methane class implements access to a sensor that detects the amount of methane in air. The property name methaneDetector is used when part of a compound sensor.

See Annex A for the formal algorithms of the Methane sensor class.

14.14 Nitric Oxide

The NitricOxide class implements access to a sensor that detects the amount of nitric oxide in air. The property name nitricOxideDetector is used when part of a compound sensor.

See Annex A for the formal algorithms of the NitricOxide sensor class.

14.15 Nitric Dioxide

The NitricDioxide class implements access to a sensor that detects the amount of nitric dioxide in air. The property name nitricDioxideDetector is used when part of a compound sensor.

See Annex A for the formal algorithms of the NitricDioxide sensor class.

14.16 Oxygen

The Oxygen class implements access to a sensor that detects the amount of oxygen in air. The property name oxygenDetector is used when part of a compound sensor.

See Annex A for the formal algorithms of the Oxygen sensor class.

14.17 Particulate Matter

The ParticulateMatter class implements access to a sensor that detects the amount of particulate matter suspended in air. The property name particulateMatterDetector is used when part of a compound sensor.

See Annex A for the formal algorithms of the ParticulateMatter sensor class.

14.18 Proximity

The Proximity class implements access to a proximity sensor or range finder. The property name proximity is used when part of a compound sensor.

See Annex A for the formal algorithms of the Proximity sensor class.

14.19 Soil Moisture

The SoilMoisture class implements access to a soil moisture detector. The property name soilMoistureDetector is used when part of a compound sensor.

See Annex A for the formal algorithms of the SoilMoisture sensor class.

14.20 Switch

The Switch class implements access to a switch sensor. The property name switch is used when part of a compound sensor.

14.21 Temperature

The Temperature class implements access to a temperature sensor. The property name thermometer is used when part of a compound sensor.

See Annex A for the formal algorithms of the Temperature sensor class.

14.22 Touch

The Touch class implements access to a touch panel controller. The property name touch is used when part of a compound sensor.

See Annex A for the formal algorithms of the Touch sensor class.

14.23 Volatile Organic Compounds

The VolatileOrganicCompounds class implements access to a sensor that detects the amount of volatile organic compounds suspended in air. The property name vocDetector is used when part of a compound sensor.

See Annex A for the formal algorithms of the VolatileOrganicCompounds sensor class.

15.1 constructor

Following the Peripheral Class Pattern, the constructor has a single options object argument. The options object defines the hardware connections of the display. These use the same properties as the IO types corresponding to the hardware connection.

A Display Class is not required to have properties to configure its hardware connections. For example, a memory-mapped display may have no external connections. Or, a Display Class may be preconfigured for the hardware of a specific host.

15.2 configure method

The following table enumerates the properties defined for the options object argument:

The Display Class Pattern does not define default values for these properties to allow the host to provide default values that are appropriate for its hardware. Implementations may provide the current configuration through the configuration property defined by the Provenance Sensor Class Pattern.

15.3 begin method

The begin method starts the process of updating the display's pixels. If no arguments are passed, the entire frame buffer is updated starting at the top-left corner (coordinate {0, 0}), proceeding left-to-right, top-to-bottom, ending at the bottom-right corner (coordinate {display.width, display.height}).

If an options object is passed as the sole argument, the object may contain x, y, width, and height properties that define a rectangular area to update. The rectangle must fit within the bounds of the display (e.g. {0, 0, display.width, display.height}) or a RangeError is thrown.

A display may not support all possible update areas. For example, a display may only support updates aligned to even horizontal pixels. A RangeError is thrown if an unsupported update area is passed to begin. Prior to calling begin, the adaptInvalid method may be used to adjust the update area to the capabilities of the display.

The options object has an optional continue property to support discontiguous updates on displays that use page flipping to swap between multiple frame buffers. When continue is false, the default value, the call to the begin method starts to update a new frame buffer. Calling begin with continue set to true continues updating the same frame buffer rather than starting a new one.

An Error exception is thrown if the begin method is called more than once without an intervening call to the end method, unless continue is set to true in the successive calls. For example, this is a valid call sequence to update three horizontal slices of the display.

display.begin({x: 0, y: 0, width: 240, height: 10});
display.send(pixels);
display.begin({x: 0, y: 20, width: 240, height: 10, continue: true});
display.send(pixels);
display.begin({x: 0, y: 40, width: 240, height: 10, continue: true});
display.send(pixels);
display.end();

15.4 send method

The send method delivers one or more horizontal scan lines of pixel data to the display. The sole argument to send is a Byte Buffer of pixels. The pixels are stored in a packed array with no padding between scan lines. The format of the pixels matches the format property of the options object of the configure method.

15.5 end method

The end method finishes the process of updating the display's pixels, by making all pixels visible on the display. Any buffered pixels provided to the send method must be flushed. If the display uses page flipping, the page must be flipped to the most recently updated frame buffer.

15.6 adaptInvalid method

The adaptInvalid method accepts a single options object argument that includes x, y, width, and height properties that describe an area of the display to be updated. It adjusts these properties as necessary so that the result is valid for the display and encloses the original update area.

Consider a display which limits the update area horizontally to even pixel positions. The following code calls a display's adaptInvalid method with odd numbers for both left and right edges of the update area:

const area = {x: 3, y: 20, width: 10, height: 20};
display.adaptInvalid(area);
display.begin(area);
display.send(pixels);
display.end();

An implementation of adaptInvalid to apply the rules above, if implemented in ECMAScript, would be:

function adaptInvalid(options) {
    if (options.x & 1) {
        options.x -= 1;
        options.width += 1;
    }
    if (options.width & 1) {
        options.width += 1;
    }
}

Some displays require that the update area only include full scan lines. The following function shows the implementation for such a display, assuming a scanline width of 128 pixels;

function adaptInvalid(options) {
    options.x = 0;
    options.width = 128;
}

For displays that only support full screen updates, adaptInvalid updates the rectangle to be the full display dimensions. The following function shows the implementation for a QVGA (320 x 240) display:

function adaptInvalid(options) {
    options.x = 0;
    options.y = 0;
    options.width = 320;
    options.height = 240;
}

15.7 Instance properties

width

The width of the display in pixels as a number. This property is read-only. This value may change based on the configuration, for example, when changing the rotation causes the orientation to change from portrait to landscape.

height

The height of the display in pixels as a number. This property is read-only. This value may change based on the configuration, for example, when changing the rotation causes the orientation to change from portrait to landscape.

15.8 Pixel format values

16.1 Properties of constructor options object

16.2 configure method

The following property is defined for the options object.

16.3 time property

The current time of the RTC. Set this property to change the current time of the RTC. This value is an ECMAScript time value contained in a Number.

The resolution of the RTC component may impact the values. For example, an RTC with one-second resolution may return time values with a milliseconds of zero.

If the time is unavailable (for example, because it has not been set or is otherwise invalid on the RTC), the returned value is undefined.

16.4 configuration property

The configuration property returns an object containing the current configuration of the RTC. It contains the alarm property, if supported.

The configuration property is introduced in the Provenance Sensor Class Pattern.

17.1 Properties of constructor options object

17.2 connect method

Initiates the process of connecting to a network. If a connection attempt is already in progress, connect throws an exception.

The sole argument is an options object. Each Network Interface class defines properties for the options object.

17.3 disconnect method

Disconnects from the currently connected network. If in the process of connecting, the connection attempt is abandoned. If already disconnected, does nothing. No arguments are specified.

17.4 connection property

The read-only connection property indicates the current connection state of the network interface as a number. The following values are defined:

Larger values indicate a later stage in the connection process. This allows values to be compared with greater and less than operators. Additional states may be added by specific types of network interfaces.

17.5 MAC property

The read-only MAC property is the MAC address assigned to the network interface as a string. If the MAC address is unavailable, the value is undefined.

17.6 address property

The read-only address property is the IP address assigned to the network interface as a string. If the address has not yet been assigned, the value is undefined.

17.7 Ethernet Network Interface

The Ethernet Network Interface is a logical subclass of the Network Interface Class Pattern for Ethernet network interfaces.

import Ethernet from "embedded:network/interface/ethernet";

See Annex A for the formal algorithms of the Ethernet Network Interface.

17.8 Wi-Fi Network Interface

The Wi-Fi Network Interface is a logical subclass of the Network Interface Class Pattern for Wi-Fi network interfaces.

import WiFi from "embedded:network/interface/wifi";

See Annex A for the formal algorithms of the Wi-Fi Network Interface.

18.1 resolve method

The resolve method begins the process of resolving a DNS name to an address. Several resolve operations may be queued and be pending at the same time. The resolve requests complete in an implementation dependent order, which may not be the order requested.

The first argument is a required options object. The second argument is a required completion callback function that is invoked when resolution completes. If successful, the resolved address is provided in the second argument and the requested hostname in the third.

18.2 DNS over UDP

DNS over UDP is a logical subclass of the Domain Name Resolver Class Pattern that resolves DNS names over UDP.

import Resolver from "embedded:network/dns/resolver/udp";

18.3 DNS over HTTPS (DoH)

DNS over HTTPS is a logical subclass of the Domain Name Resolver Class Pattern that resolves DNS names using an HTTPS connection (DoH).

import Resolver from "embedded:network/dns/resolver/doh";

19.1 Properties of constructor options object

19.2 getTime method

The getTime method initiates a time synchronization operation. Only one time synchronization operation may be active at a time. getTime throws throws on requests made before the current request completes. The sole argument is a required completion callback function that is invoked when synchronization completes. If successful, the ECMAScript time value is provided in the second argument as a Number.

20.1 Data format

The HTTPClient class data format is always "buffer".

20.2 close method

In addition to the behaviours defined in the Base Class Pattern, all outstanding requests are cancelled.

20.3 request method

Queues an HTTP request described by the required options object, the sole argument.

The options object supports the following properties:

The return value of the request method is an HTTP Client Request instance. This instance is the receiver when the callback functions of the options object are invoked. The request instance has read and write methods.

20.4 HTTP Client Request instance

The HTTP Client Request instance conforms to the IO Class Pattern. It is instantiated by the HTTP Client and so has no constructor. No close method is available because the protocol does not support cancelling a request in progress.

21.1 Data format

The HTTPServer class data format is always "buffer".

21.2 Properties of constructor options object

21.3 close method