How to avoid using global vars?

[kWoody_uk]

Hi all,

I have very little formal C training, but a fair amount of experience - however I find it difficult to avoid using global variables.

For example: I need a coms. function to flag that a reply hasn't been received within a certain period of time and the result of this is that the LCD displays a message etc.

How do you ensure that the two separate functions (coms. handling and LCD handling) do not become blurred but can still relay information to each other, without using global variables? I know that it is appropriate to use them sometimes, but they seem to be creeping into my code more often...

I know there are a certain element of people who disregard recommended programming practices, but my old boss was the language guru for a defence company and he gave me a good foundation in the basics which I'd like to aspire to.

Any advice would be gratefully received.

Thanks,

Keith

[newguy]

At my old position we briefly had a "software guru" who also positively HATED global variables. His projects were filled with "get_" functions. The idea being that a module could request some value from a different module through the use of these get_ functions. Define the get_ functions in a .h file which is included in each module that uses the functions but they're only defined inside the module that handles the data.

A word of caution, however: this person's code was a nightmare in terms of speed of execution and stack usage. Function after function, each one line, each calling a different nested function. Finding where he was actually doing the nitty-gritty work was a pain. I designed a dsPIC based communication bridge (CAN - serial) supporting 2 CAN networks and 2 serial streams. He wrote the code that interfaced to the bridge, but was resident on a beaglebone black. He actually managed to bog that thing down even though it was running at 1GHz vs the 80MHz of my dsPIC. His RAM usage was absolutely unreal.

Globals, on a PIC, aren't a bad thing. On larger projects running a RTOS - the encapsulated programming approach has its place. On a PIC without an operating system - don't bother trying to avoid them.

[Ttelmah]

It is better on RAM space, and reduces the risk of variables becoming corrupted, if you keep all variables that are local to a function, local. So everything that is only used inside a function, should always be a local variable.
Using global for stuff that genuinely is 'global' on the other hand makes sense. So something that is talked to by multiple separate functions, really is an excuse for a global variable. Often though it is surprising how few things this really applies to.
Having a global variable for 'comm_timeout', as such may be perfectly sensible.

Keep global definitions in one place. This helps massively, since if you have a include file 'global_defines.h' for example, you can at any time look in this and first, see what variables are global, and also putting a variable here may well make you think again.

If a routine is split into two subroutines, pass these a master variable from the calling function, or have each generate a return status value, rather than using globals.

For things like interrupt driven serial, timers etc., then globals really are going to be used.

Avoid like the plague, 'global' variables for things like local counters etc..

So 'treat with care', 'try to reduce', but accept that they _are_ part of programming for things like embedded applications.....

[asmboy]

Let me add one comment to MR.T's excellent summary: BEWARE any global VAR of MORE than 8 bits that is modified by an interrupt function.

let's say you have an INT32 that can be changed by interrupt.

I've found it necessary to declare a foreground
or local var to insure integrity of the data,

[RF_Developer]

[temtronic]

OK, I'll admit I'm a 'sloppy C programmer' and most of the time my variables are always global. Perhaps in the good old days when memory was expensive, there was a real need to be 'creative' in memory management but these days I just don't see it.
There is no 'right or wrong' to coding, heck if it works...great !

Jay

[ezflyr]

[jeremiah]

I try to keep it balanced though I tend to lean more on the "less globals" side than some others.

For me, I use globals for sure under certain conditions:

1. If I need to use a variable in an interrupt that is also accessed in either another interrupt or the main code (unavoidable here)
2. If I am managing some sort of state or device parameters for the program lifetime (READ: not the device lifetime) and multiple functions need to access those parameters.
3. The code becomes too complex to pass it through a series of functions.

Otherwise, I at least see what it looks like using parameter passing or some other method. We've had global variables bite us too many times to not at least ask the question of "should we" before using them.

I do like using some encapsulation in my code though I don't know if it fits the personal definitions mentioned here (I like to try and separate the implementation of a peripheral from the actual usage code if it makes sense to do so). If I do, I try to make sure that proper use of inlining is at least adhered to to remove any bloat caused and that it doesn't get way out of hand.

At the end of the day though, I have to meet the user requirements, so I do what I have to in order to ensure that goal is met.

[newguy]

[kWoody_uk]

Thanks for the ideas and opinions guys. You know how it is, you're taught by someone and their style tends to rub off on you, for better or worse.

In the end, I just want to make code that works in the simplest way possible, and that I can come back to later without having to pull my hair out to understand (I'm starting to lose it already!)

I know that if I really do have problems, I can always ask for advice on here.

Best regards,


Keith

[Ttelmah]

Well done for asking.

Personally, I tend to have a 'status' variable of some form, that is global.
This then may contain bitfields, or integer values, reflecting the status of various components. It's usually designed so that there is at least one part, which 'if zero', reflects everything being OK.
So this might well have a 'serial_comms_error' bit, a 'calibration_error' bit, a 'usb_error' bit, a 'temperature_error' bit, etc.. Then every software component, can at any time check this for zero, and 'know' that the major parts of the system are working.

[kWoody_uk]

Thanks Ttelmah,

The status bits suggestion sounds like a good idea. I think I'll borrow that from you for my current and future projects :-)

Cheers,


Keith