[RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch (LinCAN inspired)

[Pavel Pisa]

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 <pisa at 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 <pisa at 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:     pisa at 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