Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: sensor abstraction & hardware setup file #271

Draft
wants to merge 25 commits into
base: main
Choose a base branch
from

Conversation

ROMemories
Copy link
Collaborator

@ROMemories ROMemories commented Apr 23, 2024

Draft PR of the current state of the sensor abstraction layer and hardware setup file. It will definitely be split up when time comes.

Current implementation:

  • the await_read_sensor_main! function-like proc-macro reads the list of sensor concrete types from hw-setup.yml
  • the _await_read_sensor_main! declarative macro downcasts the sensor trait object to a concrete type, reads the "main" sensor value and awaits it (required because different opaque types otherwise)
  • riot_rs::hw_setup attribute macro populate the sensors application modules with sensor driver instantiation and initialization (to be completed)
  • handles a homogeneous interface when iterating over sensors, and a specific interface when accessing a sensor directly by its global name

Major pieces which are currently missing:

  • Sensor categories: we should have sub-traits of the Sensor trait for each sensor categories (e.g., temperature sensors, accelerometers, …) so that it is easy to replace a sensor with another one from the same category
  • Consistence sensor initialization, generated from the hardware setup file
  • Sensor configuration (refresh rate, mode selection, I2C address, …) from the hardware setup file

Points of interests:

  • The Sensor trait has two "read" methods:
    • a Sensor::read_main() (which needs a better name), which provides a consistent interface across all categories of sensors (and thus only returns the "main" value returned by the sensor) and should return an enum to allow for multi-dimensional tuples, and
    • a Sensor::read() method, which returns a type implementing Reading, allowing each sensor to return a custom type (this should change when introducing sensor categories).

@ROMemories ROMemories added sensor Specific sensor support board Board support sensor abstraction The sensor abstraction labels Apr 23, 2024
@kaspar030 kaspar030 mentioned this pull request Jun 26, 2024
57 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
board Board support sensor abstraction The sensor abstraction sensor Specific sensor support
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant