Global Variables with PIC

Thread Starter

chrisw1990

Joined Oct 22, 2011
551
ok global variables with C32..
seems to have solved the problem with
Rich (BB code):
extern unsigned char heartBeat
for an ISR.. but can anyone explain why? i dont use global variables as a rule of thumb but obviously need them for ISRs as you cant pass anything to them.. or return anything..
just wondering. Ta
Chris
 

MrChips

Joined Oct 2, 2009
30,720
An ISR is never called by any part of your program. Hence you cannot pass parameters via the procedural CALL. That is why you have to use global variables.
 

Thread Starter

chrisw1990

Joined Oct 22, 2011
551
yeh i knew that.. but i put that line at the top of my isr.c.. id seen it somewhere before, i want to know if a) its correct that that variable and the one in main.c are one and the same.. and b) why its needed if i included main.h and the variable is in there?
 

nsaspook

Joined Aug 27, 2009
13,086
The "more" correct way is declare global volatile variables in the main .c file, put the isr code in a separate .c file and any extern variables used in a separate .h file so the global interface variables used are clear to the programmer and compiler.

For a simple program with only a few variables it's overkill but with a larger project with many things being passed it will help you understand the data flow.
 

Thread Starter

chrisw1990

Joined Oct 22, 2011
551
The "more" correct way is declare global volatile variables in the main .c file, put the isr code in a separate .c file and any extern variables used in a separate .h file so the global interface variables used are clear to the programmer and compiler.

For a simple program with only a few variables it's overkill but with a larger project with many things being passed it will help you understand the data flow.
thats why i created a main.h file, and so i have quick access to spellings etc of variables and prototypes without having to scroll through the main.c which is ever lengthening.

so what youre saying is..
main.c..
define global volatile variables: volatile unsigned int oogabooga for example.​
isr.c
ISR Code​
isr.h // this is the bit im not sure about.. do you mean extern variables in isr header?
use extern volatile unsigned int oogabooga​

Monsieur Chips, thanks for the help, i know it sounds silly but iv never used global variables so wasnt sure what the extern bit was actually doing..

Cheers for the help/explanations!:D
 

nsaspook

Joined Aug 27, 2009
13,086
so what youre saying is..
main.c..
define global volatile variables: volatile unsigned int oogabooga for example.​
isr.c
ISR Code​
isr.h // this is the bit im not sure about.. do you mean extern variables in isr header?
use extern volatile unsigned int oogabooga​
Monsieur Chips, thanks for the help, i know it sounds silly but iv never used global variables so wasnt sure what the extern bit was actually doing..

Cheers for the help/explanations!:D
Yes. http://c-faq.com/decl/decldef.html

It's not just a good idea to put global declarations in header files: if you want the compiler to be able to catch inconsistent declarations for you, you must place them in header files. In particular, never place a prototype for an external function in a .c file--if the definition of the function ever changes, it would be too easy to forget to change the prototype, and an incompatible prototype is worse than useless.
It's also a good idea to use #include guards. http://en.wikipedia.org/wiki/Include_guard
 

MrChips

Joined Oct 2, 2009
30,720
A lot of programming for embedded MCU is for small memory cores, 2K, 4K, 8K etc.
For a one-time project it is just as easy to have one main.c file where everything is declared.

If you are doing a lot of cross-project programming, cut and paste of subroutines still works fine.

If you are doing extensive modular programming across many different projects but wish to use your own collection of libraries where libraries may need revision then libraries with headers is a sensible way to maintain your code libraries.
 

MrChips

Joined Oct 2, 2009
30,720
Here is an example. I am in the process of writing routines to drive an HD44780 compatible LCD display from many different Microchip PICs. I don't like using stock libraries. I need to know what the code does and I have to be in total control.

So I place the LCD routines in a file called LCD.c

The main.c file needs to know how to call the routines. This "prototype" information goes into a LCD.h file which I "%include" at the top of main.c

The LCD routines need to know which hardware pins are used for RS, RW and E and which port is used for the 4-bit data. This information is defined in a project specific hw.h file which I "%include" in the LCD.c file.

In this example, there are no variables that are shared and hence there is no need for "external" declarations.
 

nsaspook

Joined Aug 27, 2009
13,086
A lot of programming for embedded MCU is for small memory cores, 2K, 4K, 8K etc.
For a one-time project it is just as easy to have one main.c file where everything is declared.

I agree it's just as easy (guilty ;)) but is it just as good months down the road when you need to add/modify the code or fix a bug. The extra 5 min to structure the code to allow the compiler to help you debug is time well spent even on a small 100 line project.
 

Thread Starter

chrisw1990

Joined Oct 22, 2011
551
thanks for the links + assistance, i didnt realise that by putting the variables/struct etc somewhere different (header) it would enable debugging im afraid i did a c project at uni, where it was all combined into one c file.. which obviously lacked all of this depth, and when we got told we would be marked down for global variables.. well.. now im learning about them:)
Thanks for the help guys, much appreciated.. i think im managing the code pretty well, just trying to understand these quirky bits and parts as i go!
 

nsaspook

Joined Aug 27, 2009
13,086
I'm all for structured programming but sometimes the reality of small memory controller devices causes you to just make it work with as few resources as possible. Global variables are ok to use if you can (in a perfect world) track usage with header files and any function other than main using the global should be in a separate .c file.
 
Top