Page 1 of 1

CRC32 code

Posted: Sun Apr 16, 2017 6:04 pm
by robs
Been dabbling lately in the TunerStudio interface and, with the NewSerial protocol, CRC32 naturally came up. The MS2 implementation in crc32.s was pretty obviously based on output from gcc. I thought I'd have a go at something a bit more hand-crafted.
crc32.zip
This has pulled a reasonable performance improvement (times in CPU cycles):

Code: Select all

    n   new    old
    6   394    568
  208 11272  16321
 1024 55336  79969
I don't know what the largest thing encoded is going to be, but the latest OutputChannels is 212 bytes, so 208 would be close to that. At 24MHz that has gone from 680us to 470us. Whether it'll even show up in looptime, I'm not sure --- I've just had a quick look at looptime and I see it averages-in values, so I guess it might have a small effect. Mind you, I think it'd make more sense for looptime to be the MAX value encountered since last send, and reset it to zero after each send. That way you'll see the worst case.

To me CRC32 seems to be huge overkill and an 8 or 16-bit hash would have done the job much more cheaply. Perhaps this was needed anyway for CAN?

On the whole, this isn't terribly exciting. It'll only have an effect at all when something's polling RS-232 or CAN. It's just that I felt like writing a bit of assembly language code and this seemed a good candidate. I even wrote it in lower case since you guys aren't so keen on "traditional" style.

Finally, a couple of notes on the code. All calls to this function pass a first argument of 0L, which seems a bit wasteful. I've written the function assuming this value to be zero. I suggest all callers should get rid of the first argument. I've only tested it in the CodeWarrior simulator (hence the cycle counts). It gets the right answers and ends with an RTC instruction; I believe it's plug-compatible with the original, but obviously it needs to be tested in a MS2. It's in the public domain now, so do with it as you wish.

Have fun,

Rob.

Re: CRC32 code

Posted: Mon Apr 24, 2017 3:07 pm
by jsmcortina
Interesting. In MS3 the code is called with a seed or previous value.
The cycletime savings are probably most useful on MS3 in SDcard readback. The code there is slightly different though as it uses some of the S12X instructions.

I will look at implementing your work as any overhead saved allows more cycles for engine control.

James

Re: CRC32 code

Posted: Tue Apr 25, 2017 2:59 pm
by jsmcortina
I thought about this some more and looked at the existing code.
The most critical use of CRC32 in MS3 is already more optimised - I hand optimised it using S12X instructions - so probably wouldn't benefit. The other calls are less time critical.

Overall though, I'm wary of changing something so core for release codes. So, I won't be changing anything in MS2/Extra 3.4.x or MS3 1.5.x. I may revisit this for future development codes.

James

Re: CRC32 code

Posted: Tue Apr 25, 2017 8:05 pm
by robs
Fine with me. It was a bit of fun to write but, as I said up front, not anything to get excited about.

On the CRC, and more a philosophical question than something to act on, I wonder whether it wouldn't be better to update the CRC as bytes are read/written rather than do all the reading/writing then compute the CRC. I'm sure this would add up to more CPU cycles, and a fair proportion of them in interrupt code too, but it would get rid of some lengthy delays in the mainloop itself. Maybe this is already being done in MS3.

Perhaps the most useful suggestion in this thread has been to change the looptime calculation to log the worst case value. More informative than the lagged average it has at the moment.

Have fun,

Rob.