drivers:platform:freeRTOS:Added mem functions

[landas]

Add freeRTOS memory functions for no-OS implementation.

Pull Request Description

Added memory allocation functions for use in freeRTOS platform.

PR Type

• Bug fix (change that fixes an issue)
• New feature (change that adds new functionality)
• Breaking change (has dependencies in other repos or will cause CI to fail)

PR Checklist

• I have followed the Coding style guidelines
• I have performed a self-review of the changes
• I have commented my code, at least hard-to-understand parts
• I have build all projects affected by the changes in this PR
• I have tested in hardware affected projects, at the relevant boards
• I have signed off all commits from this PR
• I have updated the documentation (wiki pages, ReadMe etc), if applies

[buha]

/AzurePipelines run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[buha]

Looks good to me

As a side note, I think freertos.mk should contain something like, perhaps as a separate commit:

SRCS += $(NO-OS)/drivers/platform/freeRTOS/freertos_mutex.c \
        $(NO-OS)/drivers/platform/freeRTOS/freertos_semaphore.c \
        $(NO-OS)/drivers/platform/freeRTOS/freertos_delay.c \
        $(NO-OS)/drivers/platform/freeRTOS/freertos_alloc.c

This would avoid having to specify these in the project .mk files.

[landas]

I was a bit hasty with my pull request. The last commit is compiling without error or warnings with STM32CubeIDE.

[buha]

is the weak linkage specified needed here ? i would argue that this file is THE implementation of no_os_alloc (.c/.h) for freertos platform so it should replace the 3 alloc API functions there (which are specified as weak) with non-weak versions

[buha]

btw, is the weak linkage what changed between your first and 2nd version ?

[landas]

I agree that the weak linkage should be removed, and I have done that in my last commit now.