Re: Common CONFIG_* flag missing?
Sorry, I can see the flash writes here starting at 32KB testing against the default file (/tmp/native_flash.XX) as well as a hard-coded path (-f simflash.bin). $ xxd -s 0x8000 -l 128 simflash.bin 0008000: e231 8ab9 8c42 b07f 5382 e0ac 8efc 85b1 .1...B..S... 0008010: 0040 0100 00ff .@.. 0008020: 0008030: 0008040: 0008050: 0008060: 0008070: ... where the NFFS magic number is clearly visible (https://github.com/apache/mynewt-core/blob/master/fs/nffs/src/nffs_priv.h#L48) K.
Re: Common CONFIG_* flag missing?
Hi Chris, I don't know if this helps in your particular case, but you can specify "-f " 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. It doesn't look like anything is being persisted to the bin file. When I run the .elf with the following parameters: $ [path]/blinky.elf -f simflash.bin And then connect with minicom to verify that some files are present on the NFFS partition, I see the following (expected) results: ls /cfg 002382 5 /cfg/id.txt 002382 26 /cfg/run 002383 2 files 002385 compat> cat /cfg/id.txt 5678 003002 compat> cat /cfg/run split/status=0 id/serial= Everything looks fine, but if I then exit and dump the .bin file with xxd, the entire file is empty: $ xxd simflash.bin 000: 010: 020: 030: 040: 050: 060: 070: 080: 090: 0a0: 0b0: 0c0: 0d0: 0e0: 0f0: ... identical to the end of the flash memory. I'll try to track down the NFFS code to see if it is written to take the simulator into account or not. Thanks for the heads up on the flags, though! Kevin
Re: Common CONFIG_* flag missing?
Hi Chris, 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' That seems like a sensible choice, and allows control over config settings at a package level. Thanks. I don't know if this helps in your particular case, but you can specify > "-f " 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. Wasn’t aware of this param but makes testing config persistance and file IO across resets easier. Thanks for pointing the additional flag out. I’m going to try to put together a simulation of the TSL2591 just as a proof of concept to emulate a device where you can’t easily generate repeatable external conditions. There is an accelerometer option for the sim in tee sensor code but I think it’s useful to have an example that compares against a real device. K.
Re: Common CONFIG_* flag missing?
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 " 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
