Dear Christian,
On Tuesday 30 of April 2024 08:40:43 Christian MAUDERER wrote:
> > For others, code under review hosted in CTU university GitLab
> > server
> >https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
> > Documentation
> >
> > https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html
> >
> > https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/index.html
> >
> > Main developer behind extension to CAN FD and switch to RTEMS
> > is Michal Lenc.
> >
> > The intention is to (hopefully) reach state when it meets criteria
> > to mainlining int RTEMS CPU kit under
> >
> >cpukit/dev/can
...
> > I agree, that it is compromise. But adding yet another file descriptor
> > like multiplexor for queues to each file descriptor seems to me as
> > too much complexity. But it can be added. even later as IOCTL to remove
> > individual queues based on CAN ID matches or queues IDs if create
> > is modified to return internal queue IDs...
>
> I somehow missed that you can open the device multiple times and get
> independent queues. With that, it's completely OK and should be flexible
> enough for most applications.
>
> It's great that you already have put some thought into how it could be
> extended later if some application needs more flexibility.
...
> >> Did you check with
> >> some other hardware controller, whether the whole structures / defines
> >> / flags close to the hardware do work well for other controllers too?
> >
> > The code/concept is based on my previous LinCAN and OrtCAN work
> >
> > https://ortcan.sourceforge.net/lincan/
...
> I didn't want to doubt your competence. Like I said it's some trap that
> I have fallen into often enough myself (like when guiding Prashanths
> GSoC project). But it's clear that you have put a lot of thought into
> that. So I would expect that there shouldn't be much trouble with most
> controllers. Maybe except for the ones where a semiconductor vendor
> thought it would be a good idea to create a completely different
> concept. But these are always difficult.
I agree with discussion and searching for hard arguments.
The solution is compromise and in general CAN bus concept
is optimized for direct replacement of wires in car
going between distinc units and its use as general
communication solution has some difficulties and requires
some compromises.
For small devices with predefined purpose and Autosar,
it is ideal to allocate for each CAN ID (wire signal)
to be sent one communication object on the controller.
Same for each received signal value or their set in the
single frame. The most controllers are equipped by filters
and mechanism to do so including selection of the
Tx message object for physical bus-link arbitration
according to the priority. Then sending side updates
signal value in corresponding Tx object and receiving
side sees most actual one usually on the best effort basis,
older unread frames are overwritten by updated value.
But even in simple ECU, there are obstacles to use this
principle in all kind of the communication. CAN bus is used
for firmware updates and general configuration. In this
case, the reliable delivery of all messages with given
CAN ID is required because whole sequence has to be
received and processed and the state evolution is associated
to the sequence. If a single message is lost, then all
data are unusable. Because sequence requires exact ordering
it is typical that only single Tx object is used. On Rx
side there can be problem to capture all frames without
overwrite by single Rx object so some controllers ad FIFO
which can be attached to each object or some mechanism
how to allocate more Rx objects and pass them to the user
in FIFO order.
That works for small ECUs with single purpose firmware.
But on general purpose operating system which should
allow even complete monitoring of the CAN bus, allows
dynamically started applications and even whole virtual
CAN/CANopen nodes, allocation the controller Tx/Rx message
objects for each specific purpose is impossible.
That is why all generic CAN subsystems which I know
(CAN4Linux, LinCAN, SockteCAN, NuttX char device CAN,
windows Peak's drivers etc.) define API based on
opening driver and presenting received messages
in FIFO order to application (with options for software
filtering but usually not propagated to controller,
HW - LinCAN has some option to union user FIFOs to
mask and ID propagated to HW, but you usually end with
fully end with need to receve all anyway and it has not been
used at the end). The Tx FIFO order is required for messages
with same ID or even sometimes between same stream of mesages
even wit altering ID for correct realization of some higher
level protocols.
The result is that even on hardware equipped with multiple
Tx objects but without special Tx FIFO order preserving
cyclic queue only single Tx object is used to realize
transmission of all messages, for example SocketCAN on
XCAN controller. So only part of
