Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Something wrong in part 6 (Mutex demo) #6

Open
m3y54m opened this issue Nov 20, 2022 · 1 comment
Open

Something wrong in part 6 (Mutex demo) #6

m3y54m opened this issue Nov 20, 2022 · 1 comment

Comments

@m3y54m
Copy link

m3y54m commented Nov 20, 2022

Hello,
First of all, thank you for this great course.
I'm currently following the course and trying to write and test all the demos and challenges.

In part 6 where you talk about Mutex, I noticed that there is something wrong and only one of the tasks is executed, and the other task is completely blocked and never executed.

I found out this problem by adding these lines before Serial.println(shared_var); line in esp32-freertos-06-demo-mutex.ino.

The function pcTaskGetName(NULL) returns the pcName of the task.

      Serial.print(pcTaskGetName(NULL));
      Serial.print(" : ");
      Serial.println(shared_var);

This is the resulting output:

image

I still don't know why only one task is running. Maybe it has something to do with ‍‍xBlockTime or something else.

@ChrisVeigl
Copy link

I think the problem is that task1 immediately takes the mutex again after releasing it, as there is no blocking wait or other chance for the scheduler to let task2 run. The situation can be improved by introducing a small vTaskDelay() or by calling taskYield() after giving the the mutex.

BTW: the length of the taskname string parameter should be reduced to fit the default size limit of 16 bytes (including '\0').

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants