Overview: The XDK110

The Bosch Cross Domain Development Kit (XDK) is a programmable sensor device for building IoT applications. It contains a wide range of sensors and means of connectivity and is extensible using its extension bus. Due to its versatility it also serves as reference platform for Mita.

To learn more about the XDK head over to http://xdk.io.

Implemented System Resources

Currently implemented sensors, connectivities and buses in the XDK110 platform:

Sensors Connectivities Buses IO
Accelerometer LED GPIO SD Card
Gyroscope ADC I2C
Magnetometer BLE
Humidity WLAN
Light
Pressure MQTT
Temperature Eclipse Hono over MQTT
Noise sensor REST over HTTP
Two buttons LoRa

For the gyroscope you can choose from three different variants:

  1. Pre-calibrated, more robust through sensor fusion
  2. Direct access to BMI160
  3. Direct access to BMG160

Configuration

Binary Name

To customize the produced binary name configure XDK110.applicationName: string . The default name is MitaApplication:

setup XDK110 {
  applicationName = "ShockDetector";
}

Startup Delay

To debug the startup process you can configure a startup delay so the XDK can connect via USB before setting up devices, connectivity, etc.:

setup XDK110 {
  startupDelay = 5000; /* wait 5 seconds before initialization */
}

Extension Bus Power

Per default the XDK doesn’t power the 2.5V and 3.3V lines on its extension bus. Some system resources like I2C or GPIO already change this, however in some cases you need to do this manually for example when using the ADC with a microphone:

setup XDK110 {
  powerExternalDevices = true;
}

Sensors

Any sensor can be used without configuring it. It will be initialized with sensible defaults. If you want to change a sensor’s default hardware parameters just set it up, e.g. the accelerometer:

setup accelerometer {
  // change the bandwidth of the low-pass filter
  bandwidth = BW_1000Hz;
}

Content assist (CTRL+Space) will provide you with all available configuration items and their valid values.

Temperature, pressure and humidity are available from a single resource: environment.

Device Information

The XDK offers some information you can read out via modalities.

Power Status

An approximation of whether the device is charging or on battery, and what the battery level is can be read out using XDK110.powerStatus. For example:

every button_one.pressed {
    let ps = XDK110.powerStatus.read();
    where(ps) {
        is(PowerStatus.Battery -> level) {
            println(`Battery level: approx. ${level}%`);
        }
        is(PowerStatus.Corded) {
            println("Charged");
        }
    }   
}

This is only an approximation based on the voltage level read out of channel 7. During charging the reported level can be over 100%.

Connectivities

Hardware

Hardware connectivities are available as named singletons: this means that you can configure each connectivity only once and need to give it a name. These connectivities however offer multiple instantiation of their signals. This means that for example the LED resource can provide up to three different signals for the yellow, orange and red LED.

Software

Software connectivities can have as many instances as you want. Both HTTP REST and MQTT require you to specify a WLAN instance as a transport layer.

Buses

GPIO

GPIO is a named singleton: you can instantiate it once and need to give it a name. Each of the 21 available GPIO pins can be configured as either input or output. Input pins can be operated in different modes:

  • pull up/pull down: the pin is connected to high or low via a resistor, so that if the pin is not driven from the outside it returns to a set state.
  • pull up with glitch filter: like pull up except for small glitches being filtered out.
  • no pull: the pin floats freely, i.e. if it is not driven it keeps its current state except for environmental influences and self-drain.

I2C

I2C can be instantiated multiple times so you can model different devices on the same bus. You can exchange either single words from one to four byte or complete messages as arrays of integer words. For multi-byte words, both little and big endianess are supported with the default being the XDK’s endianess, little endian.

Events

Some sensors provide events you can react to. These events are things like “device moved” (accelerometer.any_motion) or “button was pressed” (button_one/button_two.pressed).

The platform itself provides a special startup event which is triggered after the device has fully started up. This means that all resources are initialized, for example WLAN is connected, sensors collect data, and all events are enabled.

Specification

Sensors

Accelerometer (BMA280)

The BMA280 is a tri axial, low-g acceleration sensor with digital output for consumer applications. It allows measurements of acceleration in three perpendicular axes.

Configuration

Name Description
range: BMA280_Range The range of acceleration we want to measure. Default: 2G
bandwidth: BMA280_Bandwidth The low-pass filter bandwidth used by the BMA. Default: 500Hz
any_motion_threshold: uint32 The threshold of acceleration that has to be crossed before an any motion event is triggered. Default: 20
no_motion_threshold: uint32 The threshold of acceleration that must not be exceeded for a no motion event to be triggered. Default: 20

Modalities

Name Description
x_axis: int32 The X axis of the BMA280.
y_axis: int32 The Y axis of the BMA280.
z_axis: int32 The Z axis of the BMA280.
magnitude: int32 The L2 norm of the acceleration vector: sqrt(x^2 + y^2 + z^2)

Events

Name Description
any_motion The any motion event (also called activity) uses the change between two successive acceleration measurements to detect changes in motion. An event is generated when this change exceeds the any_motion_threshold.
no_motion The no motion event (also called any inactivity) uses the change between two successive acceleration measurements to detect changes in motion. An event is generated when this change consecutively stays below the no_motion_threshold.
low_g The low g event is based on comparing acceleration to a threshold which is most useful for free-fall detection.
high_g The high g event is based on comparing acceleration to a threshold to detect shocks or other high acceleration events.
single_tap A single tap is an event triggered by high activity followed shortly by no activity.
double_tap A double tap consists of two single tap events right after one another.
flat The flat event is triggered when the device is flat on the ground.
orientation
fifo_full
fifo_wml
new_data This event serves the asynchronous reading of data. It is generated after storing a new value of z-axis acceleration data in the data register.

Gyroscope (Calibrated, Sensor Fusion)

This sensor is a front end for a software library that improves on accuracy and physical limititations of the built-in sensors using sensor fusion.

Alternatively you can access two hardware sensors directly: BMI160 and BMG160

This virtual sensor only offers modalities.

Modalities
Name Description
x_axis: int32 The X axis of the gyroscope
y_axis: int32 The Y axis of the gyroscope
z_axis: int32 The Z axis of the gyroscope

Gyroscope (BMI160)

The BMI160 is a small, low power, low noise 16-bit inertial measurement unit designed for use in mobile applications like augmented reality or indoor navigation which require highly accurate, real-time sensor data.

Configuration

Name Description
bandwidth: BMI160_Bandwidth The low-pass filter bandwidth used by the BMI160. Default: 39.9Hz.
range: BMI160_Range The range the BMI160 should measure in. Default: 2000 deg/s.

Modalities

Name Description
x_axis: int32 The X axis of the BMI160
y_axis: int32 The Y axis of the BMI160
z_axis: int32 The Z axis of the BMI160

Gyroscope (BMG160)

The BMG160 is an ultra-small, digital 3-axis angular rate sensor with a measurement range up to 2000°/s and a digital resolution of 16 bit for consumer electronics applications.

Configuration

Name Description
bandwidth: BMI160_Bandwidth The low-pass filter bandwidth used by the BMG160. Default: 523Hz.
range: BMI160_Range The measurement range of the BMG160. Default: 2000 deg/s.

Modalities

Name Description
x_axis: int32 The X axis of the BMG160
y_axis: int32 The Y axis of the BMG160
z_axis: int32 The Z axis of the BMG160

Magnetometer (BMM150)

The BMM150 is a low power and low noise 3-axis digital geomagnetic sensor to be used in compass applications.

Configuration

Name Description
mode: BMM150_Preset One of four preset modes. Default: Regular.

Modalities

Name Description
x_axis: int32 The X axis of the BMM150
y_axis: int32 The Y axis of the BMM150
z_axis: int32 The Z axis of the BMM150
resistance: uint16 The resistance of the BMM150

Environment (BME280)

The BME280 is a combined digital humidity, pressure and temperature sensor based on proven sensing principles.

Configuration

Name Description
power_mode: BME280_PowerMode The BME280 power mode. Default: Normal.
standby_time: uint32 The standby time used in normal mode in milliseconds. Beware that the value supplied here will be clipped to the nearest valid value.
temperature_oversampling: BME280_Oversampling Reduces noise in the temperature measurement by over sampling. Higher oversampling settings reduce noise but increase measurement time and power consumption.
pressure_oversampling: BME280_Oversampling Reduces noise in the pressure measurement by over sampling. Higher oversampling settings reduce noise but increase measurement time and power consumption.
humidity_oversampling: BME280_Oversampling Reduces noise in the humidity measurement by over sampling. Higher oversampling settings reduce noise but increase measurement time and power consumption.

Modalities

Name Description
temperature : int32 The temperature reported by the BME280.
pressure : uint32 The pressure reported by the BME280.
humidity : uint32 The humidity reported by the BME280 in percentage.

Light(MAX44009)

The XDK light sensor.

Configuration

Name Description
manual_mode: bool Enables the manual configuration of integration time and high brightness mode. If set to false (default) the chip automatically selects those values. Default: false.
integration_time: MAX44009_IntegrationTime The integration time is the time the sensor collects light for. In automatic mode (manual mode set to false) the chip automatically selects the integration time. Default: 800ms.
high_brightness: bool Set to true so that only 18 of the photo diode current goes to the ADC. This mode is used in high-brightness situations to avoid saturation/clipping effects of the ADC. Default: false.
continuous_mode: bool In default mode (false) the IC measures lux intensity only once every 800ms regardless of integration time. This mode allows the part to operate at its lowest possible supply current.

In continuous mode (true) the IC continuously measures lux intensity. That is, as soon as one reading is finished, a new one begins. If integration time is 6.25ms, readings are taken every 6.25ms. If integration time is 800ms, readings are taken every 800ms. In this mode, the part consumes slightly higher power than in the default mode. Default: false.

Modalities

Name Description
intensity: uint32 The light intensity of the MAX44009.

Noise Sensor

The noise sensor uses the XDK’s microphone to detect noise around it. The noise is calculated over 256 microphone samples. Note that this value is without unit and needs to be calibrated/converted by your application if you require absolute noise level measurements.

Configuration

Name Description
samplingFrequency: uint32 How often the microphone is sampled in Hertz. Default: 2560Hz.
timeout: uint32 If not enough samples are ready how long to wait for additional samples in milliseconds. Default: 100ms.

Modalities

Name Description
noise: float An uncalibrated noise level. Should not enough samples be ready when getting this modality even after waiting timeout milliseconds this will throw an exception.

Buttons

The XDK features two buttons. Pressed and released are encoded by true and false in Mita. Button presses can be detected using event handlers, i.e. every button_one.pressed.

Modalities

Name Description
is_pressed: bool True if the button is pressed in this very right moment. False otherwise.

Events

Name Description
pressed Fires after the button was pressed.
released Fires after the button was released.

Connectivities

LED

The XDK features three custom usable LEDs in red, orange and yellow. On and off are encoded using true and false in Mita.

Modalities

Name Description Parameters
light_up: bool Represents one of the three LEDs. color: LedColor One of Yellow, Orange or Red.

ADC

The XDK’s ADC (Analog Digital Converter) can measure voltages against internal or external potentials.

Configuration

Name Description
externalReferenceVoltage: uint16 The reference voltage to measure against when you use an external reference voltage in a signal in [mV].

Signals

Name Description Parameters
channel: uint16 An ADC channel, read only. [mV] channel: ADC_Channel Which channel to measure.
referenceVoltage: ADC_Reference_Voltage Which voltage to measure against. Default: 2.5V internal voltage reference.
resolution: ADC_Resolution Default: 12 bit
sampleTime: ADC_SampleTime Over how many clock cycles the ADC samples its input. Default: 16 cycles.

BLE

BLE (Bluetooth Low Energy) allows the XDK to communicate over short range, up to 50m, with various devices like smartphones. In BLE a server continuously advertises all characteristics and clients can connect without requiring further interaction or authentication.

Configuration

Name Description
deviceName: string The name of the device as advertised via GAP.
macAddress: string MAC address of the device. Must start with FC-D6-BD. You may use either colon : or dash - as byte separators.
serviceUID: uint32 The last four bytes of the UUID of the GATT service we’ll create.
advertisingInterval: int16 The GAP advertisement interval. Default: 1000.

Signals

Name Description Parameters
bool_characteristic(): bool A boolean GATT characteristic. UUID: uint32 The last four bytes of the characteristic UUID. Defaults to the hash code of the VCI name.
uint32_characteristic(): uint32 An unsigned integer GATT characteristic. UUID: uint32 The last four bytes of the characteristic UUID. Defaults to the hash code of the VCI name.
int32_characteristic(): int32 A signed integer GATT characteristic. UUID: uint32 The last four bytes of the characteristic UUID. Defaults to the hash code of the VCI name.

WLAN

WLAN is one of the hardware connectivities available on the XDK. Configuration is done using sum types. Even though the concept of sum types may be daunting they are actually very easy to use. Say you want to configure authentication. Content assist (CTRL+Space) offers you three different choices: None, Enterprise and Personal. Each accepts a different number of parameters. For example to configure a WLAN with WPA2 Personal you would write this:

setup net: WLAN {
  ssid = "MyWlan";
  authentication = Personal(psk = "mySecretKey");
  /* ... */
}

Configuring IP address works the same: you can choose from either Dhcp or Static.

Content assist will help you fill in all parameters.

Configuration

Name Description
Required authentication: Authentication How to authenticate to the WLAN network.
Required ssid: string The SSID of the WLAN network we want to connect to.
isHostPgmEnabled: bool If true, server certificate will be uploaded to the WLAN chip CC3100. Make sure to update service pack of the WLAN and then upload the certificate. Certificate must placed under XDK110/common/certs/XDKDummy. Default: false.
ipConfiguration: IpConfiguration How to configure IP address. Default: Dhcp().

MQTT

MQTT is a messaging protocol for low bandwidth networks. The current implementation is based on the serval stack. MQTT requires a setup WLAN resource.

Example

setup net: WLAN { /* ... */ }

setup backend: MQTT {
  transport = net;
  url = "mqtt://iot.eclipse.org";
  clientId = "XDK42";

  var telemetry = topic("telemetry");
}

every 100 milliseconds {
  backend.telemetry.write(`${accelerometer.magnitude.read()}`);
}

Configuration

Name Description
Required transport: WLAN The transport layer used for communication.
Required url: string The URL pointing to the MQTT broker, for example: mqtt://does-not.exist:1883. You can use MQTT with TLS by specifying the protocol mqtts:// instead of mqtt://. Doing so requires you to specify the expected server certificate with certificatePath.
Required clientId: string A unique name the broker can use to identify devices. No two clients may have the same name per broker.
authentication: MqttAuthentication Username/Password authentication or unauthenticated, for example authentication = Login("user", "pass"). Default: None().
lastWill: MqttWill The last will that will be published on a forceful disconnect. Either NoWill() or LastWill(topic="topic", message="message", qos=1). Default: NoWill().
cleanSession: bool The clean session flag indicates to the broker whether the client wants to establish a clean session or a persistent session where all subscriptions and messages (QoS 1 & 2) are stored for the client. Default: false.
keepAliveInterval: uint32 The keep alive interval (in seconds) is the time the client commits to for when sending regular pings to the broker. The broker responds to the pings enabling both sides to determine if the other one is still alive and reachable. Creates an automatic ping task that pings twice in this interval. Default: 60.
certificatePath: string The path to the expected server certificate used for MQTT with TLS. Can be an absolute path like C:\certificates\mosquitto.crt or /etc/ssl/certs/mosquitto.crt or a relative path like certificates/server.crt. In the latter case this will look for the certificate relative to the project root. The certificate needs to be in PEM format (-----BEGIN CERTIFICATE-----/-----END CERTIFICATE-----). This configuration item is required when using MQTT over TLS.
sntpServer: string To verify the server’s certificate the XDK needs to get the current time over SNTP. Per default it connects to pool.ntp.org:123, however if for some reason like being in a closed network you cannot access this NTP server you can specify your own.

Signals

Name Description Parameters
topic: string Publishes a message to a particular topic. name: string The topic’s name.
qos: uint32 Default: 0

Eclipse Hono

Mita implements a HonoMqtt resource you can use to easily connect to an Eclipse Hono service via MQTT.

Example

setup net: WLAN { /* ... */ }

setup backend: HonoMqtt {
  transport = net;
  url = "mqtt://iot.eclipse.org";
  clientId = "XDK42";
  authentication = Authenticated(username="consumer@HONO", password="verysecret");

  var telemetry = telemetry(qos=0);
}

every 100 milliseconds {
  backend.telemetry.write(`${accelerometer.magnitude.read()}`);
}

Configuration

Name Description
Required transport: WLAN The transport layer used for communication.
Required url: string The URL pointing to the MQTT broker, for example: mqtt://does-not.exist:1883.
Required clientId: string A unique name the broker can use to identify devices. No two clients may have the same name per broker.
Required authentication: HonoAuthentication Credentials or identification for authentication to the Hono network.
certificatePath: string The path to the expected server certificate used for MQTT with TLS. Can be an absolute path like C:\certificates\mosquitto.crt or /etc/ssl/certs/mosquitto.crt or a relative path like certificates/server.crt. In the latter case this will look for the certificate relative to the project root. The certificate needs to be in PEM format (-----BEGIN CERTIFICATE-----/-----END CERTIFICATE-----). This configuration item is required when using MQTT over TLS.
sntpServer: string To verify the server’s certificate the XDK needs to get the current time over SNTP. Per default it connects to pool.ntp.org:123, however if for some reason like being in a closed network you cannot access this NTP server you can specify your own.

Signals

Name Description Parameters
telemetry: string Publishes a message to a particular topic. qos: uint32 Default: 0
event: string Publishes a message to a particular topic. qos: uint32 Default: 0

REST over HTTP

Using REST you can easily talk to servers over HTTP. REST defines a stateless interface with a simple URL scheme. Normally a REST server consists of a versioned endpoint like http://api.github.com/v3 which then provides different resources, for example api.github.com/v3/repos/eclipse/mita/branches and /repos/eclipse/mita/issues.

Currently only writing is supported.

Example

setup net: WLAN { /* ... */ }

setup backend: HttpRestClient {
  transport = net;
  endpointBase = "http://jsonplaceholder.typicode.com";

  var posts = resource("/posts");
}

every 100 milliseconds {
  backend.branches.write(`${accelerometer.magnitude.read()}`);
}

Configuration

Name Description
Required transport: WLAN The transport layer used for communication.
Required endpointBase: string The server URL base to which REST requests are made.
headerContent: string A custom header which is added to each HTTP request. Example: "X-Auth: MySecretToken\nX-Version: 1.0".

Signals

Name Description Parameters
resource: string A REST resource on the server. endpoint: string The REST path to the resource.
writeMethod: HttpMethod Which method to use when writing. Default: POST
readMethod: HttpMethod Which method to use when reading. Default: GET

LoRa

LoRa is a low-power network for IoT. Since bandwidth is usually extremely limited you should only send small messages infrequently. In this implementation there are two ways to send data: either raw bytes or CayenneLPP messages, a serializable predefined format.

Receiving messages is currently not supported.

Example

setup lora: LoRa {
  region = EU;
  loraAppKey = [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];
  loraAppEui = [0,0,0,0,0,0,0,0];

  var r = raw(0, Unconfirmed);
  var c = cayenne(1, Confirmed);
}

every 1 hour {
  let data: array<CayennePayload, 1>;
  data[0] = CayennePayload.Accelerometer(
    accelerometer.x_axis.read() as int16, 
    accelerometer.y_axis.read() as int16, 
    accelerometer.z_axis.read() as int16
  );
  lora.c.write(data);
}

every 10 minutes {
  let data: array<uint8, _> = [0xCA, 0xFE];
  lora.r.write(data);
}

Configuration

Name Description
Required region: Region Whether you are using the EU or US LoRa module.
Required loraAppKey: array<uint8> The key of your application in big-endian format (MSB first).
Required loraAppEui: array<uint8> The EUI of your application in big-endian format (MSB first).
loraDeviceEui: array<uint8> Optionally set the device’s EUI. If you don’t set this the predefined EUI of your LoRa board will be used.
adaptiveDataRate: bool Control whether adaptive data rate is turned on. Default: true.
bandFrequency: uint16 Configure the band frequency according to your gateway in MHz. Valid values are for the EU module: 433 MHz and 868 MHz, and for the US module 915 MHz. Defaults: EU: 868, US: 915
rx2Frequency: uint32 Configure the Rx2 frequency according to your gateway in kHz. Valid values are for the EU module: 433050 kHz to 434790 kHz and 863000 kHz to 870000 kHz, and for the US module: 923300 kHz to 927500 kHz. Defaults: EU: 869525 kHz, US: 923300 kHz
rx2DataRate: uint8 Configure the Rx2 data rate according to your gateway. Valid values are for the EU module: 0 to 7, and for the US module: 8 to 13. Defaults: EU: 0, US: 8
dataRate: uint8 Configure the data rate according to your gateway. Valid values are for the EU module: 0 to 7, and for the US module: 0 to 4. Default: 3

Signals

Name Description Parameters
raw: array<uint8> Send data input as raw bytes. portNum: uint8 Which port to use. Default: 1
confirmation: LoRaMessageConfirmation Whether to send confirmed messages. One of Confirmed and Unconfirmed. Default: Unconfirmed
cayenne: array<CayennePayload> Send serialized CayenneLPP messages. portNum: uint8 Which port to use. Default: 1
confirmation: LoRaMessageConfirmation Whether to send confirmed messages. One of Confirmed and Unconfirmed. Default: Unconfirmed

Cayenne Messages

The following CayenneLPP messages are supported via a sum type:

alt CayennePayload {
    DigitalInput: uint8
  | DigitalOutput: uint8
  | AnalogInput: int16
  | AnalogOutput: int16
  | IlluminanceSensor: uint16
  | PresenceSensor: uint8
  | TemperatureSensor: int16
  | HumiditySensor: uint8
  | Accelerometer: int16, int16, int16
  | Barometer: uint16
  | Gyrometer: int16, int16, int16
  | GpsLocation: {Latitude: int32, Longitude: int32, Altitude: int32}
}

Constructing them works like in the example above or as described in the documentation of sum types. For example to create a GPS location message type CayennePayload.GpsLocation(Latitude=lat, Altitude=alt, Longitude=lon).

Buses

GPIO

GPIO provides bit-wise communication with the environment. Low (0V) and high (3.3V) are represented by false and true.

Example

setup test: GPIO {
  var out = digitalOut(pin = PA1, initialValue = false);
  var inp = digitalIn(pin = PB2, mode = PullDown);
}

every 100 milliseconds {
  test.out.write(true);
  let x = test.inp.read();
}

Signals

Name Description Parameters
digitalIn: bool A GPIO-pin configured in input mode. pin: GPIOPin which pin to configure.
mode: GPIOMode whether this pin is pull up, pull down or floating.
digitalOut: bool A GPIO-pin configured in output mode. pin: GPIOPin which pin to configure.
initialValue: bool The pin’s initial value after startup. Default is low (false).

I2C

The I2C bus provides access to interfaced devices via I2C.

Configuration

Name Description
Required deviceAddress: uint8 The slave address identifying the interfaced device on the I2C bus.
byteOrder: ByteOrder Byte ordering for multi-byte words. Default is little endian, the XDK’s internal order.

Signals

Name Description Parameters
register_intType:intType A device register of size and sign specified by intType. address: uint8 the register’s address.
I2CMode: I2CMode whether this register is read, write, both or none. This only has an effect on validation, not on initialization.
array_register_ intType : array<intType> A device register consisting of multiple words of size and sign specified by intType. address: uint8 the register’s starting address.
I2CMode: I2CMode whether this register is read, write, both or none. This only has an effect on validation, not on initialization.
length: uint8 how many words this register consists of.

IO

SD Card

SD cards can be used to log data without connectivity. Only FAT32 is supported.

There are different kinds of file access:

  • read or write
  • resuming/appending or rewinding
  • text or binary

Resuming only applies to read access to files. It means that, when you do consecutive reads, the second reads picks up where the first left of.

Appending only applies to write access to files. It means that, when you write to an already existing file, you will always append content.

Rewinding applies to both kinds of accesses to files. It means that reads or writes always start at the beginning of the file. When writing, the file will always be truncated first.

Text means you will get null terminated strings, where binary will give you blocks of bytes.

In all cases, writing will ensure that the file exists and create it if it doesn’t.

You can declare multiple files with the same path; this way you can read and write at the same time or emulate pipes.

Files will not stay open between calls, this means that you can safely declare a file with write access multiple times, for example to read it in both text- and binary-mode.

Configuration

Name Description Parameters
resumingTextRead: string Provides read access to a file. Continues reading from last position. filePath: string The absolute path to the file.
blockSize: uint32 The size of the buffer to be read at once.
appendingTextWrite: string Provides write access to a file. Appends to existing files. filePath: string The absolute path to the file.
rewindingTextRead: string Provides read access to a file. Always reads from the start of the file. filePath: string The absolute path to the file.
fileSize: uint32 The size of the buffer to be read at once.
rewindingTextWrite: string Provides write access to a file. Always truncates the file. filePath: string The absolute path to the file.
resumingBinaryRead: array<uint8> Provides read access to a file. Continues reading from last position. Reads bytes instead of text. filePath: string The absolute path to the file.
blockSize: uint32 The size of the buffer to be read at once.
appendingBinaryWrite: array<uint8> Provides write access to a file. Appends to existing files. Reads bytes instead of text. filePath: string The absolute path to the file.
rewindingBinaryRead: array<uint8> Provides read access to a file. Always reads from the start of the file. Reads bytes instead of text. filePath: string The absolute path to the file.
fileSize: uint32 The size of the buffer to be read at once.
rewindingBinaryWrite: array<uint8> Provides write access to a file. Always truncates the file. Reads bytes instead of text. filePath: string The absolute path to the file.