Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jr1221 opened this issue Sep 8, 2024 · 1 comment
Assignees

Comments

@jr1221
Copy link
Contributor

jr1221 commented Sep 8, 2024

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
Copy link
Contributor Author

jr1221 commented Sep 8, 2024

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

@jr1221 jr1221 transferred this issue from Northeastern-Electric-Racing/Embedded-Base Nov 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants