Add suport to use hardware CRC calculation for F4 series #526
Conversation
- add native code project for F4 series - update TinyBooter and TinyCLR projects in Solutions to be able to choose from hardware/software CRC library
| - can only handle buffer sizes multiple of 4 otherwise the calculation is incorrect | ||
| - can not handle initial CRC values, only 0 is admited | ||
| - all the above can be fixed with more code so feel free to jump in ;) | ||
| */ |
There was a problem hiding this comment.
Given these restrictions how does this work with NETMF, NETMF often chunks data into blocks to maintain the appearance of multitasking in a single thread. So it will compute the CRC for a portion of data, use that result as the starting seed of the next so if only 0 is allowed, won't that fail?
It would be interesting to understand the variations of hardware CRC so that we can adjust the HAL layer API surface to better accommodate real world hardware, if not in the interpreter at least it could be done for AOT compilation.
There was a problem hiding this comment.
The current working Solutions are for F4 series which are covered by this code.
I thought on adding this note there to make people aware of the hardware differences with other STM32 series.
The hardware variations are documented in ST's AN4187
There was a problem hiding this comment.
@smaillet-ms Unfortunately, the hardware CRC unit design on F4 is rather limited, further iterations support configurable polynomial, 8/16/32 bit data size, programmable initial value and bit reversal, which makes it significantly easier to use.
The calculation takes 4 AHB clock cycles for 32-bit data; the data size can be dynamically adjusted to minimize the number of accesses (i.e. 32, 16, 8 for 7 bytes).
| */ | ||
|
|
||
|
|
||
| UINT32 SUPPORT_ComputeCRC(const void* buffer, int size, UINT32 initCrc) |
There was a problem hiding this comment.
Do you have any performance measurements on the hardware based solution vs. software? The table based software approach is pretty small in code size, big on data size for the table and reasonably fast, so I'm curios to see how much better the hardware form is.
There was a problem hiding this comment.
I haven't hard measure it. But being the CRC peripheral in the silicon it would be expected to be way faster than any software algorithm.
Anyway you can read all about ST own comparison on their App note above. They claim the hardware peripheral is about 60 times faster than the software equivalent.
|
I believe that this PR now has all the features of the original implementation... |
This provides a nice performance improvement when debugging and making use of the debug connection which CRC calculations abundantly on every packet rx/tx.