KestrelAdrian
commented
1 year ago Also, I don't see how lwgsm defines osThreadId_t.
When compiling lwgsm_ll_stm32.c it throws up an error that osThreadId_t is undefined, I've been through the headers that get included from that file and none of them define that type.
I've tried compiling the example in Stm32CUBEIDE as well and it also throws up the same unknown type for osThreadId_t.
I must be missing something very obvious here, but I cannot currently spot it.
MaJerle
Hi,
I'm just playing with lwgsm at the moment, but while adding lwgwm into an existing project I quickly hit an issue due to paths used in the freeRTOS port.
Your headers include "freertos/freeRTOS.h" (and the same obviously for other freeRTOS related headers and this means you cannot use the freeRTOS kernel directly as a submodule since this is not how the freeRTOS official repository (https://github.com/FreeRTOS/FreeRTOS-Kernel) is laid out.
In order to directly use lwgsm with freertos from github the paths inside the port need to be modified in some manner.
either removing "freertos/" from the include lines and adding the appropriate path to the include folder,
or
by adding "include/" to the includes to match the layout of the freertos kernel repository.
giving either:
or:
the second method imposes a restriction that the submodule needs to be in a folder named "freertos", so it's more restrictive than the first option that allows the user to layout their code in the manner they are accustomed to.
The first option is the better once since it then relies on the user adding the include paths correctly, a name clash with includes is not an issue since if you're already using freertos, you more than likely have the include path to include the freertos includes folder.
You may of course not see this as an issue with the exiting code since it can be fixed locally by modifying lwgsm, but it seems to me that it would be useful to have compatabilitywith freertos as a submodule "out of the box".