[SOLVED] A sketch from several files

I have two separate working sketches (.ino files) in their own separate directories. The two sketches have been written so they can eventually work as one - but it is easier to develop and troubleshoot while they are separate.

I haven't found any instructions or advice about how to have several separate files as part of an Arduino project (without using a library). This is easy to do with Ruby, but that's an interpreted language.

Each of my sketches is internally organized like this ...

declaration of global variables;



loop() {
  get serial input from PC
  call the relevant subroutine
  // this loop code is identical between the two sketches

various_subroutines() {


I can envisage creating a short .ino file that just has the setup() and loop() code and then two separate files with the rest of the subroutines - but what file extension should I give to those files?

Also, is it possible to load the global variables from the two separate files or must they all be in the central file?

I am reluctant to physically merge all the code (with copy and paste) until I am satisfied the project works. Even then it would be much better if the pieces could be kept separate for further development.

There might also be a third part at some time in the future.


If you click the down arrow at the top/right of the IDE (at least in Windows) you will see that you can add extra tabs to the IDE. Each tab will cause an extra file to be created in the program folder which contains the code in the IDE tab.

All the files in the folder will be included when the code is compiled. The extra files work for me if they have the .ino extension. As you know, you will need to resolve any conflicts and setup() and loop() must only appear once across all the files so you cannot simply copy several working program files into the same folder and compile them together.

I have used the multi file approach to split useful functions between different files so that they could be reused.

Thanks Bob,

That seems to work very well and is very simple. I was afraid I might have to figure out .h files and such.

In case anyone is interested I have noticed that it loads the secondary files in alphabetical order and global variables are only accessible if they have been declared in a file that has already been loaded. So global variables in file bbb.ino are not accessible in file aaa.ino whereas bbb.ino can access global variables in aaa.ino.

There is no problem calling methods in bbb.ino from aaa.ino


When I have used multiple tabs/files I have always had a 'master' program in which all global variables are declared and initialised and have used the subsidiary files to hold functions so I have never encountered the problem that you describe. Personally I would rather do it that way so that the 'master' program is more readable and global variable declarations are more immediately visible.

I tend to tuck away the global variables with the functions that use them, so in my current LED display driver, I have a buffer which holds the screen, it is just defined within the functions that work on the screens and not accessed anywhere else. I find that works away for holding things that are not needed everywhere and making it clearer.

I tend to tuck away the global variables with the functions that use them

I cannot make sense of that. Variables are either global and available anywhere in the program or local, in which case they have a scope which is confined to the function in which they are declared, or an even smaller scope such as a for loop.

Well, of course they are global so they can be used anywhere, but generally speaking not every bit of code uses them.

So in my current sketch, all the functions that use the screen directly are all in one file (also when I first used it I realised I couldn't access the global variable outside that file). As all those functions work correctly, and there is no reason for anything else to access the screen variable, it is in that file.

So when I am editing other files, I really don't need to know about it.