-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
feat(nxp/pxp): add Zephyr Support #6298
base: master
Are you sure you want to change the base?
Conversation
#include "FreeRTOS.h" | ||
#include "semphr.h" | ||
|
||
#if defined(__ZEPHYR__) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those should not be included - they will get over lv_os.h inclusion
NVIC_SetPriority(PXP_IRQ_ID, configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 1); | ||
NVIC_EnableIRQ(PXP_IRQ_ID); | ||
#elif defined(__ZEPHYR__) | ||
IRQ_CONNECT(DT_IRQN(DT_NODELABEL(pxp)), CONFIG_LV_Z_PXP_INTERRUPT_PRIORITY, PXP_ZephyrIRQHandler, NULL, 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand now, you included the ZEPHYR header just for this CONFIG_LV_Z_PXP_INTERRUPT_PRIORITY
.
We should not mix any longer this with lv_osal support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The includes are needed for the entire interrupt logic (retrieving nodes from DT, hooking up the IRQ).
I have a problem with the code above. It is not exactly OSAL as it claims and it also breaks our build. There has to be a better way |
Yeah, these includes are needed for the interrupts. Personally I think that an OSAL is maybe not the right place for an abstraction for this, the OSAL should be kept as thin as possible. Maybe it would be an option somehow provide the user a way to give LVGL a |
Add semaphore and connect IRQ. Originally proposed by @0xFarahFl.
e339205
to
cb4c167
Compare
We got a lot request about updating Zephyr to LVGL v9 so I wonder if we can help to make it happen soon. @becseya is interested in Zephyr, so he can help with LVGL related issues. We also have several NXP boards so we can help with PXP as well. |
0f12024
to
083a95b
Compare
Please add |
The function var had to be renamed to |
Which one? 🙂 |
The last version of these patches fix the build regression I was looking at (PXP = 1 , OS_NONE on MCUXpresso SDK projects that always define SDK_OS_FREE_RTOS). There are other improvements that could be made but they can be addressed later. |
Please add |
@kisvegabor added it to |
Thanks, I've fixed the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice atomic CAS loop!
In another PR we should correct the implementation of lv_mutex_lock_isr
for cmsis_rtos2. See this comment.
#if defined(__ZEPHYR__) | ||
static void PXP_ZephyrIRQHandler(void *) | ||
{ | ||
PXP_IRQHandler(); | ||
} | ||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please put this in the static functions section and forward declare it. Maybe also change the name to make it seem less like a platform specific global function definition (unless it is).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah it kinda is - I do not know how many other RTOS give the possibility to add userdata to an ISR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I mean is the name implies that it's overriding a weak
definition in the OS like a systick handler that gets called by the OS, but it's really just a local function.
Also, does PXP_IRQHandler
need to be global? Does it get called by anything external?
src/osal/lv_freertos.c
Outdated
/* Acquire the mutex. */ | ||
if(pdFALSE == xSemaphoreTakeFromISR(pxCond->xSyncMutex, NULL)) { | ||
return LV_RESULT_INVALID; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this fails because lv_thread_sync_wait
has the mutex, will the signal never be sent and a deadlock would occur?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True - what would be the best solution for this? Not using the mutex at all and disabling interrupts instead so we can not be preempted by another ISR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my last commit, if the change is ok from your side, I'll squash it :^)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think that should work, nice. Is the CAS loop no longer needed now?
Changes the PXP osal to use the thread_sync to signal PXP readyness from the ISR.
Description of the feature or fix
Reopening of #6159 since it got merged and reverted the original PR does not track changes anymore (@nicusorcitu ).
Notes
lv_conf_template.h
run lv_conf_internal_gen.py and update Kconfig.scripts/code-format.py
(astyle version v3.4.12 needs to be installed) and follow the Code Conventions.