⬢ Sensor_Kit

Sensor_Kit is a hardware-independent sensor framework written in Ada for embedded systems.

It provides a consistent, strongly typed API for interacting with sensors while keeping sensor protocols and hardware-specific details separated from application logic.

The goal is to make sensor programming simple, portable, deterministic, and reliable without sacrificing control over the underlying hardware.

---

⬢ Vision

Build a modern embedded sensor framework where applications interact with sensors and meaningful measurements, rather than low-level hardware details.

Sensor drivers should not need to know:

• Which microcontroller is being used.
• How GPIO hardware is implemented.
• How communication peripherals are accessed.
• Which hardware registers are involved.
• How raw sensor data is converted into meaningful values.

The application should describe what sensor it wants and what hardware resources it provides. Sensor_Kit handles the rest.

---

⬢ Design Goals

• Hardware-independent sensor drivers.
• Strongly typed APIs using Ada.
• Consistent API across supported sensors.
• Static memory allocation.
• Deterministic behavior.
• No hidden background tasks.
• No unnecessary dynamic allocation.
• Clear separation between hardware access and sensor logic.
• Simple sensor configuration and creation APIs.
• Meaningful, sensor-specific measurement records.
• Portable architecture suitable for microcontrollers and embedded systems.

---

⬢ Design Philosophy

Sensor_Kit is built around a simple idea:

Applications ask for measurements. Sensor drivers handle the hardware interaction.

A sensor is configured once and created from its configuration:

DHT_Config : Sensor_Kit.DHT11.Configuration := (Data_Pin => DHT_Pin'Access);

Temperature : Sensor_Kit.DHT11.Sensor :=
   Sensor_Kit.DHT11.Create (DHT_Config);

Measurements are then obtained through the sensor:

Readings := Temperature.Read;

The application works with meaningful sensor data instead of implementing the sensor protocol itself.

For example:

Readings.Temperature
Readings.Humidity

The DHT11 driver is responsible for GPIO transitions, timing, protocol handling, checksum validation, and conversion of the raw response into the returned measurement.

---

⬢ Architecture

Sensor_Kit uses a layered architecture that separates sensor logic from hardware implementation:

Application
      │
      ▼
Sensor_Kit Sensor API
      │
      ▼
Sensor Driver
      │
      ├──── GPIO
      ├──── Wait
      └──── Future Hardware Interfaces
             │
             ▼
      Platform Implementation
             │
             ▼
          Hardware

The sensor driver only depends on the hardware capabilities it requires.

For example, a digital sensor may use:

Sensor Driver
      │
      ├── GPIO
      └── Wait

An I²C sensor may eventually use:

Sensor Driver
      │
      └── I²C

This allows the same sensor driver to be used across different microcontrollers without changing the sensor implementation.

---

⬢ Core Principles

Hardware Independence

Sensor_Kit does not depend on a specific microcontroller or hardware platform.

Hardware Abstraction

Sensor drivers communicate with hardware through small abstractions rather than accessing registers directly.

Explicit Resources

Hardware resources are provided to sensors through configuration.

Configuration := (Data_Pin => DHT_Pin'Access);

Sensor drivers do not create or own the underlying hardware resources.

Strong Typing

Sensor data is represented using strongly typed Ada records rather than loosely structured values.

Meaningful Measurements

Drivers convert raw sensor responses into useful measurements whenever appropriate.

Deterministic Behavior

Sensor operations should have predictable execution and resource behavior suitable for embedded systems.

No Hidden Concurrency

Sensor_Kit does not create background tasks or threads on behalf of the application.

Separation of Responsibilities

Sensor drivers handle:

• Sensor communication.
• Sensor-specific timing.
• Protocol decoding.
• Validation.
• Conversion into measurements.

Applications handle:

• Hardware/platform initialization.
• Sensor configuration.
• Application logic.
• Filtering.
• Sensor fusion.
• Data presentation.

---

⬢ Sensor API

Sensor_Kit follows a consistent lifecycle:

Configuration
      │
      ▼
    Create
      │
      ▼
    Sensor
      │
      ▼
     Read
      │
      ▼
   Readings

A typical sensor follows this pattern:

Config : Sensor_Kit.DHT11.Configuration := (Data_Pin => DHT_Pin'Access);

Temperature : Sensor_Kit.DHT11.Sensor :=
   Sensor_Kit.DHT11.Create (Config);

Readings := Temperature.Read;

Each sensor defines its own configuration and measurement record while following the same overall API model.

For example:

Readings.Temperature
Readings.Humidity

The returned record can contain multiple related measurements from a single sensor read.

---

⬢ Hardware Interfaces

Sensor_Kit currently provides only the hardware abstractions required by its implemented sensors.

Current interfaces include:

• GPIO
• Wait

Planned interfaces will be introduced as sensors require them:

• I²C
• SPI
• UART
• ADC
• Timing

Interfaces are intentionally kept small so that platform implementations remain simple and portable.

A future shared hardware-interface project may be extracted when the broader embedded ecosystem matures.

---

⬢ Sensor Organization

Each sensor is maintained as an independent package.

Sensor_Kit
│
├── DHT11
├── HC_SR04
├── MPU6050
├── BMP280
└── ...

The public package follows the sensor name:

Sensor_Kit.DHT11
Sensor_Kit.HC_SR04
Sensor_Kit.MPU6050

Each sensor can internally contain whatever protocol-specific implementation it requires.

Communication protocols are therefore treated as an implementation detail of the sensor rather than the primary way of organizing the library.

---

⬢ Non-Goals

Sensor_Kit is intentionally focused on sensor acquisition and representation.

It does not aim to provide:

• Sensor fusion.
• General-purpose signal processing.
• Application-level data storage.
• Graphing or visualization.
• Networking.
• Cloud connectivity.
• Device management.
• RTOS abstractions.
• Microcontroller-specific peripheral drivers.

These concerns can be handled by other layers or libraries.

---

⬢ Current Status

Version 0.1.0

Sensor_Kit is currently in the early architecture and implementation phase.

Foundation

• Project structure
• Sensor package structure
• GPIO abstraction
• Wait abstraction
• Sensor configuration model
• Sensor creation API
• Sensor reading API
• DHT11 package skeleton

DHT11

• GPIO protocol implementation
• Timing implementation
• 40-bit data decoding
• Checksum validation
• Temperature and humidity readings
• Hardware validation

Future Interfaces

• I²C
• SPI
• UART
• ADC
• Extended timing support

Future Sensors

Additional sensors will be introduced after the core architecture has been validated with the initial implementation.

---

⬢ License

Licensed under the Apache License 2.0.