flipperzero-firmware

flipperzero-firmware copied to clipboard

Description of the feature you're suggesting.

Creating this as a feature request even though I'm at work implementing it, just to ensure it's being tracked that someone is working on this in case there's demand or parallel effort from others. Functionality will be something like a cross between the existing GPIO menu and the Infrared menu when complete, allowing on-device loading (not saving) of .i2c file configurations from the SDCard (to avoid unwieldy libraries), organized by type.

Please let me know if anyone else is working on this as I think collaboration rather than conflict is in everybody's best interests.

I'll be starting with Sensor implementation as these tend to follow somewhat regular patterns. Still settling on final details but configuration files will contain at least the following:

• description
• i2c_type [eg: Sensor; possibly things like Receiver or Transmitter in future as well]
• category [yet-undetermined grouping id for future menu sorting if we get a lot of sensors]
• default_address
• alternate_addresses [to try if default fails]
• configurable [true/false]
• config_8bit_registers
• config_16bit_registers
• endian [big / little]
• init_sequence (sequence to write for initialization. Still working on the format)
• stop_sequence (as above with init_sequence, if needed)
• stateful [true/false]
• state_load_sequence
• start_sequence
• read_value (first/single value retrieval byte sequence)
• read_value_type (C type of the result, eg: float, uint8_t, etc.)
• read_value_# (optional, for sensors with multiple metrics available using different calls)
• read_value_#type (required for each read_value# defined)

There's probably more that will be needed. The goal is to have configurations live in SDCard space, loaded only when needed rather than pre-baked into headers as is most common. To make this work, there needs to be a lot of info in these config files to be able to steer the generic handlers in the right direction.

I hope to have a proof of concept up within the next week or two.

Anything else?

No response

The data may need some kind of hierarchy. I'm contemplating whether it's a good idea or not to load up <json.h> from the existing flipperzero-firmware codebase (I believe it's defined in a submodule but not used) rather than define yet another standard for storing/loading configuration data. The alternative would probably be improvising something akin to YAML.

There were project that implemented I2C/SPI flash reading writing which also was using similar ideas(describing geometry with configs).

Overall we use FFF, protobuf and binary formats in firmware, nor JSON nor YAML is not shipped with firmware and not going to be included in sdk. So you'll have to include them into your application.

@skotopes thanks for the clarity! I'll look into the formats being used and try to keep it similar.