|
|||||||||||
Technical Support On-Line Manuals RL-ARM User's Guide (MDK v4) RL-RTX RL-FlashFS RL-TCPnet RL-CAN Overview Features Source Files Function Overview Initialization Routines Message Reception Routines Message Transmission Routines Errors Hardware Configuration NXP LPC17xx Devices Configuration NXP LPC21xx Devices Configuration Getting Started Simulation NXP LPC229x Devices Configuration NXP LPC23xx Devices Configuration NXP LPC24xx Devices Configuration NXP LPC29xx Devices Configuration ST STM32F103 Devices Configuration Getting Started Simulation ST STM32F105/7 Devices Configuration ST STR71x Devices Configuration Getting Started Simulation ST STR73x Devices Configuration Getting Started Simulation ST STR91x Devices Configuration Getting Started Toshiba TMPM36x Devices Configuration Getting Started Luminary LM3Sxxxx Devices Configuration Atmel AT91SAM7X Devices Hardware Configuration Getting Started Initialization Example Projects RL-USB Example Programs Library Reference Appendix |
OverviewThe RL-CAN for the RTX Kernel simplifies the implementation of Controller Area Network (CAN) applications. The RL-CAN includes:
The RL-CAN runs interrupt service routines using RTX Kernel functions for Mailbox Management and Memory Allocation. The RL-CAN uses one Memory Pool for all CAN messages. Each CAN controller has two mailbox arrays, one to receive and one to transmit message buffering. The buffer method is First In First Out (FIFO) based. The interrupt-based RL-CAN provides the user with an available mechanism for message transmission and reception. The RL-CAN common generic software layer functions are located in the RTX_CAN.c file. This layer allows users to apply the same interface across different targets and to easily switch from one target to another without changing the Main Program. The RL-CAN hardware dependent software layer functions are located in the CAN_chip.c (example: for NXP LPC23xx chip file name is CAN_LPC23xx.c) file. The hardware dependent software layer enables the generic portion to function on many different targets, with each target having its own hardware dependent software layer implementation. The RL-CAN function diagram below shows how the Main Program's functions traverse the generic layer to the hardware layer where the functions are then executed. Input from the hardware controller follows a reverse route back to the Main Program. See the article in Wikipedia for more information about CAN. | ||||||||||
|
Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.