The device config and the complete object dictionary are separate concepts and they should be separated. The device config is an input file for configuring, and the object dictionary is elaborated from this. I'm proposing to split much of the code defining the objects currently in device config into an ObjectSpec, which will map pretty directly onto an EDS file -- i.e. it will describe the shape of each object and sub-object, including custom application specific objects and system generated objects (like PDO configuration, device info, etc).
Additionally, there is a further layer of configuration required for generating code for the node, and I'm calling this ObjectBuildSpec. If specifies how the object dictionary is implemented -- e.g. which objects / sub-objects are implemented as "storage" and which are "callback", or which objects are implemented by zencan provided "system" objects (like bootloader objects). This should make the code generation a clearer (i.e. remove the special object ID cases) and more flexible. An ObjectBuilderSpec is a wrapper on ObjectSpec which adds information, and can be converted easily to an ObjectSpec. It's a separate type in order to support reading EDS files, for example, which don't contain any information about the implementation.
The device config and the complete object dictionary are separate concepts and they should be separated. The device config is an input file for configuring, and the object dictionary is elaborated from this. I'm proposing to split much of the code defining the objects currently in device config into an
ObjectSpec, which will map pretty directly onto an EDS file -- i.e. it will describe the shape of each object and sub-object, including custom application specific objects and system generated objects (like PDO configuration, device info, etc).Additionally, there is a further layer of configuration required for generating code for the node, and I'm calling this
ObjectBuildSpec. If specifies how the object dictionary is implemented -- e.g. which objects / sub-objects are implemented as "storage" and which are "callback", or which objects are implemented by zencan provided "system" objects (like bootloader objects). This should make the code generation a clearer (i.e. remove the special object ID cases) and more flexible. AnObjectBuilderSpecis a wrapper onObjectSpecwhich adds information, and can be converted easily to anObjectSpec. It's a separate type in order to support reading EDS files, for example, which don't contain any information about the implementation.