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

Proposal: Make OpenSprinkler-Firmware a non-hardware specific PlaformIO library #142

Open
timbodeit opened this issue Jun 24, 2020 · 3 comments

Comments

@timbodeit
Copy link

I have been looking a bit into refactoring the OpenSprinkler-Firmware codebase.

My primary goals behind the change are:

  • improve code structure
  • make one-off adjustments (such as Allow GPIO pins to be manually entered #96 (comment)) easier, without major changes to the code-base
  • improve reusability across hardware iterations (including portability to other architectures such as ESP32)
  • make the build process more reliable and reproducible

@rayshobby: The changes I am suggesting are fairly invasive to the code-base. I would appreciate, if you could give me a short feedback, whether this is something that you would like to see integrated into your code-base as a pull request or if you would prefer me keeping it in a separate fork.

To accomplish this, I would like to make the following changes:

1. Separate hardware-specific integration and general implementation

All business-logic code currently placed in main.cpp will move into OpenSprinkler.cpp or to a different class thereunder. The OpenSprinkler class will become the interface to the hardware integrator. Hardware specific details (Pins, IO Expanders used, etc) will be passed into an OpenSprinkler constructor.
There hardware specific assumptions such as "every ESP8266 based OpenSprinkler has 3 buttons and an OLED display" are removed. The corresponding logic will instead be reflected by the usage of the Class in main.cpp.

2. Encapsulate code into smaller components

Example: Encapsulate all UI code (LCD / Buttons) into its own class. This allows providing additional implementations (such as integrating a new touch screen based UI) that can be used alternatively under a common interface.

3. Remove global state

static variables are moved into the object. UserInterface, Server code, etc are abstracted into a class.

4. Change the build system from "Arduino IDE + make" to a platformIO based approach

A big part of making builds reproducible is to have consistent dependencies. PlatformIO takes care of installing the correct version of all dependencies automatically. It makes sure the same dependency versions are installed, when revisiting a commit at a later point in time (such as during a git bisect).
Having a one-step build makes continuous integration easier to establish. Exposing the OpenSprinkler class as a library facilitates custom integrations that stay up to date with the OpenSprinkler codebase.

@emaste
Copy link

emaste commented Jul 24, 2020

It seems to me that 1+2+3 and 4 can be addressed somewhat independently. I'm looking at running OSPi on FreeBSD and in that context am indifferent to the platformIO change. I am interested in changes 1 through 3 though.

@manoj153
Copy link

Is this suggestion code work started?

@maxgerhardt
Copy link
Contributor

maxgerhardt commented Feb 6, 2021

In PR #165 I've created the necessary platformio.ini to build the firmware build for ESP8266 (OS 3) and ATMega1284P (OS 2.2). So, not a PlatformIO library with a library.json or whatever (that would need code changes), but it's a PlatformIO-compilable project now (after PR merge).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants