programming in C efficiently? tips/tricks/

[DanD]

Hello,

We'll ive been coding away at my project (using MPLAB IDE, C18) and am now at 250 lines of code and things are getting a littly hairy. so i thought id seek some guidance in writing code that compiles effeciently for the PIC.

I use a lot of subroutines. Is there a resource hit for each subroutine? or does it all end up the same once compiled?

liek for example i have:

getADC();
conv2temp();
setAlarm();
display();
etc.

all to manipulate one piece of data from the ADC. am i hurting myself w/ a bunch of subroutine calls? it could easily be done just the same sequentially but i like the 'readability' of the subroutine calls.

any other general tips/tricks to make my C code as PIC friendly as possible?

Thanks

 

[Papabravo]

IMHO your priorities a bit out of joint. If your goal is to get something working and you're just starting out, they should be:

1. First make it work
2. Then make is small or fast whichever you prefer
3. Then make it elegant.

It is also worthwhile to ask how much effort it will be to figure out what is going on if you have to come back after 6 months and have forgotten everything.

Now, once it is working it is time to move on to the second priority and ask questions, form hypotheses, and test the results. That will teach you more about good code than we can convey.

In everything that you do there will be tradeoffs. It is difficult to comment on the use of subroutines without more information. There is a time penalty, but usually a space saving if the subroutine is called more than once. The use of local variables on a stack is very popular on many processors. In a PIC it places an extreme burden on the application to execute code for creating and tearing down stack frames for a single piece of data from an A/D converter.

I hope this information will be helpful to you

 

[DirtyLude]

Optimization is also quite dependent on the compiler. The best thing to do is to check the assembler code generated by the compiler to see what it's doing. I would only do that, if I required some optimization of the code, though, or I just wanted to learn what it was doing. You'll find that sometimes the compiler strays quite a bit.

 

[GraveYard_Killer]

Hello,

We'll ive been coding away at my project (using MPLAB IDE, C18) and am now at 250 lines of code and things are getting a littly hairy. so i thought id seek some guidance in writing code that compiles effeciently for the PIC.

I use a lot of subroutines. Is there a resource hit for each subroutine? or does it all end up the same once compiled?

liek for example i have:

getADC();
conv2temp();
setAlarm();
display();
etc.

all to manipulate one piece of data from the ADC. am i hurting myself w/ a bunch of subroutine calls? it could easily be done just the same sequentially but i like the 'readability' of the subroutine calls.

any other general tips/tricks to make my C code as PIC friendly as possible?

Thanks

as i have been reading books for C programming, I learned that main() function, as much as possible, should call the subroutines just like what you did.

also, if it is do-able in your part, separate the files into .c and .h and make them more modular.

although this is a different thing, MPLAB C18's optimization is very good as it can make your compiled code small. But if your program is very tight on timings, you should decide from the start if you will turn on the mplab c18's optimization features. because this is what happened to me yesterday :lol: , I created bit banged multiparallel programmer for PICs for production use, my code doesnt work when optimizations are enabled, so i have to stick with optimizations disabled for my code to work since I started doing it without optimizations :lol:

 

[BeeBop]

Hello,
I just had to add my 2 cents.

I think what Papa Bravo said:

1. First make it work
2. Then make is small or fast whichever you prefer
3. Then make it elegant.

is some of the best advice I've heard, and would rate it right up there with an adage I learned in my first (only) programming course:
Good programming practice for subroutines: High coupling, low cohesion.

Regards,
Robert

 

[Oznog]

I use a lot of subroutines. Is there a resource hit for each subroutine? or does it all end up the same once compiled?

It's a complicated issue. One is whether you care about code length, execution speed, or code clarity.
It takes a number of cycles to jump to a routine and return. It's highly variable depending on how much data you pass.
If a function is used only once, it's better to just write the operation in the code for length & speed but may be worse for clarity. Like I want to make one file that writes out all the LCD display tasks all in one place. MCC allows you to use the "inline" keyword which fixes that conflict.

It's also a matter of opinion. For example I might not use getADC() just to get a value off the two registers, it's not worth the jump, context saving, initialization of a variable, and return. But my situation is often one where I need to be mindful of speed. I could use the inline keyword too.

 

[philba]

While I think you have gotten good advice overall, I don't at all agree with the "just make it work, then make it fast". Too often, I have seen people wind up throwing out their first attempt because of this.

I much prefer to think through performance as well as functionality before writing a line of code. For example, if you don't think through your data structures from a performance perspective, you may have to completely redesign them. That may force you to completely rework your program. Complete ignoring performance until later is a way to waste time, IMO.

On the specific question of using procedures. It's generally a good idea to modularize your code. It allows you test that part and, thus, to isolate problems Hoiwever, if you are calling the procedure at the "bottom" of a loop, you may want to just put it inline. call overhead could be a significant percentage of the total time. But, if you call the procedure infrequently, the overhead is insignificant.

In general, efficiency of C on micros needs a very close look. What I do with a new complier is write a number of common constructs (arracy accesses, switch statements, various loops, struct de-referencing, pointers etc) and then look at the generated code. For example you will discover that on the mid-range PIC, rom array indexing isn't very efficient.

to put my comments in perspective, I've been writing operating systems in C since 1976 for about 10 different architectures.