title: Is this strategy, to avoid global variables in C, right?
body: <p>in my (personal) embedded project global variables are piling up. I need those variables to be acessible from the ISR (interrupt service routine) and/or from a menu system (so that they can be modified by the user) but at the same time I'd like to avoid having too many globals.  </p>
  
  <p>Since they can be grouped for modules I thought that I can encapsulate them in their own .c file, declared as <code>static</code> or <code>static volatile</code> , and expose to the outside world some functions to handle them. </p>
  
  <p>Something along the line of:</p>
  
  <p><strong>in module1.c</strong> </p>
  
  <pre><code>#include module1.h
  
  static volatile int module1_variable;
  
  int getModule1Var(void){
      return module1_variable;
  }
  
  void setModule1Var(int i){
      //some code to disable interrupts for atomic operations
      module1_variable = i;
      //some other code to re-enable interrupts
      return;
  }
  </code></pre>
  
  <p>module1.h would contain the function prototypes, structs and all the other elements for making the module work except for the static variable definition of course</p>
  
  <p><strong>in main.c</strong></p>
  
  <pre><code>#include module1.h
  
  void main(){
      //setting the variable value, could be done from a menu 
      setModule1Var(15);
      //remaining application code
  }
  
  void generic_ISR(){
      //trivial usage example
      doSomething(getModule1Var());
      return;
  }
  </code></pre>
  
  <p>This scheme would naturally be extended to the other modules.</p>
  
  <p>Now my questions are:<br>
  <strong>is this a good approach? Is it the same to simply have a bunch of globals? Any major drawbacks?</strong></p>
  
  <p>I also thought I could use some sort of mix like still having the global variables to allow direct manipulation by the ISR (since function calls from the ISR are sometimes frown upon) and the functions in every other case. Would this be better?</p>