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.