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

FreeRTOS linux port and GoogleTest #45

Closed
marcobergamin opened this issue Jul 30, 2020 · 6 comments
Closed

FreeRTOS linux port and GoogleTest #45

marcobergamin opened this issue Jul 30, 2020 · 6 comments

Comments

@marcobergamin
Copy link

Hello,

I have added your posix port to my codebase because I wanted to do some TDD using GoogleTest.
The first test runs just fine: at the end of the unit tests I can destroy all my tasks and call vTaskEndSheduler().

The problem is that vTaskEndSheduler(), beside stopping the scheduler, it also destroys some variables statically initialized (a pair of mutexes and something else). I've tried to add a new function to initialize again the static variables declared in port.c with the idea of calling it at the beginning of each unit test, without success.

As workaround I could use the GoogleTest --filter functionality to execute each test in a dedicated process, but I don't like this option a lot.

Any idea?

Thanks,
Marco

@matt-duke
Copy link

I am interesting in using this project in the same way - testing a FreeRTOS codebase on Linux using the port. Did you find a solution to this issue?

@michaelbecker
Copy link
Owner

There was an extensive conversation regarding vTaskEndScheduler() a while back. The summary is that this is a limitation of FreeRTOS itself. FreeRTOS never really expects that vTaskEndScheduler() will actually be called, which makes sense if you've ever coded a small embedded system.

Reference:
#14 (comment)

@marcobergamin
Copy link
Author

I am interesting in using this project in the same way - testing a FreeRTOS codebase on Linux using the port. Did you find a solution to this issue?

I actually have found a solution. Here the code:
https://gist.github.com/marcobergamin/2e77003e7efa2a891a6726b14e8c61fe

Please note that I have just manually copied the code from an offline machine, it could contains typos (if you find them, please leave a comment).

I have built that "alternative" gtest_main for FreeRTOS based on a discussion thread I had found online (unfortunately I have lost the link to the discussion).

I can tell you that with the latest GCC/Posix port it works very well IF:

  1. you don't create threads not managed by the FreeRTOS scheduler (in other words: use only vTaskCreate).
  2. you close all the tasks created inside a unit test at its end.

Link to the POSIX port I am using:
https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/main/portable/ThirdParty/GCC/Posix

@matt-duke
Copy link

matt-duke commented Jan 20, 2022

Thanks Marco, that looks very promising! Only 2 typos: <cstint> should be <cstdint> on line 8 and gtest_main function should be renamed gtest_task.
I like your approach here. I was originally planning to start and stop FreeRTOS in the setup and teardown of each test case, but it looks like this takes a slightly different approach where the scheduler runs for the entire test suite. For my purposes, that should be ok.

@marcobergamin
Copy link
Author

@matt-duke I'm very sorry for the late answer, I've completely forgot to answer your message. First of all thanks for pointing out those typos, I've fixed the gist.
Does this solution work well for you so far?

@michaelbecker
Copy link
Owner

Closing because this is not a FreeRTOS add-on issue. This is a known issue with FreeRTOS itself.

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

3 participants