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

Depends on configSUPPORT_STATIC_ALLOCATION #27

Open
asolochek opened this issue May 9, 2023 · 3 comments
Open

Depends on configSUPPORT_STATIC_ALLOCATION #27

asolochek opened this issue May 9, 2023 · 3 comments

Comments

@asolochek
Copy link

FreeRTOS-Plus-POSIX uses the static versions of semaphore/mutex API functions. These functions only are available if configSUPPORT_STATIC_ALLOCATION is 1. At a minimum this should be listed as a dependency, but ideally this library would work with dynamic allocation as well, as there is a bit of overhead required to use static allocation.

If there is a straightforward way of converting this to use the dynamic versions of the API functions, I'd appreciate learning about that.

@aggarg
Copy link
Member

aggarg commented May 10, 2023

At a minimum this should be listed as a dependency, but ideally this library would work with dynamic allocation as well, as there is a bit of overhead required to use static allocation.

Agree that it should be listed as a dependency. What do you mean by overhead of using static allocation?

If there is a straightforward way of converting this to use the dynamic versions of the API functions, I'd appreciate learning about that.

It would require you to change the implementation of semaphore and mutex. What is your motivation to do that?

Also, what is your motivation of using these wrappers and not using FreeRTOS native APIs directly?

@asolochek
Copy link
Author

The overhead I'm referring to is needing to implement vApplicationGetIdleTaskMemory() and vApplicationGetTimerTaskMemory().

The reason for using posix is because I inherited the project and some components of it run both on the stm32 we are using as well as in some Mac/pc utilities . I guess the previous author thought it would be easier if the threading were portable.

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