LM4F120: to ROM or not to ROM?

[dannyf]

A highly unscientific experiment on the performance difference between the ROM code vs. the Stellaris library for the LM4F120 (TM4C) chip. The take-away is that the rom code is not the exact copy of the library code, may be due to code retrival mechanism, or actual code.

https://dannyelectronics.wordpress.com/2016/08/19/lm4f120-to-rom-or-not-to-rom/

I suspect that the same thing is true for the Luminary LM chips as well.

[westfw]

The ROM code has some funky prologue stuff that it uses (?) to keep the entry points identical regardless of ROM code version,etc.


IIRC, you can dig up the source code (which is the same for rom vs library for a given version, except for conditional compilation) and have a look if you really care.   (Hmm.  Maybe not.  It might be the same source api whether you do library code or HAVE it call the rom, rather than actually exposing the ROM source.   Sorry;  not near a real computer at the moment.)

[thm_w]

So is there any compelling reason to have a ROM library like this? Other than the case of ROM bootloader, it seems like something that rarely would be used.
CRC/AES is nice, but if its 2x slower as you've demonstrated, why use it.

A CRC32 table is 1KB. Their AES looks to be ~3KB. For reference the micro used has 256KB of flash:
http://www.ti.com/product/TM4C1233H6PM

And the ROM code functions are here:
http://www.ti.com/lit/ug/spmu367/spmu367.pdf

[dannyf]

So is there any compelling reason to have a ROM library like this?

To save flash space.

Other than the case of ROM bootloader, it seems like something that rarely would be used.
CRC/AES is nice, but if its 2x slower as you've demonstrated, why use it.

It is hard and likely imprudent to extropolate the 2x figure to all ROM functions. Without extensive testing, it is hard to say definitively.

[dannyf]

Case in point: I just ran Crc16() vs ROM_Crc16() and the ROM version is 15% slower. So the "performance hit", if there is such a thing, is function dependent as well.

[andyturk]

It is hard and likely imprudent to extropolate the 2x figure to all ROM functions. Without extensive testing, it is hard to say definitively.

I think westfw hit the nail on the head. There's a big lookup table that maps those ROM calls to actual code and when the routine you're calling is very quick (e.g., setting a  GPIO pin), the percentage time of that lookup overhead is much higher. If you're calling a ROM entrypoint with lots of code behind it, the cost of the lookup will disappear into the noise.

Should you use those ROM calls? Well, the code is already there in the device, so it doesn't cost anything. I used ROM calls for things like clock configuration that I only used once and where I didn't want to figure out all the magic necessary. For other things, like GPIO pins, I wrote my own drivers that went directly to registers. The TM4C port API has some interesting tricks and those aren't available in the ROM.

Sometimes the ROM code is buggy though. You can see this where TI has removed MAP_ equivalents of some calls from newer versions of driverlib.