estimating program footprint change?
Hi all -
This topic has virtually nothing to do with Qt, but...there's lots of smart people that frequent this forum, and it is the lounge, so...
My company has a legacy product running on an 8-bit processor. This product is sorely in need of an upgrade, and we're looking at newer 32-bit processors. My current concern is what this will do to the binary footprint. This is an embedded solution and cost of the BOM is important, so this matters.
Does anyone here know of a method for estimating the change in code footprint size when making such a change? Re-hosting the existing code isn't straightforward, as several parts are written in assembly. And I'd like to do better than estimating based on a "hello world" scale project.
My current concern is what this will do to the binary footprint
That will probably increase. However, other people had this problem before you, so ARM for example has 16-bit thumb instruction set next to the regular 32 bit instructions.
To understand the problem deeper, he question is rather: which 8 bit MCU is that? Which code size are we talking about? 8 kB should be no problem to fit in any modern CPU. If 128 kB - then probably a flash of 256 kB is needed and you cannot get the cheapest CPU.
It's probably not possible to test the assembler code, but for the C code you should be able to compile some files and compare the differences.
Hi aha -
The current device is an Atmel ATMega1284P. IIRC, all instructions are 2 bytes. Running our new processor in thumb mode may be of help, so I should add the ability to run in thumb mode to the criteria for device selection.
I'll also compile some existing code and compare sizes.
fcarney last edited by
It might be worthwhile to talk to an Atmel rep. They may have tools/documents for estimating the impact of a processor/platform change. A good rep will have worked with many customers in your situation.
Yeah, I've already started talking with someone at one of Atmel's distributors (that seems to be how they do it these days -- the device manufacturers expect the distribution channel to furnish end-user technical support)...he's been helpful, but it's an area with which he's not too familiar.
I'm starting to get the impression, though, that it's going to be close to 2X larger for the 32-bit code. I hope I'm wrong, because that will cause us problems. Later today, I'm going to try to do some experimental builds and compare object file sizes. I know that's not a perfect comparison, but it's a starting point.