This commit adds support for CTU CAN FD controller. The controller
can be initialized from BSP by ctucanfd_initialize() function call.
It also implements the dynamic redistribution of hardware transmission
buffers to CAN stack priority classes in order to avoid possible
priority inversion.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
Co-authored-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
This commit adds a support for a simple virtual CAN controller. This
controller can be used to test CAN stack functions and serves as an
inspiration for further controller implementations.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
Co-authored-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
This adds support for common full-featured CAN/CAN FD stack to RTEMS.
The API is provided in form the form of the POSIX character driver with
each CAN controller (chip) registered as node into “/dev”
namespace.
The stack utilizes FIFO queues (also called edges) organized
into oriented edges between controller side and application side.
Edges, responsible for message transfers from application to controller
and vice versa, can have different priorities and function as priority
classes.
The stack provides run time configuration options to create new
queues with desired priority, direction and filter, making it
suitable for various applications requirements. There is also a
possibility to configure controller’s characteristics (bit rate,
mode, chip specific ioctl calls). Both blocking and nonblocking mode
is supported.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
Co-authored-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
This adds the possibility to open an I2C bus with O_NONBLOCK (or set it
later via fcntl) to get non-blocking transmissions. This means that if
the bus is busy, a read, write or transfer ioctl will return with a
EAGAIN errno.
A speciality of the RTEMS build system was the make preinstall step. It
copied header files from arbitrary locations into the build tree. The
header files were included via the -Bsome/build/tree/path GCC command
line option.
This has at least seven problems:
* The make preinstall step itself needs time and disk space.
* Errors in header files show up in the build tree copy. This makes it
hard for editors to open the right file to fix the error.
* There is no clear relationship between source and build tree header
files. This makes an audit of the build process difficult.
* The visibility of all header files in the build tree makes it
difficult to enforce API barriers. For example it is discouraged to
use BSP-specifics in the cpukit.
* An introduction of a new build system is difficult.
* Include paths specified by the -B option are system headers. This
may suppress warnings.
* The parallel build had sporadic failures on some hosts.
This patch removes the make preinstall step. All installed header
files are moved to dedicated include directories in the source tree.
Let @RTEMS_CPU@ be the target architecture, e.g. arm, powerpc, sparc,
etc. Let @RTEMS_BSP_FAMILIY@ be a BSP family base directory, e.g.
erc32, imx, qoriq, etc.
The new cpukit include directories are:
* cpukit/include
* cpukit/score/cpu/@RTEMS_CPU@/include
* cpukit/libnetworking
The new BSP include directories are:
* bsps/include
* bsps/@RTEMS_CPU@/include
* bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILIY@/include
There are build tree include directories for generated files.
The include directory order favours the most general header file, e.g.
it is not possible to override general header files via the include path
order.
The "bootstrap -p" option was removed. The new "bootstrap -H" option
should be used to regenerate the "headers.am" files.
Update #3254.
