Refactor profiles and EEPROM handling - Githubissues

BrewPi / firmware

Brewing temperature control firmware for the BrewPi Spark (Particle Photon inside)

http://www.brewpi.com

GNU Affero General Public License v3.0

97 stars 55 forks source link

Refactor profiles and EEPROM handling #91

Closed elcojacobs closed 6 years ago

elcojacobs commented 6 years ago

Current implementation has downsides:

Objects belong to only one profile. If a sensor is used in multiple profiles, it is repeated.
Objects can only be added to last profile in EEPROM
Only one profile can be active at any time (doesn't match well with multiple processes)

New proposal:

Profiles do not contain objects, but objects have a flag (uint8 bitfield) for which profiles they are active. This defines 8 profiles.
A global bitfield defines which profiles are active.
Activating a profile constructs runtime objects from EEPROM definition
Deactivating a profile deletes runtime objects if they are not assigned to a still active profile

Advantages:

The object list is one global list. No segmentation of EEPROM in multiple sections. No notion of profiles open/closed for adding objects.
Existing objects can be assigned to one or more profiles
Profiles can be activated/deactivated at will