[CANGEN] - Add in-topic naming, further seperation of netfield and can point

[jr1221]

Current Features

Right now, we have an abstraction called append_topic. It will take the first X CanPoints and append them to the NetField topic. It is limited to the beginning of the message and looks ugly. Further, all of our messages are parsed in a strict order.

Desired Additional Features

I want this to be location agnostic, so instead of topic_append you can use some sort of parsing of the topic.

For example you could have topic: "BMS/Pack/PerCell/Cell-{1}/Temp
The {1} thing will be referring to message number 1 in the CanPoints list. That will be appended in that position of the topic.

This also brings up the issue of nesting it. Therefore I am proposing a new YAML format where there is a message, a list of can points, and then those points are referred to in a list of net fields.

So you can have a netfield with topic BMS/Pack/PerCell/Cell-{1}/Temp and item_id: 2, where message 1 is the cell ID and message 2 is the temperature for that cell. The IDs are in order of message appearance.

Internally this will assign all CanPoints temporary variables, then subsequently push them to various topics as needed.

New YAML

- !CANMsg
    id: "0x80"
    desc: "accumulator status"
    points:
        - !CANPoint
            size: 16
            format: "divide10"
        - !CANPoint
            size: 16
            parse: False
        - !CANPoint
            size: 16
        - !CANPoint
            size: 8
        - !CANPoint
            size: 8
   fields:
    - !NetField
        name: "BMS/Pack/Voltage"
        value: 1
        unit: "V" 
    - !NetField
        name: "BMS/Pack/Amp-hours"
        value: 3
        unit: "Ah"
    - !NetField
        name: "BMS/Pack/SOC"
       value: 4
        unit: "%"
    - !NetField
        name: "BMS/Pack/Health"
        value: 5
        unit: "%"

And an example of topics

- !CANMsg
    id: "0x80"
    desc: "accumulator status"
    points:
        - !CANPoint
            size: 16
            format: "divide10"
        - !CANPoint
            size: 8
        - !CANPoint
            size: 8
        - !CANPoint
            size: 8
        - !CANPoint
            size: 8
        - !CANPoint
            size: 16
            format: "divide10"
   fields:
    - !NetField
        name: "BMS/Pack/PerCell/Cell-{3}/Volts"
        value: 1
        unit: "V" 
    - !NetField
        name: "BMS/Pack/PerCell/Cell-{3}/Power"
        value: 2
        unit: "Ah"
    - !NetField
        name: "BMS/Pack/PerCell/Cell-{4}/Volts"
        value: 6
        unit: "V" 
    - !NetField
        name: "BMS/Pack/PerCell/Cell-{4}/Power"
        value: 5
        unit: "Ah"

As you can see, the whole order is scrambed around. Indexed by 1. It is annoying because changes could shift the whole thing but so much more powerful.

Complete list of changes:

CANPoint:
new: parse (bool, default true) (whether to parse the bits or use .skip on them (basically what send used to do, if false and the ID is referenced in the message, fail to compile)

NetField:
name --> topic
points --> X
send --> X
topic_append --> X
new: value (int) (the can point to make the payload of the NetField)

CANMsg:
new: points (list[CANPoint]) (the list of CANPoint objs in order of their decoding)

Screenshots (as needed)

No response

[jr1221]

Limitations removed:
No. 8 Unsent messages should only contain the size parameter

[harrison-e]

Proposed new CAN types:

pub struct CANMsg {
  pub id: String,
  pub desc: String,
  pub points: Vec<CANPoint>,
  pub fields: Vec<NetField>,
  pub key: Option<String>,
  pub is_ext: Option<bool>,
  pub sim_freq: Option<f32>,
}

pub struct NetField {
  pub name: String,
  pub value: usize,
  pub unit: String,
  pub sim: Option<Sim>,
}

pub struct CANPoint {
  pub size: usize,
  pub parse: bool, 
  pub signed: Option<bool>,
  pub endianness: Option<String>,
  pub format: Option<String>,
  pub default_value: Option<f32>,
}

...

Bit reader changes for a future PR, will probably include pub read_type: Option<String> in CANPoint

[jr1221]

Do you wanna sim Netfields or sim points? I'm feeling points would be better but may be harder.

[harrison-e]

I'm down to sim points over fields, just not entirely sure what effects that would have