I've been reading up on using tabs for merging multiple functions into one common file operated from a main program. I have several operating programs that are completely independent but want to understand the proper format for this process such as what goes in main versus what goes in the tab.
I'm accustomed to the C style format where all the custom functions are loaded to the bottom of main but am drawn to this concept of tabs for improving my skills.
The current project I have is several sensors that all perform different tasks, such as an IR sensor and sonic sensor, respectively labeled in the tabs Sharp_IR_Sensor and HC_SR04_Sonic_Sensor.
As I said above, these program are running independent. For the IR it looks like this:
void setup() {
Serial.begin(9600); // start the serial port
}
void loop() {
float volts;
float distance_cm, distance_in;
volts = analogRead(A1); // voltage return value
distance_cm = (6787 / (volts - 3)) - 4; // linearization of voltage read
distance_in = distance_cm / 2.54; //conversion from cm to inches
delay(500); //repeat every 0.5s
if (distance_cm <= 30 && distance_cm >= 4) {
Serial.print("Distance in cm: ");
Serial.println(distance_cm); // print the distance in cm
Serial.print("Distance in inches: ");
Serial.println(distance_in); // print distance in inches
}
else if (distance_cm > 40) {
Serial.println("Object out of range");
}
else if (distance_cm < 10) {
Serial.println("Object too close");
}
}
My question comes down to how much of this independent program goes to main, if any, and how do I prompt it. Will my tabbed program have a similar declaration replacing loop() with something like ir_sensor()?
My first attempt gave me "error: #include expects "FILENAME" or ", which has led me here.
There's a variety of ways to do this. The file that contains setup() and loop() usually have the secondary file name "*.ino". You can have a second file, Sharp_IR_Sensor.h that contains the function prototypes for the functions used in the program. The *.ino and *.h files should be in the same directory, which will give you two tabs in the Arduino IDE. Near the top of the *.ino file you should have:
#include "Sharp_IR_Sensor.h"
The double-quotes means that the compiler will search your working directory for the header file. If it doesn't find it there, is will search the default library directory. If you use angle brackets,
#include <Sharp_IR_Sensor.h>
the compile looks in the default library directory.
If I have a simple program, I would likely have only two files--the INO and header file--in the working directory. If I have a complex program, I will often divide the files by function:
Initialization -- do everything necessary to set things up--initialize sensors, open databases, etc.
This is usually your *.ino file with setup() and loop().
Input -- code that acquires the data to use. database, keyboard, sensors, encoders, etc. I always
make these *.cpp files, not *.ino files. You lose type checking if you use *.ino file
names.
Process -- code that takes the raw data and processes it according to an algorithm into its final
form.
Output -- code that displays the results, passes the results to another process...whatever.
Termination -- gracefully end the program by returning the resources in Step 1...close databases,
free memory resources, etc. Usually NOT part of an embedded system.
The thing to remember is that even with the tabs you're really just writing one big file. The IDE will just stitch them together into one file before it compiles.
This is true with .ino files and pretty much how including a .h file works but that is not true with source files (.cpp, .c, .S). They are compiled as a separate compilation unit.
The IDE will let you have .INO, .CPP, .H, .C, .S files in tabs.
The INO files get concatenated. Massaged for Arduino-ese. Result is compiled.
The CPP, C, S files get compiled as Nature intended.
The Arduino-ese massaging does not always find and insert forward references. But on the whole it works quite well. And enables you to manage projects conveniently.
Note that you have to obey the respective Language rules properly for CPP, C, S files.
They can all include local H files in the normal way.
Yes, they never mentioned .cpp files but .h files were, which made it more likely they might eventually be used and econjack did mention .cpp so I just thought I should make it clear.
scotdani:
I'm accustomed to the C style format where all the custom functions are loaded to the bottom of main but am drawn to this concept of tabs for improving my skills.
Maybe I misunderstand you, but the compiler needs to know what a function looks like (which arguments it takes) before it can 'use' it.
So your functions can't be after main(). You can however declare the function prototypes before main() so the compiler knows about them and write the implementations after main().
sterretje:
So your functions can't be after main(). You can however declare the function prototypes before main() so the compiler knows about them and write the implementations after main().
Yes, this is what I was trying to describe.
david_prentice:
The IDE will let you have .INO, .CPP, .H, .C, .S files in tabs.
The INO files get concatenated. Massaged for Arduino-ese. Result is compiled.
The CPP, C, S files get compiled as Nature intended.
The Arduino-ese massaging does not always find and insert forward references. But on the whole it works quite well. And enables you to manage projects conveniently.
I'm not wholly familiar with all of the extensions outside of INO and C, and not sure what concatenated means.
econjack:
If I have a simple program, I would likely have only two files--the INO and header file--in the working directory. If I have a complex program, I will often divide the files by function:
Initialization -- do everything necessary to set things up--initialize sensors, open databases, etc.
This is usually your *.ino file with setup() and loop().
Input -- code that acquires the data to use. database, keyboard, sensors, encoders, etc. I always
make these *.cpp files, not *.ino files. You lose type checking if you use *.ino file
names.
Process -- code that takes the raw data and processes it according to an algorithm into its final
form.
Output -- code that displays the results, passes the results to another process...whatever.
Termination -- gracefully end the program by returning the resources in Step 1...close databases,
free memory resources, etc. Usually NOT part of an embedded system.
This logic I can follow, now I need to understand what files do what respectively.
INO files I gather are executable files containing the respective functions, print statements, etc in the Arduino language.
Regarding H files, what sort of data would this file contain? I'd be curious how to dissect the IR sensor example I originally posted. If I understand the #include correct, with a local H file it'd be in double quotes?
scotdani:
I'm not wholly familiar with all of the extensions outside of INO and C
.cpp is C++. Arduino sketches are actually C++ after the IDE does some minor modifications to the code so it's more common to use C++ with Arduino but you can also use C if you like. At the level of programming most beginners do in Arduino sketches the two languages are the same.
.S is assembly. Assembly is the language your C++ or C code is translated to during compilation. Generally you don't need to use assembly unless you want a better understanding of the inner workings of your code.
scotdani:
not sure what concatenated means.
Let's say you have a sketch named foo with three .ino files.
foo.ino:
void setup(){}
asdf.ino:
void loop(){}
bar.ino:
void someFunction(){}
During the compilation the Arduino IDE concatenates these into a single file with the .ino file that matches the sketch name first, followed by the other ino files in alphabetical order:
No, they're not executable. They're text files that contain C++ code.
scotdani:
the Arduino language.
There is no Arduino language. It's C++.
scotdani:
Regarding H files, what sort of data would this file contain?
Most commonly the .h file will contain declarations. Definitions are in the .cpp file. However, you can put anything you like in the .h file. It's possible to put all your code in the .h file if you want.
scotdani:
If I understand the #include correct, with a local H file it'd be in double quotes?