Introduce table coding system for program memory savings #70
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If the message structure is compatible, the DSDL compiler generates a table which describes its structure. If enabled, an interpreter is then used to follow the table description and encode or decode the message. This occupies substantially fewer bytes per message as the table is much smaller than the C function previously used. This translates to a large reduction in program memory usage, especially if many different message types need to be coded. This commit sets up all the hooks to enable and disable the system and defines the interpreter functions. However, they don't do anything as the system currently doesn't support any types.
Each table has a four byte header, plus some number of entries (4 bytes). Each field consumes one entry. The maximum encoded message length in bytes, size of the C message struct in chars, and number of table entries all are limited to 65535 for table coding to be possible. Also supports nested compound types containing these fields.
Static arrays have a 2-entry header (8 bytes), plus the entries describing the contents of the array. Array contents cannot consist of more than 256 entries (including header entries and entries describing nested types). The array length cannot exceed 65535.
Dynamic arrays have a 3-entry header (12 bytes), plus the entries describing the contents of the array. Array contents cannot consist of more than 256 entries (including header entries and entries describing nested types). The maximum array length cannot exceed 65535.
Unions have a 2-entry header (8 bytes), plus 1 entry for each field, plus the entries describing each field. The maximum number of fields is 255. Each field cannot consist of more than 255 entries (including header entries and entries describing nested types). This completes the list of DSDL types.
tpwrules
force-pushed
the
pr/table-coding
branch
from
ab5b3f6 to
dd2aca9
Compare
|
Removed fallthroughs that clang was whining about. Tested and GCC can optimize them anyway. |
|
Still have some minor cleanups and polishing to do but I figure that will come after the first round of reviews. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If the message is compatible, the DSDL compiler generates a table which describes its structure. If enabled in libcanard, an interpreter is then used to follow the table description and encode or decode the message. This occupies substantially fewer bytes per message as the table is much smaller than the C function previously used. This translates to a large reduction in program memory usage, especially if many different message types need to be coded.
The table can describe any structure of message supported by DSDL, however the quantities and sizes of specific aspects are limited by the datatypes chosen; see the code for details. Requires dronecan/dronecan_dsdlc#30 to actually generate the tables.
On top of Ardupilot master (a560f89b3), this system saves over 9K flash on Cube Orange, over 5K flash on Pixhawk1-1M, and 250-2000 bytes across MatekL431-based peripherals. DroneCAN-enabled bootloaders do not seem to profit however, so this should be disabled for them. No performance testing has been done yet, suggestions about how to go about it would be appreciated if deemed necessary. Also not sure if any of this needs to be documented further than already done, it is mostly invisible to the user.
Tested using the dronecan_dsdlc test scripts and Ardupilot SITL. Testing on real hardware remains to be done.