Hello Gedare, thanks for feedback.
On Tuesday 05 of March 2024 22:54:35 Gedare Bloom wrote: > On Thu, Feb 29, 2024 at 6:40 AM Pavel Pisa <p...@fel.cvut.cz> wrote: > > On Tuesday 27 of February 2024 22:27:43 Gedare Bloom wrote: > > > On Mon, Feb 12, 2024 at 8:03 AM Pavel Pisa <p...@fel.cvut.cz> wrote: > > > > > > > > https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd > > > > > On a quick review, my recommendation would be to switch to using the > rtems_mutex mechanism of the self-contained objects, see > https://docs.rtems.org/branches/master/c-user/self_contained_objects.html > > I believe this will be a more suitable solution than the more general > interrupt lock. It should be relatively straightforward to implement > this replacement for both the qends and the fifo structures. Each may > embed its own rtems_mutex. I see you already use a > rtems_mutex_recursive to protect the can_bus structure. I would avoid > a design that allows recursive access if possible. I did not see if > you acquire the lock during interrupt service routines. > > Since you have the interrupt_lock mechanism implemented, may be it > would be a nice experiment to evaluate the performance vs the > self-contained rtems_mutex. I agree with switch to self-contained rtems_mutex_lock and probably we try even rtems_binary_semaphore_post for notification. In the fact, this was my question in RFC whether consider self-contained objects for synchronization. By switch of queues protection to mutexes, we lose option to fill it directly from interrupt and implement driver Rx and Tx in interrupts. This could be problem on very slow targets with really short Rx FIFO. But that is not case of CTU CAN FD and even SJA1000 has 128 bytes HW FIFO. The code locking by interrupt disable is for really short time, so it should not be a problem. But we have decided to use chip dedicated thread on RTEMS from start to allow its priority setup even somewhere in middle to allow if there are even some more timing critical tasks running. On Linux kernel, we have used interrupt disabling spinlock to allow write LinCAN Rx and Tx handles directly in interrupt service routine. But that locking mechanism automatically switches to priority aware RT mutexes on the fully preemptive kernel. Anyway, we switch to rtems_mutex_lock on RTEMS, it makes code even simpler and do timing before and after switch ho have idea about behavior on Zynq target (which falls into middle or lower performance range today so it is appropriate for assessment if overhead is significant). Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa social: https://social.kernel.org/ppisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ RISC-V education: https://comparch.edu.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel