optimization of embedded resources

[Vladimir Yanakiev]

Hello, I have question:
When u writing a software for microcontrollers it happends very often to optimize something, for example minimize memory, CPU load et.c
what resource in embedded devices is most frequently optimized (personally by yourself, or other way(by compilator et.c.))
RAM, ROM, CPU load or any other

would be thankfull for your opinion in personal or profesional expirience.

p.s. I need these answers for scientific research.

 

[NorthGuy]

If I need to optimize, it is almost exclusively for speed.

 

[Ian Rogers]

Ditto... Mainly for speed.... A couple of times for data space.... Nowadays the compilers are extremely efficient, so sometimes you need to UN-optimise ( if there's such a word ).. I know that sounds mad, but on occasion....

 

[atferrari]

Ditto... Mainly for speed.... A couple of times for data space.... Nowadays the compilers are extremely efficient, so sometimes you need to UN-optimise ( if there's such a word ).. I know that sounds mad, but on occasion....

Why would you want do that Ian?

 

[Ian Rogers]

I knew someone would ask.... Simply for simulation!!! Optimization plays havoc with coff/ debug files... When optimized, the code will be reused more than you can imagine... Its actually a really good way to learn how to write good C code.

 

[NorthGuy]

the code will be reused more than you can imagine...

That would mean the C compiler tries to optimize for the code size (which actually makes things slower).

 

[Ian Rogers]

That would mean the C compiler tries to optimize for the code size (which actually makes things slower).

True! but you can optimize for speed OR size... If you are short of space you have to.... The OP wants to know why code is optimized, not why I personally optimize..

My systems are not really time dependent... Usually I try to cram a program into a PIC18F4520.... My latest program has about 48 bytes spare!! I have now looked at swapping to the PIC18F4620.. Then it will not bother me again...

 

[misterT]

I optimize for size by default. I try to optimize the performance (speed) with good code design.
I only optimize for speed (using compiler) only if I really need to.. and even then I build a separate library out of it.

 

[NorthGuy]

I optimize for size by default. I try to optimize the performance (speed) with good code design.
I only optimize for speed (using compiler) only if I really need to.. and even then I build a separate library out of it.

Why do you optimize for size? Do you often find yourself in a situation where your program doesn't fit MCU?

 

[Ian Rogers]

If he's anything like me... I always have the resource usage manager in view.. The code speed can always be optimized by me to a degree I can live with... The size, however, cannot... As I have my boards laid out and certain things are set in concrete, I'm always a bit loathed to swap micro's.... The reason! Even swapping from a pic18f452 to the newer pic18f4520, had silly little issues.... I would rather tighten my code than shift up to a newer bigger processor.

I'm hoping the next step for me is... A new PCB with a decent sized pic32... It's in the design stages at the moment, but ongoing products will still be using the faithful pic18 for some time yet...

The logic... "Why fix what ain't broke"... I have re-visited my code soooo many times now, it must be as tight as I could possibly get it...

 

[Pommie]

Ian,

If you're going to switch to a more modern pic then can I suggest the pin compatible 18F2xK22 - 64k ROM 4k RAM 1k EEPROM 64MHz int osc, 7 timers, dual EUSART etc. and only around $2 each.

Mike.

 

[misterT]

Why do you optimize for size? Do you often find yourself in a situation where your program doesn't fit MCU?

Same question can be asked about optimizing for speed.. "do you often find yourself in a situation where your MCU is not fast enough?"

I want to keep my code tight. At debug phase I use lot of UART communication reporting back things and those strings add up. Sometimes I need to add floating point library just for debugging etc. I want to use the memory efficiently even if I have plenty.

And I do have the resource manager always in view. I wan't to know how much each module "wastes" memory.
And my modules are meant to be re-usable. Someday I may use it in a very small device with very limited memory. If some "very general purpose" library gets "unreasonably large", I usually try to find out why.. and try to re-design.

Anyway.. has anybody even tested how much larger your code gets when optimizing for speed. Or how much faster your code gets when optimizing for speed. I have, the difference between size/speed is usually irrelevant, and the selection between optimization levels is more psychological than practical (when compiling for the "final product", debugging is different case).

Again I say that the design of your program, the "software architecture", is what really matters.

Example: Calculating a function using series expansion and fixed point can make very tight code, but is not very fast compared to look-up tables. But, look-up tables use lot of memory.. that kind of choice makes such a difference that no compiler optimization can match. Maybe you want to use look-up tables an optimize for size so that you have more memory for tables. Or maybe you want to use series expansion and fixed point and optimize for speed..

 

[Ian Rogers]

Ian,

If you're going to switch to a more modern pic then can I suggest the pin compatible 18F2xK22 - 64k ROM 4k RAM 1k EEPROM 64MHz int osc, 7 timers, dual EUSART etc. and only around $2 each.

Mike.

I'm always a bit loathed to swap micro's.... The reason! Even swapping from a pic18f452 to the newer pic18f4520, had silly little issues....

 

[NorthGuy]

"do you often find yourself in a situation where your MCU is not fast enough?"

Not often. Most of the time, I don't optimize anything. I try not to waste things, but that is just out of habit.

I think I would optimize for speed regardless of the CPU speed. When you have lots of parallel processes, it's important to make sure nothing clashes with each other. This, certainly, includes hardware, which also leaves at its own pace. An ability to make certain things run faster may lead to a better overall design. And conversely, the fact that some things run slow, impairs your abilities at the design stage.

BTW: Well organized lookup tables take less memory than floating point libraries.

 

[NorthGuy]

Even swapping from a pic18f452 to the newer pic18f4520, had silly little issues....

Just out of curiosity, what were the issues?

 

[Ian Rogers]

Adcon register and PBADEN... Seems stupid enough, but if you don't read addendums it could take days to fathom what's going on... The trouble was that at the time C18 had just changed to mplab18 and screwed with the ADC header.... Even debugging went daft as the coff reported I was using a compiler that I never installed..... I had to create a bogus directory and copy all the source to this "imaginary" compiler version so I could debug to find out what gives...

It's a learning curve no mistake...

 

[nsaspook]

Just a heads up on this subject. If you're using C18 and MPLABX don't use version 2.15. The optimizations/extended mode options are stuck on 'all disabled'. A support ticket has been submitted with a fix out shortly.

 

[Ian Rogers]

MPLABX..... Maybe a few years from now... When they have properly debugged it...

At the moment if you have two projects open...ie one for pic16f887 and one for pic32... The IDE assumes only one device header is needed so whinges about everything.... You have to close the project you are not working on. close the IDE and re-open to be able to use the correct header....

At the moment it's far to buggy to be used professionally...

 

[misterT]

Ian used to be strict about off-topic.. what happened ?

 

[misterT]

BTW: Well organized lookup tables take less memory than floating point libraries.

That's why I said fixed point.