LM4F120: to ROM or not to ROM? - Page 1
Forum section: electronics / general

author: dannyf
author_rank: Super Contributor
timestamp: August 19, 2016, 02:02:00 pm
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: August 19, 2016, 06:21:05 pm
content: 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.)

author: thm_w
author_rank: Super Contributor
timestamp: August 19, 2016, 10:36:34 pm
content: 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/TM4C1233H6PMAnd the ROM code functions are here:http://www.ti.com/lit/ug/spmu367/spmu367.pdf

author: dannyf
author_rank: Super Contributor
timestamp: August 19, 2016, 11:39:49 pm
content: QuoteTo save flash space.QuoteIt is hard and likely imprudent to extropolate the 2x figure to all ROM functions. Without extensive testing, it is hard to say definitively.

author: dannyf
author_rank: Super Contributor
timestamp: August 20, 2016, 12:26:36 am
content: 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: August 20, 2016, 03:04:16 pm
content: Quote from: dannyf on August 19, 2016, 11:39:49 pmI 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.