-
Notifications
You must be signed in to change notification settings - Fork 655
Add APP_TEXT object type to BLFReader #1942
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
base: main
Are you sure you want to change the base?
Conversation
|
Thanks for pointing that out @zariiii9003 and I wasn't aware of the vblf project. Does it make sense to have this functionality in BLFReader? It seems like the API here is focused on just returning objects that appeared on the bus in the iterator, and abstracting away the fact that there are other object types in the BLF. It seems a little awkward to have a side channel in self.app_text that is only populated as a side-effect of iterating for messages. |
|
|
||
| # APP_TEXT objects are appended when type 65 is encountered | ||
| # while iterating | ||
| self.app_text: List[Tuple] = [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of a tuple, i'd prefer an AppText or BlfAppText dataclass with timestamp, source and text attributes.
| silently ignored. APP_TEXT objects are parsed into `self.app_text` when | ||
| they are encountered while iterating. | ||
| self.app_text is a list of tuples containing the parsed app_text objects. The |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Take a look at the sphinx documention on how to properly document instance attributes.
BLF files have metadata objects that encode useful information such as CAN channel mapping configuration. This PR provides the minimal additions to the BLFReader class to support extracting that data along with the parsing of the message objects. Parsing the data structures used in the metadata objects is outside the scope of this PR. However this still provides a significant benefit to applications that are can perform context specific interpretation of the metadata without having to duplicate the BLF parsing performed by BLFReader.