CRC32 code

This is a forum for discussing the development and testing of alpha MS2/Extra code. Documentation
(Runs on MS2 and Microsquirt)

Moderators: jsmcortina, muythaibxr

Post Reply
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

CRC32 code

Post 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.
jsmcortina
Site Admin
Posts: 39585
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK
Contact:

Re: CRC32 code

Post 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
I can repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk

My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
jsmcortina
Site Admin
Posts: 39585
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK
Contact:

Re: CRC32 code

Post 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
I can repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk

My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: CRC32 code

Post 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.
Post Reply