|Anonymous | Login | Signup for a new account||2020-10-26 12:03 UTC|
|Main | My View | View Issues | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000462||Firmware||Init & Config||public||2011-12-03 13:50||2014-02-18 23:05|
|Target Version||0.2.1||Fixed in Version|
|Summary||0000462: Design And Implement Space-Efficient Flexible Tables|
|Description||Current adjustable 3D tables have hard coded axis sizes and locations in terms of storage.|
The new way should use a normal struct with the DEFAULT dimensions setup, but the actual code should NOT use the struct at all, in fact, the struct typedef should only be exposed to the data initialisation code.
Instead the new code should be passed a pointer and a size. From that it should read the first two bytes to determine axis lengths, with the first byte specifying the RPM axis length and the RPM axis data being first after the two specifier bytes. The second byte should specify the load axis length and that should be next, all remaining data can be used for table data, thus it's more efficient, always. Code handling this can simply use pointer arithmetic to access the appropriate fields.
This is related to 0000162 which will effectively get implemented at the same time.
Additionally, each set of handlers of this nature will probably need a hard coded axis field size and data field size.
Right now axis are in 16 bit numbers. This could change to give us even larger data area for tables. The following thread goes over the size changes in detail.
I currently see the firmware using 1k (uint8, uint8, uint8, uint8, uint16) for VE tables and 512 byte (uint8, uint8, uint8, uint8, uint8) for lambda and ignition timing tables. Fuel timing tables could be in the form (uint8, uint8, uint8, uint8, uint16) using 512 bytes to provide full timing tuning in a single table and UI simplicity. However any size combo is possible within the memory allowances.
Validation methods would need to be updated too. And the calculator spreadsheet.
It probably makes sense to implement this with the existing data sizes first to miminise change inside a single block of work. Then the axis can be changed later as a separate block.
|Tags||No tags attached.|
|Issue Type||New Feature|
|Risk of Breakage||high|
|For purposes of keeping the code clean, macro pasting may be required to facilitate multiple versions of the struct in the source for custom/default builds, while still only having one struct def in the headers. The firmware will resolve the structure automatically regardless, but defining it in a type-safe way might be more difficult without these.|
|The type of tables will likely end up stored in the block details repo. Internal conversion methods can be available in a separate lookup based on var use vs var type. Then it's flexible such that you can have 16 bit axis if you want them, or more 16 bit data and 8 bit axes if you want that, etc.|
|Copyright © 2000 - 2011 MantisBT Group|