On Sat, Jul 07, 2018 at 06:13:22PM +0200, Kevin Townsend wrote: > In the sys/config package, there are two main flags to test against in > code, depending on your implementation: > > * CONFIG_FCB (storage in FCB) > * CONFIG_NFFS (storage in NFFS) > > https://github.com/apache/mynewt-core/blob/master/sys/config/syscfg.yml > > I'd like to add config key-pairs as an option to a sensor driver (the > TSL2591 I submitted a PR for), to reload the integration time and other > settings on startup, and persist changes when made, but am I correct > that there isn't a single higher level 'CONFIG' flag and I'll need to > test against both of the values above to determine if the config system > is present or not? It seems not, but maybe I'm missing something. > > Would anyone else consider it 'cleaner' to add a single flag that is > defined in either case (more if another persistance layer is added in > the future), since the API itself makes FCB or NFFS (or ???) mostly > transparent?
I think "package-present" settings are often not as useful as they might seem. Most of the time, code doesn't care whether a package is present in the build; it only cares whether it has access to the package. That is, what matters is whether it has a dependency on the package, directly or indirectly. For example, the `sys/reboot` package depends on `sys/config`. Since pretty much every build includes the `sys/reboot` package, `sys/config` will be present, and all its settings will be defined and available to the rest of the system. However, a driver package won't have access to the `sys/config` header files unless it also depends on the package. I think cases like the one you described are usually solved by adding a new setting to the driver package (e.g., `TSL2591_CONFIG`). If that setting is enabled, the driver package depends on `sys/config`, e.g., pkg.deps.TSL2591_CONFIG: - '@apache-mynewt-core/sys/config' > Kevin > > PS: As a side note, persisting the NFFS partition to an external file > under ARCH_sim would make certain test cases easier., storing values > across reets and builds. If this seems useful to anyone, I can raise it > as a Github issue and look at putting a PR together? I don't know if this helps in your particular case, but you can specify "-f <path>" to use a local file for internal flash (assuming the app calls `mcu_sim_parse_args()` in main). If you specify the name of an existing file, the simulator will reuse its contents. Chris