riot-appstore / memory_map_manager Goto Github PK

• Modbus based map (with some common tool outputs)
• svd file format output?
• EtherCAT ESI

if I have something.unique I can just access it with unique -> more of an interface thing I suppose.

• Support enums
• Incorporate access levels more than numbers
• use config file for generation parameters
• Defaults generated at runtime

Add parameters such as default values, invalid values, and addresses to the python interface to help with writing tests. It would be good to know what parameters and how they should be accessed. @smlng may want to comment.

This allows adding users without overwriting the parent setting.

For example if I have a user that can access everything and I want to add a parameter for both that user and another new one I have to include both, I cannot just add one.

The offsets are there but may be hard to understand why without further information...

The enums should at least be included, especially for the legacy output.

Generate python classes for the parameters using typedict or dataclass so there is documentation and autocomplete when coding with python.

support generation of data for RIOT-OS/riot_pal#3

Instead of having saved_setups and outputs have everything in one folder to make a simpler way. This will be similar to how @jia200x and @leandrolanzieri does the configuration generator.

It requires an app_access file which is a bit of a pain.

It should also include stdint.h since it is used.

Sort with name, offset, size, description first to make it more readable.

Improve documentation to better describe how to use the MMM and what is can be used for.

• Separate functions that can be called but also a verify map function.
• Flag to make it a ceiling or floor vs error return (and possibly not update value)

It seems that when there are two fields in the element section that have the same name it just overwrites...

typedefs:
  sys_t:
    description: System settings for PHiLIP
    elements:
     - access: read-only
        description: The philip device designator - A constant number to identify philip firmware
        name: device_num
        type: uint32_t
        default: 17061
        description: The frequency of the system clock in Hz
        access: read-only
        name: sys_clk
        type: uint32_t

name just overwrites... No error or anything.

This can help with backwards compatibility.

• Can be used in the nested context as an additional name.
• Can also be used in override to simplify a common long name.

A number of things that may not be related to the generator or output but would be good to have in the schema so that application interfaces may be able to use them.

• cache_time -> time that the value with be retrieved from system memory rather than from the device
• volatile -> Changes without input, use for auto-tests and possibly for hashes of configs for ignoring commit changes
• non_volatile -> Paired with submap, basically something indicating values persist through reset
• validate_regex -> If a string is being written, this applies validates it. Can also be applied after reads for tests.
• immediate_apply -> Record does not need commit for it to work.
• sub_maps -> Flag record across typedefs or bitfields for a sub_map typedef that auto-copies info back and forth.
• alias -> Allow different names for record lookups
• display_name -> More human readable name that may be used for GUIs or end user facing strings.

It appears that in the memory map csv the bit_offset field generate the offset + 1.

I wanted to mention https://commschamp.github.io/ along with many other solutions out there...

There should be a way to add deprecation warnings on a parameters.

It turns out if using an array of a special type:

gpio_t gpio[10];


...
void init_defaults() {
gpio.0 = DEFAULT_GPIO_0_....
}

• comparing hash from previous version
• have some pointer to latest

• This would add a number of parameters across many types to it's own map.
• Use case: non-volatile storing of data -> create a map for all the non-volatile records in the generated map
• Auto get/set of sub map to map
• Also use case for device parameters, if only some need to be changed at commit.

figure out what CI to add...

It would be nice to request the map information from the firmware directly. If there is some sort of way to iterate over the structure, maybe also output the variable names that would be cool.

For example I have a timestamp_t where access can be 1 but I don't want access for the build time. Should the higher level dictate the access rights or should it be given to the lowest level? Should there be a default or empty level that basically allows overwriting?

It might be nice to have this pregenerated in... Some make/cmake/scons thing.

At least for the access levels.

If we enforce the hash to be available at the start of every map than we do not have to depend on a special way of checking the hash (was get version) which mean interfaces such as modbus would not have to rely on that and would be able to just read the known offset,

A web interface would be good to edit and view the structures (json). This could provide verification and remove some need for documentation.