Comments on: Efficient C Tip #11 – Avoid passing parameters by using more small functions

By: C Programming Resources | Mechanics, Electronics & Computing

C Programming Resources | Mechanics, Electronics & Computing — Mon, 12 Sep 2011 02:40:19 +0000

[...] C Tips #7 – Fast loops Efficient C Tip #11 – Avoid passing parameters by using more small functions Efficient C Tip #13 – use the modulus (%) operator with [...]

By: C Programming Tips | Mechanics, Electronics & Computing

C Programming Tips | Mechanics, Electronics & Computing — Sun, 11 Sep 2011 14:55:42 +0000

[...] C Tips #7 – Fast loops Efficient C Tip #11 – Avoid passing parameters by using more small functions Efficient C Tip #13 – use the modulus (%) operator with [...]

By: Krzysztof Wesołowski

Krzysztof Wesołowski — Mon, 29 Aug 2011 01:44:13 +0000

I think that both approaches should be considered when designing interface. For example when multiple similar peripherals are used one big function (or separate function for each action) can be usefull. I also prefers when variable passed is USART1/USART2… than dealing with functions with prefixes.

On the other hand separate function for each object/action are imho good decision when objects are separate and not used ass group/array of objects. This also make it easier to adjust implementation for specific needs (i.e. inverted logic on some LEDs).

Personally when few clock cycles efficiency is not needed it might be the best way to create class led, objects for led1, led 2… etc – and led* array when iteration through multiple leds is needed.

By: David Brown

David Brown — Mon, 27 Sep 2010 10:43:27 +0000

avr-gcc will do both, inlining small functions and the big function. But it needs a little help. First you have to make sure that the function definition is known at compile-time – either include the function definition in the same module that it is used, declare it “static inline” in a header file, use -fwhole-program, or try out the new LTO options.

Secondly, while gcc will automatically inline the small functions, it will not automatically inline a big function like this (unless it knows there is only one use of that function in the program). So you have to label it “inline”.

By: Bernhard Weller

Bernhard Weller — Mon, 23 Aug 2010 14:14:58 +0000

While this may be nice and useful in case of switching on and off LEDs, I doubt you can use this technique for helper functions like converting different dataformats.
I found myself in the position to renew a part of an electronic which used a PIC, sending some sensor data already calculated and normalized to a value ranging from zero to one in a floating point format. Now I used a MSP430 in this case. Being not really familiar with the PICs I just implemented the feature as anyone would.
I got myself in trouble on the first sensor readings which had some funny values, and I started wondering what was going on. The problem lies in the floating point format, PIC uses it’s own format and the other side of the communication was expecting a PIC float. The MSP uses the IEEE-754 floating point format.
So I wrote a function which turned a IEEE-754 floating point number into four bytes (ready for serial communication) representing the PIC-float with the same value.
Now how would you prevent passing an argument to a function in this case?
Using a global variable comes to mind, but that’s sacrificing good coding style (no use of global variables where possible).

I now pass references to the converter-function, this reduced code size by a few bytes (about 20 bytes):

void ConvertFlt32ToPIC(const Flt32 &infloat, uByte &lsbbyte, uByte &midbyte, uByte &msbbyte, uByte &expbyte)

References as parameters are a C++ construct (if I remember correct) so a C implementation would probably use a const pointer to some type (uByte* const, const Flt32 * const)
I tried some things with references and it seems like they only reduce code size (I haven’t checked on cycle count) if the variable type is longer than the normal size the processor handles. So in case of a 16-bit MCU passing as reference seemed only beneficial if the parameter is bigger than 16 bit.

By: Doug

Doug — Tue, 27 Jul 2010 23:32:16 +0000

I guess to me this solution is only about half-way to the most efficient solution. To turn on an LED I define a macro such as “#define LED1_OFF PORTB_PORTB1 = 0;”. Then a call to LED1_OFF is visually descriptive, doesn’t use any stack space for call and return, requires only one line of assembly code and can be changed in one location if the hardware changes (moving LED1 to a different GPIO for instance).

By: Frank

Frank — Mon, 29 Mar 2010 09:16:36 +0000

@Dan: the OO approach is very nice, I use it too.
My Duo-LEDs can
- be turned on or off and toggle
- can blink
- and can change its color.
This leads to member functions
- C_DuoLED_On(struct C_DuoLED* me), C_DuoLED_Off(struct C_DuoLED* me), C_DuoLED_Toggle(struct C_DuoLED* me)
- C_DuoLED_BlinkStart(struct C_DuoLED* me), C_DuoLED_BlinkStop(struct C_DuoLED* me)
- and C_DuoLED_SetColor(struct C_DuoLED* me, eLedColor color).

This seems to be a lot of functions, but all commands are completely orthogonal, the first parameter is always a kind of “this”-pointer to the instance of the Duo-LED. This instance keeps track of the state of the LED such as the current color, the on/off-state, a link to the SW-timer for blink support and the IO-pins of the CPU where the LED is connected to. In this way the LED always knows about its own state, there’s no need for bookkeeping by clients that simply want to use the LED.

By: Carlos

Carlos — Thu, 18 Feb 2010 15:50:08 +0000

Suppose we have several leds (say 32) in our system, and we want to turn them ON in a consecutive way (maybe a lighting application?). With the single function approach the code could be:for (i=0; i<32; i++){ led(i, LED_ON); wait();}While with the multiple function approach:led1_On();wait();led2_On();wait();led3_On();wait();…led32_On();wait();I guess someone may have better ways of coding this, but if this is not the case, and we use this code, can it be possible that the overhead introduced by the second approach (due the amount of code aggregated) be at the end more costly than using the single function approach?What about its flexibility?

By: david collier

david collier — Mon, 15 Feb 2010 11:10:02 +0000

I'm with kepa.The inefficiency of breaking the code by failing to correctly edit one of multiple copoiies of the same code is what I'd be worrying about.Now in practise, one could/wold probably be able to set up a constant array of bit masks, which would allow one to deal with the selection of the target LED by picking out an array entry.I might even go so far as to use something similar yo do the actions – though that might end up looking a bit clever-clever…. but and, or, xor in turn with 3 fields in an array would work fine – though it would need careful commenting.D

By: Sergio Prado

Sergio Prado — Sun, 14 Feb 2010 14:32:06 +0000

Very good post Nigel!Another good idea is to use some kind of data oriented implementation. For example, you could have:void led(LED_NO led_no, LED_ACTION led_action){ (*led_action)(led_no);}In this case, you would have a structure defining the led number and the port that it is connected, and a group of led functions defined by LED_ACTION. I do not know if it is more efficience than your code, but I think it would be more maintainable, since to include a new led you do not need to create three new functions. It would be just the case of adding a new element in the leds structure.Keep the good work!Sergio PradoSão Paulo/Brazil