Hello expert,
My customer would like to know below question from TCAN4550 and TCAN4550-Q1. May we know if you can help to answer it? Thanks!
Best regards,
Ann Lien
Hello Ann,
Thank you for your patience during this holiday season.
We have some ANSI-C (bare metal) driver code available for download on the TCAN4550 and TCAN4550-Q1 product folders under the "Software Development" section. This driver was developed with the MSP430FR989, but is abstracted in a way that it should be compatible with any MCU after the SPI drivers are modified to meet the hardware requirements of your particular MCU.
We have a Software Developer's User Guide available as well to help explain how to develop and integrate the TCAN4550 into the application.
A Linux driver has been developed and incorporated into the Linux Kernel starting with version 5.10. It is called "tcan4x5x".
The TCAN4550 will work with any system that can communicate through the SPI interface of the device. Therefore if your OS can support the required SPI interface, the TCAN4550 will work. This is usually more of a hardware consideration than a OS consideration.
We don't provide a test program, but outside of the demo starter code API, an AutoSAR abstraction layer is available upon request.
CANopen and SAE J1939 are higher level protocol layers that operate on the CAN physical layer hardware. The TCAN4550 is compliant to the CAN FD physical layer and therefore can be used for any CANopen and SAE J1939 applications.
Regards,
Jonathan
Hello Edmond,
The CAN "demo starter code API" is low-level ANSI-C typically used in microprocessor firmware and is typically at the lowest level calling the SPI driver communicating with the TCAN4550 device on a physical layer. This level of code abstracts the lowest level SPI register read/write transactions into higher level functions that can be called by an even higher application layer of code. Porting this code to different microprocessors would generally only require changes to the SPI Abstraction Layer to become compatible with the processor's low level SPI driver and unique hardware requirements.
The "AutoSAR abstraction layer" is an abstracted layer of code that has specific functions defined by AutoSAR. This code is not built on any specific hardware platform or processor which allows it to be ported to different platforms.
The Microcontroller Abstraction Layouer (MCAL) provides standardized function calls to peripherals of a microcontroller such as the IOs, bus ports (SPI or I2C), or even memory. By abstracting these peripherals to common function calls, it makes it possible to simply swap MCAL drives for a different processor when migrating, but all the code above should behave the same with very little to no modifications. These MCAL drives are processsor/vendor specific since they deal with the specific code required to perform a function.
The ECU Abstraction Layer provides a common set of functions that an electronic control unit (ECU) would use such as CAN communication or GPIOs for sensing buttons or controlling lights. These modules are designed to be processor independent and call on the MCAL layer to handle whatever functions are required. In the case of the TCAN45xx, the MCAL driver for SPI is used to communicate to the TCAN45xx.
The Services Layer provides background services to the application such as network services and bus communication services. An example for the TCAN45xx is that a beacon bus communication may be desired (a periodic bus ping to check the status of devices on the bus) and this service communicates to the TCAN45xx ECU abstraction driver in order to actually send and receive the CAN messages.
Texas Instruments provides the necessary ECU abstraction layer driver source code necessary to integrate the TCAN45xx into an AutoSAR environment. However, the MCAL driver layer is vendor specific and should come from the processor vendor, or other software developer.
If you notice that both the demo starter code API and AutoSAR ECU abstraction layer code sit at a lower level than the Run Time Environment (RTE/OS) and Application Layers, they should be able to be used by a developer to support either a Windows or Linux OS. The code provided by TI is however at much lower level than the Application Layer, therefore, it will not be incorporated into a application designed for the type of OS used and also modified to work with the specific processor communicating with the TCAN4550 through SPI at the hardware level.
Regards,
Jonathan
