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: architecture & function responsibility #293

Closed
BlakeFreer opened this issue Nov 5, 2024 · 0 comments · Fixed by #315
Closed

cangen: architecture & function responsibility #293

BlakeFreer opened this issue Nov 5, 2024 · 0 comments · Fixed by #315
Assignees

Comments

@BlakeFreer
Copy link
Contributor

BlakeFreer commented Nov 5, 2024

Some things I don't like about the current architecture:

  • the if sig.byte_order block in _get_masks_shifts() is pretty repetitive. We're really just mapping a byte order string to a function. This can be more direct with a dictionary with string keys and function values. the current code is more obvious, don't change this
    • cantools also guarantees that the byteorder is valid so we don't need an explicit check
  • we create the Jinja environment multiple times (twice per bus). This should be abstracted out and only run once. Maybe it gets made in generate_can_from_dbc and passed into generate_code? Would be nice to have a function that creates and returns the environment with all filters set
  • after the last bullet, is there still value in the generate_from_jinja_template function? Should it be inlined into generate_code? It's a bit of a strange function given how many parameters it requires and how little it does. Maybe the two calls to this function could be replaced by a loop over (CAN_MESSAGES_TEMPLATE_FILENAME, MSG_REGISTRY_TEMPLATE_FILENAME)or something simila
  • i'm not a huge fan of variables/ return types that look like Dict[str, Dict[str, Tuple[List[int], List[int]]]]: This is really hard to understand. We should at least use dataclasses to bundle some of this information into a named type.
  • Log levels: since cangen can be used standalone, we shouldn't require the user to know cmake logging levels to use it. We should have two mutually exclusive arguments: a --verbose aka -v flag and --cmake-log-level=### option, the latter of which replaces the current --log-level. The parse() function should figure out which was passed and convert that to a python logging level. You can then set args.loglevel to this value and directly pass args.level to `logger.setLevel
    • this will require you to store and manipulate the value from parser.parse_args() before returning it
  • the current functions names aren't great. Renaming them may also help decide how to organize the behaviour
    • if you rename the cangen entry point, make sure to update pyproject.toml.
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

Successfully merging a pull request may close this issue.

2 participants