Hi community

I want to ask some doubts about the information given in the link.

https://www.freertos.org/Creating-a-new-FreeRTOS-project.html

Given link says following three source files are common and must be included in your project:

• FreeRTOS/Source/tasks.c
• FreeRTOS/Source/queue.c
• FreeRTOS/Source/list.c

let' say I do not want to make separates file like task.c, list.c and queue.c. just want to keep everything in main.c

#include<rtos.h>
void main(){

}

Now I have only one function that is main.c, so what will be the task, list and queue in main.c file What it would be do. I want to know what all these three things mean in context of simple RTOS design

I have spent a lot of time to understand but still I do not have clear idea What is meaning of task, list and queue in context of RTOS project design.

 

Hi community

I want to ask some doubts about the information given in the link.

https://www.freertos.org/Creating-a-new-FreeRTOS-project.html

Given link says following three source files are common and must be included in your project:

• FreeRTOS/Source/tasks.c
• FreeRTOS/Source/queue.c
• FreeRTOS/Source/list.c

let' say I do not want to make separates file like task.c, list.c and queue.c. just want to keep everything in main.c

#include<rtos.h>
void main(){

}

Now I have only one function that is main.c, so what will be the task, list and queue in main.c file What it would be do. I want to know what all these three things mean in context of simple RTOS design

I have spent a lot of time to understand but still I do not have clear idea What is meaning of task, list and queue in context of RTOS project design.

I do not have intimate knowledge of the RTOS you are working with, but I can talk in general terms about what is going on without getting into specific details.

You will always have only one function that is main.c, and it has nothing really to do with any of the tasks that you might write for your application. Those tasks for your application must be created, managed, and terminated by the functions in tasks.c, list.c, and queue.c In order to do that they must have access to the code that you must write that is the body of your application. In the main function you write a section of code that calls a function in task.c to create a task from a pointer to a function and some data memory that you allocate. Once the task has been created it can be run.

The reason you have three separate files is so that the RTOS code can be maintained. You certainly don't want to have to maintain a single large file, that would be foolish. Once a file, like tasks.c, or queue.c, or list.c, is compiled, the object code can be placed in a library and included as an object file each time you do a build. There is no need to recompile a file that does not change. AFAIK you would have scant motivation to change any of the RTOS files. If they ever do change or are updated, all you have to do is recompile them and update your object library.

 

I do not have intimate knowledge of the RTOS you are working with, but I can talk in general terms about what is going on without getting into specific details.

You will always have only one function that is main.c, and it has nothing really to do with any of the tasks that you might write for your application. Those tasks for your application must be created, managed, and terminated by the functions in tasks.c, list.c, and queue.c In order to do that they must have access to the code that you must write that is the body of your application. In the main function you write a section of code that calls a function in task.c to create a task from a pointer to a function and some data memory that you allocate. Once the task has been created it can be run.

The reason you have three separate files is so that the RTOS code can be maintained. You certainly don't want to have to maintain a single large file, that would be foolish. Once a file, like tasks.c, or queue.c, or list.c, is compiled, the object code can be placed in a library and included as an object file each time you do a build. There is no need to recompile a file that does not change. AFAIK you would have scant motivation to change any of the RTOS files. If they ever do change or are updated, all you have to do is recompile them and update your object library.

I was going to respond, but @Papabravo said it all better than I could have. I’m posting just to agree.

 

I do not have intimate knowledge of the RTOS you are working with, but I can talk in general terms about what is going on without getting into specific details.

Thank you so much, you have explained in simple language. Your work is appreciated. I am not working on any rtos right now but wish to work on rtos so I am reading more and more about it. Really it's a difficult subject. I am Just working on a way to learn it easily for myself. So I first want to know about its structure. And I read in this page that these common file is important in any rtos project

Those tasks for your application must be created, managed, and terminated by the functions in tasks.c, list.c, and queue.c

I think its work of scheduler that decide which one task will run and when it will run. You said that the work of all these files is to create the task, to run the task and to terminate the task.

I know There can be many of tasks What does it mean to create a task in terms of programming I am not writing any code, just asking how do we implement in programming.

 

Thank you so much, you have explained in simple language. Your work is appreciated. I am not working on any rtos right now but wish to work on rtos so I am reading more and more about it. Really it's a difficult subject. I am Just working on a way to learn it easily for myself. So I first want to know about its structure. And I read in this page that these common file is important in any rtos project

I think its work of scheduler that decide which one task will run and when it will run. You said that the work of all these files is to create the task, to run the task and to terminate the task.

I know There can be many of tasks What does it mean to create a task in terms of programming I am not writing any code, just asking how do we implement in programming.

So there will be a function in the file tasks.c whose purpose is to create a task. This function needs certain information in order to perform its purpose. the most important thing it needs is an entry point to a function that can be called when the task is run for the first time. It also needs some additional arguments to tell the RTOS what requirements for system resources may be required. The "Create_Task" will set up the necessary data structures and place the task on the "Ready to Run" list and return. In the normal course of events the task that was just created will be at the front of the "Ready to Run" list or queue and the RTOS will run it until it suspends or is preempted.

 

The simplest OS is no OS:

int main(void)
{
	initialize();
	while(1) {
		process_inputs();
		process_outputs();
	}
	// Never gets here.
	return 0;
}

Somewhat more advanced but light-weight OSs are available (e.g. FreeRTOS and μC/OS) or could be designed which offer task creation and scheduling but with much less overhead than heavier duty types like Linux or VxWorks. The job of the OS is to oversee switching between tasks according to priority and responding to events and semaphores as you the designer have put the pieces together.

void task_func_1(void)
{
	init_some_stuff_1();
	while(1) {
		do_stuff_1();
		block_till_next_time();
	}
}

void task_func_2(void)
{
	init_some_stuff_2();
	while(1) {
		do_stuff_2();
		block_till_next_time();
	}
}

int main()
{
	create_task( task_func_1, PRIORITY_1 );
	create_task( task_func_2, PRIORITY_2 );
	start_scheduler();
	// Probably never returns.
	return 0;
}

Often the scheduler is run based on a timer peripheral of the processor. Simply put, lists of tasks are kept and updated for READY and BLOCKED states. READY tasks are executed based on priority. Tasks are removed from either of the lists and added to the other as needed. Besides invoking each task's function the scheduler will save the outgoing tasks' context (and restore the context of the newly running task). Context will likely consist of the registers which should include the Program Counter, Stack Pointer, etc.

List.c, tasks.c, and queue.c are the FreeRTOS implementations of such a scheme. Note that list.c for example provides a very specific type of list structure used for keeping track of tasks. It's not a generic list structure that you'd likely use for other lists in your application. The queue uses the list structure and is used for keeping track of READY/BLOCKED tasks as well as a semaphore implementation. If I recall correctly. I've used FreeRTOS and μC/OS but I'm not expert level.

 

So there will be a function in the file tasks.c whose purpose is to create a task. This function needs certain information in order to perform its purpose. the most important thing it needs is an entry point to a function that can be called when the task is run for the first time. It also needs some additional arguments to tell the RTOS what requirements for system resources may be required. The "Create_Task" will set up the necessary data structures and place the task on the "Ready to Run" list and return. In the normal course of events the task that was just created will be at the front of the "Ready to Run" list or queue and the RTOS will run it until it suspends or is preempted.

I'm just talking about rtos design, not for specific rtos and coding

What is the easiest way to understand RTOS design?
Which method should i follow Top to bottom or bottom to top

I know that many will give this link https://www.freertos.org/RTOS_ports.html or either will give suggestion to read more about it. that I am already trying But I don't think I am making progress. I think I am not to understanding correctly.

I can understand that everyone has their precious time and this is a big topic And I know it would be difficult to explain it in a forum post. But now the condition is such that there is some big work to be done but I do not understand how to start

 

A semephore is kinda a wierd thing. With interrupts, you need a way to set a single bit from multiple processes that for example, "I want resource x". What if two process want resource x?

One checks the availability of the resource. (initially location is zero) and you check for zero.
Increments that location. (the value might be 1 or 2 ) after incrementing.
Then checks again. If it's 2, it decrements the resource to 1 and waits.

If it's 1, it takes control of the resource, it decrements it to zero when it's done.

A second process can be interrupted via an interrupt in the middle of all of this checking.
BUT, if INC x and Dec x is one machine cycle, it cannot, itself be interrupted.

The semaphore is a "root concept" to any OS design.

Priorites, scheduling and blocking are other concepts.

In a RTOS, your not trying to be fair to everyone? So, processing the speed interupt is more important than reading the speed setpoint. Triggering the PWM is more important than...

Emergency stop overides everything.

All for example.

Displaying the speed?

 

The longest journey begins with a single step. It does not matter where you start, it just matters that you take your time and understand things as you go.