JSON descriptor for config section

[seank]

Hi,

The new config section is about done and it would be nice to have a decent interface for it. For starters, can you tell me what you would like to see for each struct in the master config struct? I'll start by telling you what exists now:

/* Master config */
typedef struct MasterConfig {

    MechanicalProperties    mechanicalProperties;
    TachDecoderSettings     tachDecoderSettings;
    CylinderConfig          CylinderSetup[MAX_CYLINDER_COUNT];
    CylinderAngleConfig     CylindersAngles[MAX_CYLINDER_COUNT];
    FuelingProperties       fuelingProperties;
    SensorProperties        sensorProperties;
    OperatingLimits         operatingLimits[NUM_OPERATING_LEVELS];
    GPIOchannel             GPIOchannels[NUM_GPIO_CHANNELS];
    XGateOutputCHpinMapping xGateOutputCHpinMapping[XGATE_CHANNEL_COUNT];
    ComSettings             comSettings;
    uint8_t                 configMessage[25];
}MasterConfig;

/* CylinderConfig details */
typedef struct {
   SyncedData *syncedEngineData;     /* done by firmware config */
   outputEvent *igntionEvent;             /* done by firmware config */
   outputEvent *primaryFuelEvent;      /* done by firmware config */
   outputEvent *secondaryFuelEvent;  /* done by firmware config */
   uint16_t TDCAngle;                        /* Specified by user */
   uint16_t ReadAngle;                       /* Specified by user */
   uint16_t InjectionAngle;                 /* Specified by user */
}CylinderConfig;

Given the two nested structs above, if you wanted to change your injection angle, you would want to modify the CylinderConfig member variable "InjectionAngle". I suppose at a minimum I need to provide you with:
 1. A DATA_ID so you can push and pull the CylinderConfig over the serial port.
 2. A size of the data in total, we could just include the three 16-bit variables in the payload, so there is no chance of corrupting anything else.
 3. A data-offset for each member
 4. A description for each member
 5. A scaler, much like what is provided in the data-log descriptor

The other side of things, is how to generate this data, but I think we should worry about that after the first part of it is done.

-Sean

[malcom2073]

1. A DATA_ID for each component of MasterConfig would be useful
2. You need total size, otherwise array objects would not work properly. If fields are read only, mark them as such. For instance, CylinderConfig would have a DATA_ID pointing to the first member of the CylinderSetup array. It would also have a size for the whole struct, so when calculating the second, third, etc cylinder, we know what offset to apply to the DATA_ID write request.
3. Data offset and member type (uint16_t, int8_t, etc). This offset should be from the start of the struct.
4. Description and name
5. Scalar and value offset would be the best bet for simplicity.

The data can be auto-generated by parsing the header file ala mavlink style as we discussed. I can play around with the parsing library I wrote for mavlink and see how difficult it would be to auto-generate things. We could use doxygen style comment parsing for description, read/read-write, and scalar/offset fields.

My main reasoning for having it auto-generate would be to reduce the possibility of human error when making an edit to the MasterConfig, then having to go make the proper edit to the JSON. This way, you would have the generator read the header, generate a "json_descriptor.h" or whatnot during the build process, then have that included to send to the tuner on request.

You may need to break MasterConfig out into its own header, to ensure that no other classes get parsed, unless you're sure everything inside Configuration.h should be included.