Add APP_TEXT object type to BLFReader#1942
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. |
jonmon6691
changed the title
|
|
||
| # APP_TEXT objects are appended when type 65 is encountered | ||
| # while iterating | ||
| self.app_text: List[Tuple] = [] |
There was a problem hiding this comment.
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.
Take a look at the sphinx documention on how to properly document instance attributes.
|
Closing this PR since I think it makes more sense for users of python-can to consider vblf for the purpose of more protocol-specific usecases |
2 participants
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.