Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation
Hello Pavel,
it's quite a big work. So I've started to read through the
documentation to get an overview. Some questions:
Do I understand that correctly, that the only user-facing interface is
via the "/dev/can*" files. There is no separate interface for special
operations, right? That's completely OK for me. I just want to make
sure that I understand it correctly.
Chapter "1.1.1.1: Managing Queues": I assume the limitation that
RTEMS_CAN_DISCARD_QUEUES removes all queues and not only selected ones
is a limitation due to the nature of the ioctl interface or the driver
capabilities? It could be a bit of an annoying limitation in an
application that dynamically wants to register or unregister queues.
Chapter "1.1.1.3: Setting Mode": These look quite controller specific.
If I want to add a controller that has a new mode: Would I just add a
new flag? What happens if we reach 33 flags? Would an array or maybe a
structure with a single uint32_t field be a better choice? I assume
that if a controller doesn't support a mode, (like setting FD on a
non-FD controller), the IOCTL will just return an error?
Chapter "1.1.3: Frame Transmission" and "1.1.4: Frame Reception": The
last argument of "write" is a count. If I see a write, my first guess
is that I have to call it like:
struct can_frame frames[10] = {... /* some values */ ...};
ssize_t rv = write( fd, frames, sizeof(frames) );
But from taking a look at the tests in the repository, the count
is calculated by can_framelen(). Is it possible to send or receive
multiple CAN frames using write or read? Or is it always a single
frame? What happens if I pass a wrong length? Do I send wrong data,
crash the system or the whole CAN bus or do I just get an error? Can
you make that more clear in the documentation?
Some details regarding "struct can_chip":
* There is a pointer called "type". I would use a "const char *" for
that. I expect that stuff like names will never change and having
them constant allows to use a pointer to a flash memory area.
* You have an "int irq". That's not fully compatible to the
rtems_vector_number which is an uint32_t (at the moment).
Regarding the CAN drivers: Do I see it correctly, that currently only
a single (real) device is supported (ctucanfd)? 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?
Like the mode flags from 1.1.1.3. It doesn't really matter which other
controller. From my own attempts to write a driver stack, I just know
that sometimes you make assumptions based on one controller that are
hard to implement on another one. Usually it's not even necessary to
really add a second controller. Just skimming through the manual can
be really helpful. On the other hand, the Doxygen documentation
mentions, that the concept is based on LinCAN. So maybe that already
helps to avoid that trap?
Regarding the device names "/dev/can0" and similar: Currently that
seems to be a fixed scheme, correct? In my experience, sometimes it
can be useful to use longer names instead. For example
"/dev/can_ctufd0". That's especially interesting if a system is
initialized dynamically. For example if you have a USB to CAN adapter
that is enumerated more or less randomly during startup. Is that
supported or are there some fixed assumptions that a can device is
always called "/dev/canX"?
Best regards
Christian
On 2024-04-27 11:53, Pavel Pisa wrote:
Dear RTEMS and CAN community,
I want to report another update in Michal Lenc work
on the generic CAN/CAN FD RTEMS stack.
The Sphinx and Doxygen documentation is generated by CI
on our faculty GitLab server. Links to RTEMS CAN resources
in the section
CAN/CAN FD Subsystem and Drivers for RTEMS
https://canbus.pages.fel.cvut.cz/#cancan-fd-subsystem-and-drivers-for-rtems
Repository https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
Manual
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html
Doxygen
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/index.html
CAN/CAN FD frame and header described there
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/structcan__frame.html
Feedback from everybody is welcomed. It would be especially
welcomed if Oliver has some remarks to can_frame_header
and can_frame field names because changes of these
start to be more painfull when/if project is accepted
into RTEMS mainline. Oliver is not probably on RTEMS
list, but I would forward reply there if it will not pass.
I have done initial update of our CAN/CANopen
framework from2003 year to be prepared to work with
new RTEMS solution. Only classic CAN frames for now,
FD is ignored
https://ortcan.sourceforge.net/
https://sourceforge.net/p/ortcan/ortcan-vca/commit_browser
Best wishes,
Pavel
--
Pavel Pisa
phone: +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of
Re: GCC 14: m68k, sh, and sparc64
On Sun, Apr 28, 2024 at 3:18 PM Joel Sherrill wrote: > > > On Sun, Apr 28, 2024 at 6:17 AM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> Hello, >> >> the m68k, sh, and sparc64 build fails with GCC 14 due to: >> > > Two of those are scheduled to be removed after we branch 6. > > So only the m68k really matters. More below. > >> >> make "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2 -m4-single-only" "CCASFLAGS=-g >> -O2 -m4-single-only" "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=" >> "INSTALL=/usr/bin/install -c" "LDFLAGS=-m4-single-only" >> "LIBCFLAGS=-m4-single-only" "LIBCFLAGS_FOR_TARGET=" "MAKE=make" >> "MAKEINFO=makeinfo --split-size=500" "PICFLAG=" >> "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest" >> "RUNTESTFLAGS=" "exec_prefix=/tmp/sh/i-sh-rtems6" >> "infodir=/tmp/sh/i-sh-rtems6/share/info" >> "libdir=/tmp/sh/i-sh-rtems6/lib" "prefix=/tmp/sh/i-sh-rtems6" >> "tooldir=/tmp/sh/i-sh-rtems6/sh-rtems6" >> "top_toollibdir=/tmp/sh/i-sh-rtems6/sh-rtems6/lib/m4-single-only" >> "AR=/tmp/sh/i-sh-rtems6/sh-rtems6/bin/ar" "AS=as" >> "CC=/tmp/sh/b-gcc-sh-rtems6/./gcc/xgcc -B/tmp/sh/b-gcc-sh-rtems6/./gcc/ >> -nostdinc -B/tmp/sh/b-gcc-sh-rtems6/sh-rtems6/m4-single-only/newlib/ >> -isystem >> /tmp/sh/b-gcc-sh-rtems6/sh-rtems6/m4-single-only/newlib/targ-include >> -isystem /home/EB/sebastian_h/src/gcc/newlib/libc/include >> -B/tmp/sh/i-sh-rtems6/sh-rtems6/bin/ >> -B/tmp/sh/i-sh-rtems6/sh-rtems6/lib/ -isystem >> /tmp/sh/i-sh-rtems6/sh-rtems6/include -isystem >> /tmp/sh/i-sh-rtems6/sh-rtems6/sys-include -m4-single-only" "LD=ld" >> "LIBCFLAGS=-m4-single-only" "NM=" "PICFLAG=" >> "RANLIB=/tmp/sh/i-sh-rtems6/sh-rtems6/bin/ranlib" "DESTDIR=" all-am >> make[4]: Entering directory >> '/tmp/sh/b-gcc-sh-rtems6/sh-rtems6/m4-single-only/newlib' >>CC libm/complex/libm_a-ccoshl.o >> /home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c: In function >> 'ccoshl': >> /home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c:43:13: error: >> implicit declaration of function 'coshl'; did you mean 'coshf'? >> [-Wimplicit-function-declaration] >> 43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I; >>| ^ >>| coshf >> /home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c:43:24: error: >> implicit declaration of function 'cosl'; did you mean 'cosf'? >> [-Wimplicit-function-declaration] >> 43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I; >>|^~~~ >>|cosf >> /home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c:43:35: error: >> implicit declaration of function 'sinhl'; did you mean 'sinhf'? >> [-Wimplicit-function-declaration] >> 43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I; >>| ^ >>| sinhf >> /home/EB/sebastian_h/src/gcc/newlib/libm/complex/ccoshl.c:43:46: error: >> implicit declaration of function 'sinl'; did you mean 'sinf'? >> [-Wimplicit-function-declaration] >> 43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I; >>| ^~~~ >>| sinf >> make[4]: *** [Makefile:43178: libm/complex/libm_a-ccoshl.o] Error 1 >> >> Implicit function declarations are an error by default in GCC 14. Joel, >> could you please have a look at the long double support in Newlib since >> you worked with it some time ago. >> > > Looks like a file that probably should be disabled on targets without > long double support. I'll try to dig into it. > I have a build with a gcc version that has this as a warning but duplicates the underlying issue. I'll see what I can do. > > Please file an RSB issue once we get to gitlab. I think that's where these > type of issues go now since it is gcc. > >> >> -- >> embedded brains GmbH & Co. KG >> Herr Sebastian HUBER >> Dornierstr. 4 >> 82178 Puchheim >> Germany >> email: sebastian.hu...@embedded-brains.de >> phone: +49-89-18 94 741 - 16 >> fax: +49-89-18 94 741 - 08 >> >> Registergericht: Amtsgericht München >> Registernummer: HRB 157899 >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler >> Unsere Datenschutzerklärung finden Sie hier: >> https://embedded-brains.de/datenschutzerklaerung/ >> > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation
Dear Christian,
thanks a lot for finding time to read through documentation.
On Monday 29 of April 2024 10:56:29 Christian MAUDERER wrote:
> it's quite a big work. So I've started to read through the
> documentation to get an overview.
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
We plan to prefix all public functions by rtems_ prefix as the
final step after review and acceptance for mainline to not
pollute applications namespace. User visible structures
types for IOCTLs and farmes are planned to stay without
prefix for readability. They can be hidden by not including
given header file.
> Some questions:
> Do I understand that correctly, that the only user-facing interface is
> via the "/dev/can*" files. There is no separate interface for special
> operations, right? That's completely OK for me. I just want to make
> sure that I understand it correctly.
Yes, it is the goal to use only character device as the only intreface
to the user application. LinCAN worked in standard POSIX environment
with MMU etc. and even on RTEMS we consider user and kernel
space as fully separated and only read, write, IOCTL exchange
data controlled way.
There are more functions which are intended for drivers developers
and for registration from BSP.
> Chapter "1.1.1.1: Managing Queues": I assume the limitation that
> RTEMS_CAN_DISCARD_QUEUES removes all queues and not only selected ones
> is a limitation due to the nature of the ioctl interface or the driver
> capabilities? It could be a bit of an annoying limitation in an
> application that dynamically wants to register or unregister queues.
The single chip can be opened multiple times, each open instance
created their own canque_ends_user_t
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/structcanque__ends__user__t.html
This structure allows to connect FIFO queues (canque_edge_t) at any time
in any direction including echo to itself or some intermediate node
to send messages to more links for redundancy etc.
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/structcanque__edge__t.html
That is internal implementation which is intended to be really flexible
and with minimal locking intervals - only during move to next queue
during iterations.
But we are trying to keep external interface reasonably simple, so we consider
only queues from single user (file-descriptor) to single chip corresponding
to /dev/can during chosen during open for now.
The rationale for discard all only is that we if we allow manipulation of
individual queues we cannot identify queues by pointers. We take as forbidden
to expose kernel pointer addresses of canque_edge_t. It can be resolved
by assigning some unique numbers for each edge created from given user
ends and returning these to user from RTEMS_CAN_CREATE_QUEUE. The initial
default connection can have ID 0. Then it would be easy iterate over
all queues going to/from given user and remove only that queue where
the specified ID matches. Other option is to limit which queues will
be removed based on CAN ID and mask... but there can be problem to uniquely
match such queue etc...
So the compromise is taken. You can remove all queues to given open instance
and then add queues one by one as you want with controlled CAN ID
filters and priority.
If you need to create dynamically some application which needs specific
CAN IDs and priorities and then you expect that it should not interact
with network any more, then you can open /dev/canX again and you have
private queues pool. When the file representation is closed then all
these queues will be removed. That all without any influence
to other open instances to same or other CAN device {if we do not
consider system load).
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...
> Chapter "1.1.1.3: Setting Mode": These look quite controller specific.
> If I want to add a controller that has a new mode: Would I just add a
> new flag? What happens if we reach 33 flags? Would an array or maybe a
> structure with a single uint32_t field be a better choice? I assume
> that if a controller doesn't support a mode, (like setting FD on a
> non-FD controller), the IOCTL will just return an error?
I hope that these modes should be mostly controller inde
Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation
Hello Christian,
thank you a lot for the review. In addition to Pavel Píša's reply, I
have updated the documentation to provide (hopefully) a better description.
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html
I plan to enhance it further, I write it in parallel with my diploma
thesis at the moment and sometimes I have the text already written in
one document and not in the other one. So thank you for pointing out the
parts where the description was not clear. I will address the changes in
can_chip structure later this week.
Regarding future CAN controllers, I hope we will find some time and
resources for the implementation of SJA1000 controller to our stack.
Another interesting controller from our side would be MCAN since we have
some projects with SAMv7 MCU. But those are more long term goals.
Thank you again for your input.
Best regards,
Michal Lenc
On 29. 04. 24 10:56, Christian MAUDERER wrote:
Hello Pavel,
it's quite a big work. So I've started to read through the
documentation to get an overview. Some questions:
Do I understand that correctly, that the only user-facing interface is
via the "/dev/can*" files. There is no separate interface for special
operations, right? That's completely OK for me. I just want to make
sure that I understand it correctly.
Chapter "1.1.1.1: Managing Queues": I assume the limitation that
RTEMS_CAN_DISCARD_QUEUES removes all queues and not only selected ones
is a limitation due to the nature of the ioctl interface or the driver
capabilities? It could be a bit of an annoying limitation in an
application that dynamically wants to register or unregister queues.
Chapter "1.1.1.3: Setting Mode": These look quite controller specific.
If I want to add a controller that has a new mode: Would I just add a
new flag? What happens if we reach 33 flags? Would an array or maybe a
structure with a single uint32_t field be a better choice? I assume
that if a controller doesn't support a mode, (like setting FD on a
non-FD controller), the IOCTL will just return an error?
Chapter "1.1.3: Frame Transmission" and "1.1.4: Frame Reception": The
last argument of "write" is a count. If I see a write, my first guess
is that I have to call it like:
struct can_frame frames[10] = {... /* some values */ ...};
ssize_t rv = write( fd, frames, sizeof(frames) );
But from taking a look at the tests in the repository, the count
is calculated by can_framelen(). Is it possible to send or receive
multiple CAN frames using write or read? Or is it always a single
frame? What happens if I pass a wrong length? Do I send wrong data,
crash the system or the whole CAN bus or do I just get an error? Can
you make that more clear in the documentation?
Some details regarding "struct can_chip":
* There is a pointer called "type". I would use a "const char *" for
that. I expect that stuff like names will never change and having
them constant allows to use a pointer to a flash memory area.
* You have an "int irq". That's not fully compatible to the
rtems_vector_number which is an uint32_t (at the moment).
Regarding the CAN drivers: Do I see it correctly, that currently only
a single (real) device is supported (ctucanfd)? 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?
Like the mode flags from 1.1.1.3. It doesn't really matter which other
controller. From my own attempts to write a driver stack, I just know
that sometimes you make assumptions based on one controller that are
hard to implement on another one. Usually it's not even necessary to
really add a second controller. Just skimming through the manual can
be really helpful. On the other hand, the Doxygen documentation
mentions, that the concept is based on LinCAN. So maybe that already
helps to avoid that trap?
Regarding the device names "/dev/can0" and similar: Currently that
seems to be a fixed scheme, correct? In my experience, sometimes it
can be useful to use longer names instead. For example
"/dev/can_ctufd0". That's especially interesting if a system is
initialized dynamically. For example if you have a USB to CAN adapter
that is enumerated more or less randomly during startup. Is that
supported or are there some fixed assumptions that a can device is
always called "/dev/canX"?
Best regards
Christian
On 2024-04-27 11:53, Pavel Pisa wrote:
Dear RTEMS and CAN community,
I want to report another update in Michal Lenc work
on the generic CAN/CAN FD RTEMS stack.
The Sphinx and Doxygen documentation is generated by CI
on our faculty GitLab server. Links to RTEMS CAN resources
in the section
CAN/CAN FD Subsystem and Drivers for RTEMS
https://canbus.pages.fel.cvut.cz/#cancan-fd-subsystem-and-drivers-for-rtems
Repository https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
Manual
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html
Doxygen
https://o
Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation
Hello Pavel,
thanks for your explanations.
On 2024-04-29 21:23, Pavel Pisa wrote:
Dear Christian,
thanks a lot for finding time to read through documentation.
On Monday 29 of April 2024 10:56:29 Christian MAUDERER wrote:
it's quite a big work. So I've started to read through the
documentation to get an overview.
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
We plan to prefix all public functions by rtems_ prefix as the
final step after review and acceptance for mainline to not
pollute applications namespace. User visible structures
types for IOCTLs and farmes are planned to stay without
prefix for readability. They can be hidden by not including
given header file.
Some questions:
Do I understand that correctly, that the only user-facing interface is
via the "/dev/can*" files. There is no separate interface for special
operations, right? That's completely OK for me. I just want to make
sure that I understand it correctly.
Yes, it is the goal to use only character device as the only intreface
to the user application. LinCAN worked in standard POSIX environment
with MMU etc. and even on RTEMS we consider user and kernel
space as fully separated and only read, write, IOCTL exchange
data controlled way.
OK. That's reasonable.
There are more functions which are intended for drivers developers
and for registration from BSP.
I noted that the driver developer has a different interface.
Chapter "1.1.1.1: Managing Queues": I assume the limitation that
RTEMS_CAN_DISCARD_QUEUES removes all queues and not only selected ones
is a limitation due to the nature of the ioctl interface or the driver
capabilities? It could be a bit of an annoying limitation in an
application that dynamically wants to register or unregister queues.
The single chip can be opened multiple times, each open instance
created their own canque_ends_user_t
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/structcanque__ends__user__t.html
This structure allows to connect FIFO queues (canque_edge_t) at any time
in any direction including echo to itself or some intermediate node
to send messages to more links for redundancy etc.
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/structcanque__edge__t.html
That is internal implementation which is intended to be really flexible
and with minimal locking intervals - only during move to next queue
during iterations.
But we are trying to keep external interface reasonably simple, so we consider
only queues from single user (file-descriptor) to single chip corresponding
to /dev/can during chosen during open for now.
The rationale for discard all only is that we if we allow manipulation of
individual queues we cannot identify queues by pointers. We take as forbidden
to expose kernel pointer addresses of canque_edge_t. It can be resolved
by assigning some unique numbers for each edge created from given user
ends and returning these to user from RTEMS_CAN_CREATE_QUEUE. The initial
default connection can have ID 0. Then it would be easy iterate over
all queues going to/from given user and remove only that queue where
the specified ID matches. Other option is to limit which queues will
be removed based on CAN ID and mask... but there can be problem to uniquely
match such queue etc...
So the compromise is taken. You can remove all queues to given open instance
and then add queues one by one as you want with controlled CAN ID
filters and priority.
If you need to create dynamically some application which needs specific
CAN IDs and priorities and then you expect that it should not interact
with network any more, then you can open /dev/canX again and you have
private queues pool. When the file representation is closed then all
these queues will be removed. That all without any influence
to other open instances to same or other CAN device {if we do not
consider system load).
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.
Ch
Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation
Hello Michal,
On 2024-04-29 22:48, Michal Lenc wrote:
Hello Christian,
thank you a lot for the review.
Thank you for your work.
In addition to Pavel Píša's reply, I
have updated the documentation to provide (hopefully) a better description.
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html
Thank you. I did take a look on some of the sections where I had some
open questions, and it's already much clearer now.
I plan to enhance it further, I write it in parallel with my diploma
thesis at the moment and sometimes I have the text already written in
one document and not in the other one. So thank you for pointing out the
parts where the description was not clear. I will address the changes in
can_chip structure later this week.
Take your time.
Regarding future CAN controllers, I hope we will find some time and
resources for the implementation of SJA1000 controller to our stack.
Another interesting controller from our side would be MCAN since we have
some projects with SAMv7 MCU. But those are more long term goals.
If that's the SAMV71 or SAME70 family: Be very careful with that
controller and take a very thorough look at the Errata before you plan
to use it in some productive system. It has some really horrible bugs.
The worst ones that I encountered was that
1. I couldn't use SDRAM and USB at the same time because the SDRAM added
a lot of jitter to the USB PLL.
2. Sometimes a conditioned branch instruction did take the wrong path (I
verified the whole register values and assembly code multiple times
before believing that it really happened).
I followed the errata quite some time. First there were more and more
bugs related to SDRAM. Finally, Microchip just told that you should not
use the SDRAM at all and removed the SDRAM chapter from the reference
manual.
Of course, you can use the chip. But again: I would strongly recommend
taking a really detailed look at the errata sheets for all peripherals
that you plan to use.
Best regards
Christian
Thank you again for your input.
Best regards,
Michal Lenc
On 29. 04. 24 10:56, Christian MAUDERER wrote:
Hello Pavel,
it's quite a big work. So I've started to read through the
documentation to get an overview. Some questions:
Do I understand that correctly, that the only user-facing interface is
via the "/dev/can*" files. There is no separate interface for special
operations, right? That's completely OK for me. I just want to make
sure that I understand it correctly.
Chapter "1.1.1.1: Managing Queues": I assume the limitation that
RTEMS_CAN_DISCARD_QUEUES removes all queues and not only selected ones
is a limitation due to the nature of the ioctl interface or the driver
capabilities? It could be a bit of an annoying limitation in an
application that dynamically wants to register or unregister queues.
Chapter "1.1.1.3: Setting Mode": These look quite controller specific.
If I want to add a controller that has a new mode: Would I just add a
new flag? What happens if we reach 33 flags? Would an array or maybe a
structure with a single uint32_t field be a better choice? I assume
that if a controller doesn't support a mode, (like setting FD on a
non-FD controller), the IOCTL will just return an error?
Chapter "1.1.3: Frame Transmission" and "1.1.4: Frame Reception": The
last argument of "write" is a count. If I see a write, my first guess
is that I have to call it like:
struct can_frame frames[10] = {... /* some values */ ...};
ssize_t rv = write( fd, frames, sizeof(frames) );
But from taking a look at the tests in the repository, the count
is calculated by can_framelen(). Is it possible to send or receive
multiple CAN frames using write or read? Or is it always a single
frame? What happens if I pass a wrong length? Do I send wrong data,
crash the system or the whole CAN bus or do I just get an error? Can
you make that more clear in the documentation?
Some details regarding "struct can_chip":
* There is a pointer called "type". I would use a "const char *" for
that. I expect that stuff like names will never change and having
them constant allows to use a pointer to a flash memory area.
* You have an "int irq". That's not fully compatible to the
rtems_vector_number which is an uint32_t (at the moment).
Regarding the CAN drivers: Do I see it correctly, that currently only
a single (real) device is supported (ctucanfd)? 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?
Like the mode flags from 1.1.1.3. It doesn't really matter which other
controller. From my own attempts to write a driver stack, I just know
that sometimes you make assumptions based on one controller that are
hard to implement on another one. Usually it's not even necessary to
really add a second controller. Just skimming through the manual can
be really helpful. On the other hand, the Doxygen do
Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation
Hi, > OK. Maybe then it would be good to make some notes in which cases it's > OK to add another flag to avoid that someone adds a lot of hardware > dependent flags here. Yes, we will add the description. Thanks. > I assume if something is really very special to a specific hardware, > the driver should get an extra driver specific IOCTL for that, right? Yes, this is already implemented, although not used for CTU CAN FD at the moment. IOCTL calls not recognized by common layer in can-bus.c are passed to the driver (if driver implements this functionality, otherwise -EINVAL is returned immediately). So it is possible for driver to have specific IOCTL calls. Best regards, Michal ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
