config on SD card - read/save, change meter resolution, add stats in lux_only mode

[danielskowronski]

Draft for now, I want to add I2C address change since it'll be around the same place as meter resolution setting.

---

Config on SD card

It lives in /ext/lightmeter/config.txt and as of now looks like this:

Size: 123
Filetype: lightmeter
Version: 1
iso: 08
nd: 00
aperture: 03
dome: 00
backlight: 00
measurement_resolution: 01
lux_only: 01

I'll be checking that weird issue with flipper_format_write_int32 vs flipper_format_write_hex causing stack overflow. It may be something in my local setup - I'm using SDK for 0.76.0 and firmware hacked from unlshd-026 which now I realized is old...

Sensor resolution

For now, it does not provide ton of benefits as we're anyway polling meter in UI threads. Maybe it'll get useful in the future.

Stats in Lux meter mode

• resettable peak value
• simple histogram with some hackish attempts at squeezing entire spectrum in 20px with emphasis on 1k-10k lux range

[oleksiikutuzov]

Hey, thanks a lot for your effort! Looking good, except for a few minor things to fix

[oleksiikutuzov]

Or maybe it would be even better to wait for this getter for the app data path flipperdevices/flipperzero-firmware#2181 to be merged

[danielskowronski]

@oleksiikutuzov do you know if there's any reason why app on Flipper seem to prefer using built-in flipper_format_* even for settings instead of some structured doc format like JSON? It causes variety of issues like Hong5489/ir_remote#3, especially when those config files are treated as input for use who may put lines in incorrect order.
I'd love to try some lightweight implementation of JSON parser which would let me just unmarshal stream to C struct, but maybe there's some reason why it would be problematic.

[danielskowronski]

Weird, despite being on unleashed-030 and building against freshly downloaded SDK (ufbt update --channel=dev, it's newer than 0.77.1) it still dislikes config file produced by flipper_format_write_int32 when reading using flipper_format_read_int32 (of course having changed fields of LightMeterConfig struct from uint8_t to int32_t).

Example of file that once written by app crashes Flipper with stack overflow on first attempt to read it:

>: storage read /ext/apps_data/lightmeter/config.txt
Size: 116
Filetype: lightmeter
Version: 1
iso: 4
nd: 0
aperture: 3
dome: 0
backlight: 0
measurement_resolution: 1
lux_only: 1


>:

And working one for _hex/uint8_t variant:

>: storage read /ext/apps_data/lightmeter/config.txt
Size: 123
Filetype: lightmeter
Version: 1
iso: 04
nd: 00
aperture: 03
dome: 00
backlight: 00
measurement_resolution: 01
lux_only: 01


>:

[danielskowronski]

Mysterious crash solved.

was caused by stack_size being too small to handle int32 😄

[oleksiikutuzov]

@oleksiikutuzov do you know if there's any reason why app on Flipper seem to prefer using built-in flipper_format_* even for settings instead of some structured doc format like JSON?

I guess it's just not to use external libraries which would make the app more complex and heavier. In this case I would also say the standard implementation would be enough as this is not a user-definable config

[danielskowronski]

I guess it's just not to use external libraries which would make the app more complex and heavier. In this case I would also say the standard implementation would be enough as this is not a user-definable config

Makes sense :)

I pushed some fixes. So if everything else looks OK, then we wait for oleksiikutuzov/flipperzero-BH1750#1 + flipperdevices/flipperzero-firmware#2181, and finally, I will be able to get them backported and finish this PR.

[oleksiikutuzov]

I pushed some fixes. So if everything else looks OK, then we wait for oleksiikutuzov/flipperzero-BH1750#1 + flipperdevices/flipperzero-firmware#2181, and finally, I will be able to get them backported and finish this PR.

I'll be back to my laptop in couple of days or by the end of the week, so I approved the fix now. It seems fine, so you can continue as the other one will be merged.

[oleksiikutuzov]

I also got an answer from @DrZlo13 in Tg chat regarding your question to config files, will share the auto translated text here. He also meant that even 2 KB of stack is quite optimistic and can easily be increased to at least 4 KB 😁

In order:

1. We needed a human-readable and human-editable format. There are some exceptions in applications that build "arrays" in our format (animations, the irda application), but everything else can be easily edited, rearrange lines, add spaces, and that's it.
2. We needed a format with comments.
3. We needed a format that was easy enough to write and maintain.
4. We needed a format that does not load the entire file into memory, and can work within a very limited framework, just hundreds of bytes of RAM.

If we take the same cJSON for comparison:

1. I would not call json human-readable and easily human-editable.
2. json does not support comments (there are hacks with special keys, but see below).
3. The cJSON codebase is 3-5 times larger.
4. I have not yet seen a format that, in an embedded framework, can replace data by key in the middle of a file of any size, even in megabytes.

I would not say that cJSON digests all the quirks that are present in the json format, it is extremely difficult to write a correct json parser, see for example https://habr.com/ru/company/vk/blog/314014/.

Comments: https://habr.com/ru/post/247473/. As you can see, without expanding the parser, everything is based on writing a comment to the key, which, firstly, will be loaded into RAM, and secondly, when saved, it will be sorted xs where, and may well be far from the field that comments.

[DrZlo13]

@oleksiikutuzov merged :).