Into task communication in the sparkfun ESP 32 thing with free articles. In this video we will learn about queues in the ESP 32. Later, we will implement inter task communication with an example project. And finally, we will cover the need in application of queues when handling interrupts. In the last video, we learned about creating tasks and synchronizing them. In many real time systems.

Like the nuclear reactor example, we explained earlier, tasks need to communicate with each other into task communication is necessary for applications where we collect a large amount of data from sensors. In many cases, there will be multiple tasks handling multiple sensors, trying to communicate with the receiver task. The task that receives the data might not be available all the time. It might be busy receiving data from other sensors Thus the sensor reading will get lost. This is why we need a buffer in between the tasks to store the incoming data, so that it can be accessed later. Now, we will implement a small project with our sparkfun ESP 32 thing to teach you how to implement queues in your own project.

In this project, we will create two tasks and a queue. One is the producer task and the other is the consumer task. The producer will collect the sensor readings from the internal Hall Effect sensor and add these values to the end of the queue also known as the tail. The consumer task will read the value from the head of the queue and if the effective magnetic field is too high, the red LED will be on the project circular diagram looks like this. Basically, you have to remove the green LED and its accompanying current limiting resistor from the last project In this project, the Hall Effect sensor task will run on core zero and the LED blinking task will run on core one. A message queue will be created in the ram with a specified size.

There are basically three free Atos functions, you should be familiar to use queues for inter task communication in your projects. They are excu create, excuse send and excu receive the excu create function creates a new queue by using dynamic memory allocation to automatically allocate Ram. This function accepts two parameters. The first parameter is the length of the queue. It determines the maximum number of items the queue can hold. The second parameter is the size in bytes each queue item can hold.

Each item in the queue will be of the same size. They excuse and function We'll post an item at the end of the queue. This function accepts three parameters. The first parameter is the handle to the queue on which the item is to be posted. The second parameter is a pointer to the item that has to be placed on the queue. The final parameter is the maximum amount of time, the task should wait.

If the queue is already full. The execute receive function receives an item from the head of the queue. This function also accepts three parameters. The first parameter is the handle to the queue from which the item has to be received. Next is a pointer to the variable or buffer to which the received item or items will be copied. The final parameter is the maximum amount of time the task should wait for an item to receive if the queue is empty at the time of the call over the Arduino ID and last sensor underscore led underscore q.io no code file from the repository.

First we create two handles for the two tasks. One handle is also created for the queue, we created a variable to set the size of the queue, and also the pin number for the red LED. Inside the setup loop, the only new line of code that got added is this instruction, it creates the queue and assigns it to the queue handle. Here, the size of each item in the queue is set to the size of an integer as the whole sense outputs integer values. Also, don't forget to pin the tasks to separate course. Next, we have the function definitions of the producer task and the consumer task.

Inside the producer task, there is an infinite for loop that reads the whole sensor data and since then, one by one to the queue here, the Val is the pointer to the integer variable named Val. By putting port max underscore delay as a third parameter, the function will wait indefinitely if the queue is full. Inside the consumer task, there is yet another infinite for loop, in which we use the execute receive function. To access the elements stored in the queue, one by one. The sensor values pointer is assigned to the variable element by the end element parameter. Now the sensor value is stored in the variable element.

Later, we use conditional logic to detect the magnetic field the value will go below zero or about 25. If the magnetic field around it is too high, the direction it goes depends on the polarity of the magnetic field. Thus, we use a conditional OR operator to enable or disable the red LED Finally, the word blue is left empty. Now upload the code to the bold and bring a magnet near the ESP 32. You can see that the red LED is on. If you move it away, the LED will become off.

Through this simple example, you were able to implement a very important concept in free Otto's called kills. The concept of queues is very important, especially in applications where we use interrupts. an interrupt is an event that temporarily suspends the main program and passes the control to a special code called the interrupt service routine, also known as Asr, and after that presumes the main program flow where it had left off. Since the ASR doesn't accept any parameters or return values, conventionally, there is no way for our program to share data with the ISF program. For example, when using a keyboard, each keystroke generates an interrupt signal. A keyboard ASR code simply plays the character it reads into a global variable from which the program could read it.

However, this would provide no advantage over software polling. Since the ASR is only moving the data from the receiver data register to another location. It is still necessary for the program to read the character before it is overwritten. But say that the main program is busy with some other task, then this situation will lead to data loss, and some keystrokes entered won't be registered. Using free auto skills softens the requirements on the program to keep up with input. If the ions are places characters in a queue that can hold 25 characters, then 25 characters can be typed.

While the program is busy with other work and no data loss will occur. The program must To keep up with input, but it can check for input much less frequently, as long as it processes all the data in the queue before it overflows. If you want to know more about implementing kills for inter task communication between an ASR and your task, please check out the resources section. Summary. In this video we have covered the following topics queues for inter task communication, implementing queues in a project and queues for interrupt handling. In the next video, we will look at the performance comparison with free Otto's implementation in the ESP 32.