With multiple files, how does the Arduino IDE knows what to compile??

@ work I develloped a python script to generate state machine files using a graphic representation as source. I also made scripts to generate some extra stuff such as a file for timers, round robin tasks, IO lists and their descriptions and the xxx.ino is also generated.

I want to make a stripped version of this project generator for the hobby community. The idea is that you first create basic state machine in a porgram called 'yEd', use the script to create the source codes. Then you must assemble the IO files. At work we had a .c and a .h files because our IO have to have descriptions to display on a monitor. And after all files are generated the rest of the project is to be assembled. As software timers are implemented you only have to fill in the state machine and it's states.

The syntax of the state machine looks as follows:

State(startKraken) {
	nextState(turn2kraken, 0); }

State(turn2kraken) {
	nextState(stop4kraken, 0); }

State(stop4kraken) {
	nextState(krakenOut, 0); }

State(krakenOut) {
	if(clusterIndex == (clusterAmount - 1))	nextState(Kraken_IDLE, 40);  // conditions to be filled in
	else					nextState(turn2kraken, 40); }

It is just a fraction of the function. It is a switch case with a clever written macro.
With more macros I managed to let a single state look like:

State(turn2kraken) {
	entryState{

	} 
	onState{
		if(condition) exit = true; 
	}
	exitState {
		return true; 
	} 
}

This is just a part of the 'magic'

It is my believe that everybody who speaks english may understand what the code in my format supposes to do.

There is one thing I have to know about arduino IDE.

The work project has 2 sub-folders in the program's directory. One sub folder is called "modules" and contains our machine's unique source and header files. The other sub folder is for the basic stuff which every machine has; basic functions, io lists, timer software. This is stuff which is not to be altered.

We compile stuff with a compiler to which I must tell which files the compiler must compile. When we start a new project, we just generate what we need and copy the entire content of the basic stuffs and the modules.

That means we that we also copy modules we do not need, we simply tell the compiler not to compile these files.
When I put files in the main program's directory for arduino. Arduino seems to compile every thing?

I was wondering how this precisely works. Does arduino look at the #includes in the files? to know what to compile and what not? Or does the IDE simply compile every .ccp it can find in the main folder? and in all the sub folders?

bask185:
We compile stuff with a compiler to which I must tell which files the compiler must compile.

[....]

That means we that we also copy modules we do not need, we simply tell the compiler not to compile these files.

Presumably your Python program tells the compiler what files need to be compiled?

Couldn't it be adapted so it only copies those files and then the Arduino IDE could just compile everything it sees?

...R

Robin2:
... and then the Arduino IDE could just compile everything it sees?

Well that is my question, does arduino work in that way?

Robin2:
Presumably your Python program tells the compiler what files need to be compiled?

I will most likely do precisely this.

The reason why we did what we did, had to with git. Some of our teammembers wanted one software project which would be universal for every machine. In some .h file you'd only #define which machine type the machine is, and the right components would be compiled. In this method we would house the software for our entire machinepark in just one git repo. I personally find this a bit 'overkill' and it is likely we will not see through it, but that is a problem for later on and a problem for us :wink:

Copy? Sounds bad. How do you upgrade existing machines when a core file changes?

For me, most of the real work of a state machine is done in the transitions. When I get the "start" button I start the motor. The "running" state doesn't need to know what is running. But splitting each state into 3 seems workable.

I'd like to se an example of this used for parsing a GPS or user input.

Just compile everything that could be used and let the linker sort out what is used.
Basically what the IDE does.
Compile all files in the sketch folder.
Compile all of the included library files.
Compile all of the core files.
Link the sketch file against all the compiled (object) files.
If something has been used in the sketch it is linked in otherwise it is ignored.

bask185:
Well that is my question, does arduino work in that way?

I will most likely do precisely this.

The reason why we did what we did, had to with git. Some of our teammembers wanted one software project which would be universal for every machine. In some .h file you'd only #define which machine type the machine is, and the right components would be compiled. In this method we would house the software for our entire machinepark in just one git repo. I personally find this a bit 'overkill' and it is likely we will not see through it, but that is a problem for later on and a problem for us :wink:

Yes. Many library files for Arduino code use the #ifdef construct in the .h and .cpp files to decide what to compile. I do it frequently in my main code by defining which processor I am compiling for and use #ifdef in my code. Some of the LED display libraries need the display family defined in the main program to tell the compiler which code to compile.

MorganS:
Copy? Sounds bad. How do you upgrade existing machines when a core file changes?

For me, most of the real work of a state machine is done in the transitions. When I get the "start" button I start the motor. The "running" state doesn't need to know what is running. But splitting each state into 3 seems workable.

I'd like to se an example of this used for parsing a GPS or user input.

I was still looking for a challenge to test me code :slight_smile:

I have developed a special version for the menu structure for our MMIs. The MMIs are merely a simple terminal with an emulated LCD screen and a couple of buttons. In all entry states I can fill in the texts which need to be displayed, in the on states I would read the button presses (serial bytes) from the MMI. For instance, when I would press the 'menu' button, I'd set the exit flag. And a new menu would be selected. All the basic states; 'powerOff', mainMenu, settings, inputs and outputs. Are after code generation 100% workable. All other menu pages can be entered and left but these need filling in to make them functional.

When working with state machine I read a little some some about Mealy and Moore state machines and I found it was completely useless inpractical. It was rather abstract and I could not find any pracitical examples where this theories were coded properly imo. Too many '0's and '1's for my taste. Also the phrase "transition state" I found a bit vague.

I do not do stuff when transitioning between states other than setting some critical flags and a timer. I run an entry state, on state and an exit state. And when that last happened, the state is 'done' or 'finished' and then I select a new state.

I found that the exit state is often not needed, but sometimes it is. One of our machines has 2 loading arms. You can raise or lower them by sending a CAN message and swap them inside or outside by controlling a pneumatic cylinder. You cannot swap the arms outside if they are not in the home position. In this example I would send a CAN message in the entry state, poll it's status during the on state and swap the arms outside in the exit state and set a delay time so the arms have time to reach their outer positions (this particular example is in assembly, but same structure was used). The structure allows for great flexability. I also get to use nested state machines with great ease. These structure is the same and I can let them make use of the same timer of the 'parent's' state machine.

The flow between states is depended on inputs, flags and variables which are most often organized in structs, bitfields or & masks. For the menu state machine I sometimes use the cursorY position to pick a new state. As long as it is readable and simple.

I still want to make modules for interacting with bluetooth devices, lcd displays and handling reading of buttons and sensors.

Much work to do I have

The difference between Mealy and Moore is where you write the outputs: in the state or in the transition. I like the Mealy (transition) method. Obviously you prefer Moore. The two are functionally identical.

Yes, it's difficult for a beginner to grasp the concept of state machines. Most tutorials online are too abstract. The tutorial machine doesn't do anything useful. The best tutorial is Grumpy Mike's but it's still not perfect.

To my mind the biggest obstacle to learning about state machines is the phrase "state machine" because it conjures up a notion of something complex and mystical.

All that it really is is one or more variables that keep track of the progress of a system.

...R