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

Hardware device abstraction #346

Open
zehnm opened this issue Dec 8, 2019 · 4 comments
Open

Hardware device abstraction #346

zehnm opened this issue Dec 8, 2019 · 4 comments
Assignees
Labels
Milestone

Comments

@zehnm
Copy link
Member

@zehnm zehnm commented Dec 8, 2019

Expected Behavior or Design

As a software architect I expect a hardware abstraction layer for many reasons. To name a few:

  • Enables and simplifies testing
  • New hardware is easily integrated
  • Devices can be mocked
  • Enables support for new platforms or allows to adapt the YIO Remote software to easily run on a regular Raspberry Pi.

Current Behavior or Design

Hardware interaction code is currently implemented in dedicated classes, e.g. one for the proximity sensor, haptic motor, display etc.
However, the classes are always instantiated and all device interaction code is wrapped in many #ifdef __arm__ ... #endif blocks.

Possible Solution

  1. Create abstract device interfaces.
  2. Move existing code to a subclass of the interface
  3. Create mock implementations for non-RPi runtime
  4. Create a device factory to instantiate and configure the implementations based on runtime and configuration parameters

Detailed Description and Additional Information

Affected code in remote-software/sources/hardware:

  • apds9960.h / .cpp
  • bq27441.h / .cpp
  • display_control.h / .cpp
  • drv2605.h / .cpp
  • interrupt_handler.h
  • proximity_gesture_control.h
@zehnm zehnm added the enhancement label Dec 8, 2019
@zehnm zehnm added this to the Release 0.3 milestone Dec 8, 2019
@zehnm zehnm self-assigned this Dec 8, 2019
@zehnm zehnm added this to Backlog in YIO Remote software via automation Dec 8, 2019
@zehnm zehnm moved this from Backlog to Accepted in YIO Remote software Dec 8, 2019
@ChristianRiedl

This comment has been minimized.

Copy link
Member

@ChristianRiedl ChristianRiedl commented Dec 8, 2019

Good idea ! Optimum would be to have it in a seperate lib. A YIO-Hardware SDK.
Maybe without Qt, it is not required on this layer.
I think YIO remote could be interesting for PI fans making their own software.

@zehnm

This comment has been minimized.

Copy link
Member Author

@zehnm zehnm commented Dec 8, 2019

Well there are a few Qt signals which I see required or at least convenient to have. So that would lead to low-level C / C++ device interaction code and probably a higher level Qt integration providing the signals for the other components.
Most important step now is to start refactoring the code. I already started with the design in the wifi rewrite branch and I'm going to start with this task next week.
Once that's done we can discuss further improvements.

@zehnm zehnm moved this from Accepted to Design in YIO Remote software Dec 8, 2019
@zehnm zehnm moved this from Design to Implementation in YIO Remote software Dec 17, 2019
@ChristianRiedl

This comment has been minimized.

Copy link
Member

@ChristianRiedl ChristianRiedl commented Dec 20, 2019

A lot of files, isn't it a bit over engineered ? But maybe I'm a little old fashioned.

@zehnm

This comment has been minimized.

Copy link
Member Author

@zehnm zehnm commented Dec 23, 2019

The wifi code has been rewritten and merged into the develop branch. It will serve as the foundation for refactoring the hardware specific classes with factories and platform specific includes.

In my opinion this is not over engineered but clearly separated code following well established software design patterns. Probably not yet C/C++ perfect since I'm still having some language issues coming from Java. But I'm confident that it provides us the much needed flexibility and an easy start for new developers or platforms we'd like to support.

I'm starting a feature branch now for refactoring the affected code.

zehnm added a commit that referenced this issue Dec 29, 2019
Initial refactoring of the following device drivers:
- DisplayControl
- InterruptHandler
- Battery
zehnm added a commit that referenced this issue Dec 30, 2019
- Setting QQmlEngine::CppOwnership for hw device singletons
- using `#pragma once` instead of ifndef header guards
- added license template for Qt Creator

Part of #346
zehnm added a commit that referenced this issue Dec 30, 2019
- Split ProximityGestureControl into separate device classes

Part of #346
zehnm added a commit that referenced this issue Dec 31, 2019
Part of #346
zehnm added a commit that referenced this issue Jan 1, 2020
Part of #346
zehnm added a commit that referenced this issue Jan 2, 2020
zehnm added a commit that referenced this issue Jan 2, 2020
zehnm added a commit that referenced this issue Jan 2, 2020
zehnm added a commit that referenced this issue Jan 2, 2020
Calling virtual methods in a base constructor doesn't call the
overriden child methods!

Part of #346
zehnm added a commit that referenced this issue Jan 2, 2020
Part of #346
zehnm added a commit that referenced this issue Jan 3, 2020
- common initialization logic
- simplified handling in hardware factory
- prepared i2c device configuration

Part of #346
zehnm added a commit that referenced this issue Jan 3, 2020
After standby some QML functions call it with values > 100.
This crashes the pwm funtion and brightness / display standby
don't work anymore.

Part of #346
zehnm added a commit that referenced this issue Jan 5, 2020
- New signals: ready(), error(DeviceError, message)
- Device name for logging messages
- Assert macro for checking if device is open
- Logging categry for proper category when logging in base classes

Part of #346
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
YIO Remote software
  
Implementation
2 participants
You can’t perform that action at this time.