✨ Expose the static task function #204
Conversation
Jerrylum
changed the title
There was a problem hiding this comment.
A couple notes on wrong headers and stuff I don't think we should expose. Your test also only covers tasks, but it really should have 100% coverage over what you're adding. You can also consider adding it/augmenting some of the tests in the test folder as there are some related.
On another note related to decoupling lvgl, this isn't strictly necessary for that. You likely could just use tasks on the heap and it would work fine. I'm not opposed to taking this route though, as there are likely uses for this that I don't know about.
include/pros/apix.h
Outdated
| #define portUSING_MPU_WRAPPERS 0 | ||
| #define configMAX_TASK_NAME_LEN ( 32 ) | ||
| #define portSTACK_GROWTH ( -1 ) | ||
| #define configRECORD_STACK_HIGH_ADDRESS 0 | ||
| #define portCRITICAL_NESTING_IN_TCB 0 | ||
| #define configUSE_TRACE_FACILITY 1 | ||
| #define configUSE_MUTEXES 1 | ||
| #define configUSE_APPLICATION_TASK_TAG 0 | ||
| #define configNUM_THREAD_LOCAL_STORAGE_POINTERS 2 | ||
| #define configGENERATE_RUN_TIME_STATS 1 | ||
| #define configUSE_NEWLIB_REENTRANT 1 | ||
| #define configUSE_TASK_NOTIFICATIONS 1 | ||
| #define configSUPPORT_STATIC_ALLOCATION 1 | ||
| #define configSUPPORT_DYNAMIC_ALLOCATION 1 | ||
| #define INCLUDE_xTaskAbortDelay 1 | ||
| #define configUSE_QUEUE_SETS 0 |
There was a problem hiding this comment.
I don't think these should be exposed to the end user. I think manually evaluating the macros would be best. Also if we change these in the future, it would be a binary breaking change. I don't think it's a big issue, but it's worth mentioning.
There was a problem hiding this comment.
In order to create static_task_s_t, I evaluated the final value for the macros here. Is that what manually evaluating mean or do you what to remove all config macro to the end-user?
There was a problem hiding this comment.
Yea, my thoughts are that these values are implementation details of FreeRTOS, it's micro-controller specific port, and how we've configured it. They really shouldn't be available outside the kernel. In order for that to happen, then, yes, all the config macros will effectively have to be removed in this header. It isn't the best maintenance wise though, so I'm open to other approaches.
There was a problem hiding this comment.
Okay, I removed all the config macros.
Yes, I will change my test code since it is not suitable after commit 5d10690. |
|
The more I think about this, the more conflicted I get. I know I had mentioned wanting to expose static tasks so that we could more easily decouple LVGL from the kernel, but now I don't think we really even need them---a normal task would probably work just as well in this case. Sorry to bring this up after you've done so much work on it already... |
|
I agree with Alex. That, and with how tightly coupled static tasks are with FreeRTOS, I don't really like exposing them. Thanks for looking into it though. Do you have an opinion otherwise Jerrylum, or should this be closed? |
👌 |
Summary:
I was looking at issue #168. Expose the static task function can help us get a foot in the door.
Motivation:
Expose it and 90% of users don't even know what is it.
References (optional):
#168
Test Plan:
Tested 957603f