Table of Contents
Introduction
In this blog, we will delve into the CAN protocol in embedded systems. Our goal is to gain a comprehensive understanding of the CAN protocol from the perspective of microcontrollers and embedded systems. While there is a plethora of content available online that explains the theoretical concepts of the CAN protocol, resources that focus on its practical implementation from a microcontroller and embedded systems standpoint are scarce.
It is crucial to grasp the intricacies of the CAN protocol from a microcontroller and embedded systems perspective, especially when it comes to integrating it into your product or learning about the protocol. By understanding the CAN protocol in this context, you will be better equipped to effectively implement it in your projects.
Over net and online courses, we will find number of resources and blogs about CAN protocol and technology. All of the resources cover only theoretical part of CAN protocol. Not only theoretical but rather same content is there in most of the resources. Most of the content is on what is CAN protocol and Its overview in terms of features and specs. Those resources are good to know from beginners point of view and good to have to know about CAN protocol in theoretical respect. But resources on CAN technology implementation in practical way and how to use CAN technology for doing CAN communication is very very limited and not present.
And that what we are going to cover in today topic. We are going to understand about CAN Protocol from microcontroller and practical implementation point of view.
Brief About CAN
In CAN protocol, there are 3 types: Standard CAN, Extended CAN and CAN FD. Difference between these 3 are of size of payload data, size of message identifier and speed.
CAN communication is a 2-wire serial communication protocol. These 2 pins are termed as CAN Tx and CAN Rx pins. Every Microcontroller which is have a CAN peripheral, would be having these 2 pins. CAN protocol use these 2 pins for communication between 2 nodes via CAN technology.
CAN Protocol
CAN Protocol has 4 type of Frames:
- CAN Data Frame
- CAN Remote Frame
- CAN Error Frame
- CAN Overload Frame
CAN protocol has broadly 3 types:
- Standard CAN: 11-bit Message ID with 8 bytes of CAN data
- Extended CAN: 29-bit Message ID with 8 bytes of CAN data
- CAN FD: 11-bit Message ID with 8/16/32/64 bytes of CAN data.
Important Terminologies
The CAN protocol was initially developed for use as a vehicle serial data bus, addressing the specific needs for real-time processing and reliable operation in the EMI environment of a vehicle.
- CAN Bus
- CAN Signal
- Arbitration
CAN Protocol Hands-on Course with CAN analyzer
CAN Standard
CAN specification was launched 1986 by Bosch and in next year 1987 first CAN controller chips were made by Intel. Then in 1991, CAN2.0 specification was launched by Bosch, which is widely accepted in automotive industry and internationally accepted for doing ECU Communication’s in a car.
CAN2.0 is specification that define the CAN protocol. The implementation of CAN protocol to achieve its properties are defined in ISO-11898 standard. Thus, since that ISO-11898 standard series is being followed for implementing CAN protocol.
ISO-11898 is the standard that defines the CAN protocol, according to CAN2.0 specifications. There are series of ISO-11898 standards. A brief about each standard is given below. ISO-11898 has following parts:
- ISO-11898-1 2003 2015 2024: Specifies Data Link Layer and Physical signaling of the CAN. This document describes the general architecture and provides the characteristics for setting up an exchange of digital data between electronic modules through CAN protocol. It specifies detail of logical link control(LLC) and medium access control (MAC) layer.
- ISO-11898-2 2003 2016 2024: Physical Layer for high-speed CAN for transmission rates up to 1 Mbits/s. This is first standard that specifies physical layer for CAN using 2-wire balance signaling scheme.
- ISO-11898-3 2006: Physical Layer for low-speed CAN for transmission rates of 40kbits/ to 125kbits/s.
- ISO-11898-4: specifies time triggered communication in the CAN.
- ISO-11898-5: Physical layer for high speed CAN for transmission rates upto 1Mbits/s. It is an extension of ISO 11898-2 dealing with new functionality for systems requiring low-power consumption features while there is no active bus communication.
- ISO-11898-6:2013: Physical Layer for transmission rates upto 1Mbits. It is an extension of ISO 11898-2 and ISO 11898-5 specifying a selective wake-up mechanism using configurable CAN frames.
Compared to OSI model, ISO-11898 standard has divided CAN protocol in Physical Layer and Data Link layer. We will brief about these layers after understanding about CAN node and CAN controller.
What is CAN Node?
For Doing the CAN Communication, in real world their is a CAN node. CAN node consists of:
- Host Microcontroller Controlling the CAN communication.
- CAN controller(CAN peripheral or External CAN IC)
- CAN transceiver IC
CAN transceiver IC followes the ISO-11898 standard2&3. These 2 ISO standards define the physical characteristics and electrical specification for doing CAN communication. While CAN Controller follows the ISO-11898-1 specification that is data link layer, which specifies how should CAN hardware handle the outgoing and incoming messages so as to achieve required properties of CAN protocol.
Host MCU: A host is a microcontroller or microprocessor which is running some application to do a specific job. A host configures and control the CAN controller for doing CAN communication.
- It decides which type of CAN protocol to use( Standard/Extended/CAN FD)
- When to send data, when to receive data
- Configures how to use CAN controller( what baudrate, transmission/reception mechanism: polling:interrupt:DMA and etc)
CAN Controller: CAN controller deals with the transmission and reception of data according to CAN protocol. It also triggers the transmission, or the reception of the CAN messages. The data link layer of CAN and physical bit timing is implemented
by the CAN controller (sometimes embedded within a microcontroller or some external CAN IC), according to the CAN 2.0b specification and conforming to the data link layer portion of the ISO-11898 standard. CAN Controller has following Roles and Responsibility:
- Message Filtering
- Arbitration
- Message Framing
- error handling and detection
CAN Transceiver IC: CAN transceiver is responsible for the transmission or the reception of the data on the CAN bus. It converts the data signal into the stream of data collected from the CAN bus that the CAN controller can understand. A CAN (Controller Area Network) transceiver is an Integrated Chip that interfaces between the CAN protocol controller and the physical bus. It converts the data from the controller into a form that can be transmitted over the CAN bus and vice versa. CAN Transceiver IC has following Roles and Responsibility:
1. Signal Conversion: Converts the digital signals from the CAN controller to the differential signals required for the CAN bus, and vice versa.
2. Voltage Level Adaptation: Ensures compatibility between the logic level of the CAN controller and the voltage levels on the CAN bus.
3. Fault Tolerance: Can include features to detect and handle bus errors and collisions, ensuring reliable communication even in the presence of faults.
4. Isolation: Provides electrical isolation between the CAN controller and the bus to protect the controller from voltage spikes and other electrical anomalies on the bus.
CAN Controller
Overview
In microcontroller to use CAN technology, there is a CAN Controller which handles CAN communication and follow CAN standards of ISO-11898 to support CAN protocol and its features. CAN Controller can be of 2 types CAN peripheral in Microcontrollers or some external CAN IC. So now in this blog, we are going to dig deep into general understanding of CAN Controller which are either present in the form of CAN Peripheral in microcontroller or some External CAN IC. We are going to focus on CAN Peripheral for examples given. But same understanding would be their for External CAN IC.
In different Microcontrollers there is a CAN peripheral, that can be referenced by different names. Like in NXP S32K1 and S32K3 MCU’s it is FlexCAN Module, in Infineon Technologies TC3xx MCU it is MCMCAN module. And multiple instances of corresponding CAN peripheral, can be present in a corresponding MCU. In NXP S32K1xx there are 3 instances of FlexCAN module. In Infineon TC3xx there are 5 instances on MCMCAN module. The peripherals can be termed as different names in different microcontroller, but their basic working and concept is same in all. So, it’s important that we understand how CAN peripheral in a microcontroller works.
Understanding the working of CAN peripheral of a microcontroller, make us get knowledge on how to use CAN technology in practical sense. Relating theoretical concepts of CAN technology like multi-bus protocol, error managment, Standard/Extended CAN Data Frames communication techniques, Transmission/Reception of different data frames of CAN with practical DIY projects, is best done by understanding how CAN peripheral in a microcontroller works and then doing simple DIY projects to test different features of that technology.
How does CAN peripheral in microcontroller’s work for doing CAN communication? How to do simple 2-way CAN communication from microcontrollers? How CAN transmission happens? How CAN reception happens? How to configure Microcontroller for CAN transmission and CAN reception? How to do CAN communication via different techniques(polling/interrupt/DMA)? How standard/extended/CAN FD communication configurations are done?
In CAN peripheral there are concept of Message buffer, Mailboxes, Rx FiFo, FiFo message ID filter table and CAN protocol engine which are used for transmission and reception of CAN data. These concepts are important to understand. These concepts are implemented in CAN peripherals and external CAN ICs via which transmission and reception of CAN data frames happen at microcontroller and embedded level. However, the nature of implementations of these concepts in CAN peripherals can be different and would be SoC dependent. Understanding of this concept is important from Embedded Software point of view and if you want to have some Handson project and learning on CAN protocol.
What are Message buffers in CAN Controllers?
Well now in CAN peripheral of the microcontroller’s, there is a small section of memory in microcontroller that is being used to process the CAN data. This memory is called as message buffer. Buffer signifying for memory and message signifying for CAN data. All CAN Transmitted and received data is processed in this message buffer space only. The message buffer can be referenced as Embedded RAM or Memory RAM in different SoC. But all terminologies meant same thing.
The message buffer will process all kinds of CAN Data : Standard CAN, Extended CAN, CAN FD messages. All the CAN transmission and reception of CAN data happens via the message buffer space only.
A standard CAN data is of 13.5 bytes in total, which we will near about 16 bytes to align it to
microcontroller buses. Extended CAN data is of exact 16 bytes in total, in which 8 bytes are of
payload. Similar way in the case of CAN FD data, it occupies 16, 24, 40 or 72 bytes in total in
which 8, 16, 32, 64 bytes are payload. Though CAN FD data frames are of 14, 22, 38, 70 bytes in
total but for aligning these bytes with microcontroller busses, these are rounded off to nearest
8 multiples.
Now whenever a CAN message has to be transmitted, Microcontroller will write a CAN message Data and ID in one of the memory addresses of this message buffer, according to message buffer structure. And in the case of receiving, the external CAN message data and ID is received in this memory area if all acceptance criteria conditions are met.
There are 2 mechanisms in Message Buffer: MailBox and FIFO for Processing CAN Data.
In the case of MailBox Mechanism, acceptance criteria is the message ID that is binded to the
mailbox. And in the case of FIFO mechanism, acceptance criteria is the Message ID filter table.
Message Buffer structure is applicable for mailboxes only, for FIFO mechanism, it has its own FIFO
structure.
Depending on size of the message buffer, more the number of CAN Messages can be transmitted and received at a time. More the Message buffer space is more the number of CAN data can be transmitted and received. Now implementation of message buffer can be different in SoC to SoC.
- In some SoC’s this message buffer has fixed size (NXP S32K1xx-S32K3xx MCU series, Infineon TC3xx and Renesas RH850 SoC’s): S32K144 has 512 bytes of message buffer, S32K344 has 1536 bytes of message buffer, Infineon TC3xx Microcontroller has total 4480 words of message buffer
- Whereas in Some SoC’s the message buffer space is designated by special CAN Peripheral registers (this is usually done in low space microcontrollers for e.g in STM32F103): STM32 series has designated registers( 7-8 registers in total) to use message buffer.
Course to understand Message Buffer concept in CAN Protocol
About Mailbox in CAN Controllers.
Now number of sections in a message buffer is, equal to space of message buffer divided by CAN data frame size. Each of this section is signified by a Mailbox(also called as Message Object.) Each section of the message buffer is referenced by a integer number, which is called a mailbox number.
So, for address 0x00 to 0x10(16 bytes) in message buffer, it is referenced by Mailbox number 1. From 0x10 to 0x20 it will be referenced by Mailbox number 2. 0x30-0x40 -> mailbox number 3 and 0x40-0x50 -> mailbox number 4 and so on. So, we have kind of assigned a mailbox number to the different address spaces of message buffer. So, when using mailbox mechanism, their would-be linear sections of memory that are incremented according to CAN data size and each section is referenced by mailbox number.
So now if we are processing Standard CAN, Extended CAN or CAN FD with 8 bytes payload: 16 Bytes of message buffer space is what is going to be consumed for a single Data Frame, whether it is for transmission or reception. So, total there can be 32 sections of memory if we have 512-byte size of message buffer (in the case of S32K144 Microcontroller) and 96 sections of memory if we have 1536 bytes size of message buffer(In the case of S32K344 Microcontroller).
Also Depending upon the CAN payload bytes, we can have different number of mailboxes as more the payload size in a CAN frame, more size would be of overall single CAN Frame.
As each mailbox signifies a memory of message buffer. So we can configure a mailbox to be used for transmission of CAN data or we can configure a mailbox to be used for receiving of CAN data. Thus that how via mailbox mechanism we get configuration flexibility for transmitting and receiving feature of CAN protocol achived.
What is Mailbox in CAN Controller?
The terminology which is used to refer to one section of memory of message buffer space is Mailbox. And we can configure whether this mailbox has to be used for CAN transmission or CAN reception. In the case of CAN transmission, it would be termed as TX mailbox and in the case of CAN reception it would be termed as RX mailbox.
Data to be transmitted by Tx mailbox follows the arbitration process to transmit the data, and the external signal transmitted is received by Rx mailbox if message ID of external signal matches with the message ID of Rx Mailbox.
How Tx mailbox works?
Now mailbox signifies a section of memory in message buffer, where CAN data can be written from Microcontroller in the case of transmission. So, We can bind a section of memory or what we can call a mailbox with one CAN message ID. Whenever Microcontroller calls that mailbox, configured CAN message ID with its data content would be transmitted.
In the case of transmission there are 2 important concepts to understand. First is arbitration and second is transmit priority.
Transmit priority: We can configure multiple mailboxes with different message IDs to transmit different CAN data. Now we can configure the order of transmission of those mailboxes. Which mailbox would be transmitted first, and which would be transmitted last. The CAN Controller has this feature to configure the order of transiting mailboxes. Via this feature of Tx Mailbox, another CAN priority of prioritization messages is achived.
Transmit Arbitration:
How Rx mailbox works?
In the case of reception, we can bind a mailbox with a CAN message ID. And whenever a external CAN data of that message ID is received, the CAN data is copied to the memory that is being signified by mailbox.
So, say we want to receive 2 CAN data of 0x402 message ID and 0x502 message ID. So, we can assign mailbox number 4 to 0x402 and mailbox number 20 to 0x502. Whenever CAN messages of this message ID is received by MCU, the memory that is signified by corresponding mailboxes would be filled with CAN received Data.
Now in a car a single ECU receives number of CAN data. So, we have to configure new mailbox for each CAN message ID that we want to receive.
This process might feel like it gives all the nodes a ‘master importance’, but it only adds to unwanted traffic towards every module on the bus in practicality. When connected to a CAN bus, the data logger acts as another node. Logging all the traffic in the CAN bus fills up the internal storage quickly. Finally, you may end up having no storage left to log the data when the vital/required data is transmitted in the bus.
Interrupt in MailBoxes
About FiFo buffer in CAN Controller?
There is one more way to divide the sections of memory buffer. That is using FiFo buffer. What we do is we will configure a memory section of message buffer to be used as FiFo buffer.
How FiFo mechanism works?
What happens in FIFO buffer is that, a buffer is created and only that buffer space is used for receiving and transmitting the data. We don’t configure different memory sections or mailbox numbers for transmitting/receiving CAN data. So First Come First Out mechanism is implemented, which ever configured CAN data comes first would be process first further.
In the case of reception, it is called as Rx FiFO and in the case of transmission it is called Tx FiFo. In FiFo mode, we create a Message ID filter table or Message ID transmit table in message buffer memory. These tables would be stored with CAN message ID’s that should be accepted (in the case of receiving) or transmitted (in the case of transmission) by MCU.
- In the case of reception if external CAN signal’s message ID matches with the ID’s mentioned in Message ID filter table it will copy external CAN data into a memory section of FiFo buffer. So, it works in a FiFo mechanism, First Come first out. Whichever CAN message ID out of Message ID filter table comes first will be read first by MCU.
- In the case of transmission, MCU will copy CAN data from message ID transmit table in configured order (ascending or descending) to the memory section of the FiFo buffer. And Can data be transmitted continuously until whole transmit message ID table is empty.
- In FiFo mechanism, Host MCU configure a section of memory in message buffer as FiFo Buffer. And data reception and transmission will happen from this FiFo buffer only on the basis of First in First Out. Whichever message Id is detected first would be processed first by MCU.
FIFO Buffer implementation
FiFo working mechanism is also implementation specific. In Some controller’s only Rx FiFo is available (NXP S32K1xx and NXP S32K3xx) and no TX FiFo. While in some controller both Tx and Rx FiFo will be available(Infineon TC3xx MCU’s),
FiFo buffer implementation is different from SoC to SoC. In some SoC’s FiFo buffer have different memory space with in message buffer and mailboxes have different memory space in message buffer (Infineon TC3xx MCU’s), while in some SoC’s FiFo buffer and mailboxes lies on same message buffer space ( NXP S32K1xx and S32K3xx)
In first case, enabling the RX FiFo decreases the count of mailboxes that are available to use for Tx/Rx mailbox mechanism. In First case, Rx FiFo and mailboxes reside in different memory space. But this is usually possible in those SoC’s which have larger memory. Second stage is what is used in small memory size MCU’s.
Let’s understand FiFo mechanism from receiving perspective. As FiFo mechanism is mainly for receiving of CAN Data. In this mechanism, we configure which all message ID’s we want to receive in FiFo buffer via Message ID filter Table. If any of the external CAN signal message ID, matches with the message ID of filter table the CAN data is written into the FiFo Buffer.
Host Microcontroller has to read the CAN data from the FIFO buffer memory space. FIFO buffer is x message deep. This x varies in different CAN peripherals and CAN IC’s. It can store up-to x messages in its buffer and HOST MCU can read the data sequentially in the order it is received. If MCU doesn’t read the data, then corresponding error flags would be raised by FiFo engine. Those 2 are watermark and overflow error.
- Watermark error is raised when FIFO buffer is almost full, indicating to HOST MCU that it should read the data from FIFO, FIFO buffer is almost full.
- Overflow error is raised, when FIFO buffer is full and again new CAN data is received by FIFO. When Overflow error is raised, new data will be overwritten by first data that was received and it will be lost. As FIFO buffer is full, so it will start overwriting the new CAN Data.
What is Message ID filter table?
This is a memory space in memory buffer created when we use FIFO mechanism. Over here Host MCU write’s the Message ID’s that should be accepted by FIFO Buffer. Message ID filter table is given a name table, as over here we can list down message IDs according to acceptance criteria type that should be accepted by FIFO Buffer.
In a single row of the table 1 acceptance criteria is written. So more the number of rows a greater number of message ID’s can be filtered. During Rx FiFo mechanism, CAN messages are received according to Message ID filter table. Only those message ID’s which are mentioned in message ID filter table would be received. All other message ID’s would be discarded from a corresponding CAN node.
The implementation of message ID filter is also different in SoC to SoC. In some controller’s Message ID filter table is in same memory area of message buffer where mailboxes are present. So in those increasing the Message ID filter table rows, reduces the MailBoxes number available for application. In some SoC, Message ID filter table is at different memory area of message buffer then mailboxes. So, increasing the Message ID filter table rows, doesn’t impact the mailboxes numbers.
What are Acceptance criteria?
Acceptance criteria in CAN is powerful filtering scheme to accept only frames intended for the target application. We can Configure which frames to accept in FIFO mechanism by mentioning the message IDs in the Message ID Filter Table. Message IDs of Standard CAN, Extended CAN or CAN FD, all of these are supported.
Acceptance criteria can be of 3 types:
- Single Acceptance criteria
- Dual Acceptance Criteria
- Range of Message ID criteria
In a single acceptance criterion, we can mention 1 message ID per index of filter table that should be accepted. This is simplest form of acceptance criteria. In Dual Acceptance criteria, we can mention 2 message ID per index of filter table that should be accepted. In range of message ID, we can mention a range of message ID’s that should be accepted.
But different SoC’s can have different formats of acceptance criteria. In some SoC’s we can write up to 2 Standard message ID in one acceptance criteria. Acceptance criteria also have features of bit mast, which makes it possible to configure a range of message ID to be accepted. Main moto of acceptance criteria is to provide a powerful filtering scheme, though its implementation and features can vary from SoC to SoC. Use the acceptance criteria and filter table, we can configure a CAN node to receive number of CAN data based on different message IDs.
Today’s vehicles can contain more than 70 devices, commonly called Electronic Control Units (ECUs) or nodes, that control electrical subsystems. These subsystems control the engine, transmission, powertrain and antilock braking/ABS along with many more. Communication between these subsystems is critical to ensure the reliability and safety demanded in the automotive market. The acceptance criteria feature of Controller Area Network allows ECUs to communicate within a vehicle, with each other by assigning different message IDs. We can assign every ECU with a designated Message ID and then configure other ECUs with this message ID, as a acceptance criteria so as to accept its data.
FIFO Mechanism in CAN Controller achives the Multicast reception, multi master and system wide data consistency features of CAN protocol.
CAN Properties
Well so as if now, you guys must have got the good kind of clarity and understanding in terms of CAN protocol implementation in microcontroller and embedded world. Now let’s just conclude that how does this implementation fulfills the CAN protocol properties.
Properties of CAN Protocol as per Bosch CAN 2.0B specification
- Prioritization of messages
- Guarantee of latency times
- Configuration flexibility
- Multicast reception with time synchronization
- System wide data consistency
- Multi master
- Error Detection and signaling
- Automatic Retransmission of corrupted messages
- Acknowledgement and Sleep Modes.
Prioritization of messages
Via mailbox mechanism for both transmitting/receiving, the prioritization of messages is achieved. We can configure which messages has to be transmitted/received first based on the mailbox number or based on the message ID value that is binded with mailbox. Also, in terms of FIFO, we can configure in Message ID filter table, which Message IDs should be given priority based on the message ID value or based on order in which message ID are written in Filter table.
There is corresponding microcontroller CAN peripherally registers through which configuration of message prioritization can be done.
Configuration Flexibility
Configuration Flexibility we mean which transmitting and receiving messages. Using mailbox mechanism, we can configure any message ID to transmit CAN data and binding any message ID to mailbox number to receive CAN data via that message ID only.
Multimaster
The Node which is transmitting data is master and once that node has transmitted the CAN data, now any other node can send CAN data. Its nothing like that only one node can transmit data and has the control of CAN bus. Through the process of arbitration in CAN protocol, any node can transmit data and after it has transmitted successfully any new node can new data by taking control over the CAN Bus.
Multicast reception
The CAN Data which is send by one CAN node, can be received by number of CAN nodes only using 2 wires of CAN communication. No need of separate wire like CE in SPI or changing address in I2C. Using same 2 pins CAN_Tx and CAN_Rx, same message can be received by number of CAN nodes.
The receiving CAN node can configure its mailbox or FIFO filter table to receive the CAN data by the message ID which is transmitted by Transmitting CAN node. So now whenever in CAN Bus a CAN Data is transmitted by that message ID, it will be received by all CAN nodes.
For e.g their are 3 CAN Nodes. CAN Node A, CAN Node B and CAN Node C. Node A transmits CAN Data with message ID: 0x302. The data transmitted by Node A has to be received by Node B and Node C both. So, Node B can configure one of its mailboxes to get bind with 0x302 and Node C can configure in its message ID filter table 0x302. So, both node B and Node C would be able to receive can data, without changing any address (like in case of I2C) or adding additional wire (like in case of SPI).
CAN Protocol Architecture
CAN protocol architecture has been divided into 2 layers according to OSI refrence Manual, so as to achieve design transperency and compatibility b/w any 2 CAN nodes:
- Physical Layer:
- Data Link Layer.
Physical Layer: Defines electrical- mechanical characteristics and implementation for transfer of raw CAN data (bits and bytes) from one CAN node to another CAN node via wired physical medium. CAN transceiver comes in physical layer.
Data Link Layer: Defines CAN Hardware Controller characteristics for organizing the outgoing and incoming CAN data. So that CAN Protocol properties can be achieved. CAN peripheral or External CAN IC implements the Data link layer, as intructed above. Data link layer has to provide following things:
- Finding which messages are to be transmitted.
- Deciding which messages received are actually to be used.
- Providing an interface to the application layer to process CAN data communicated on physical layer.
- To provide means for recovery managment and overload notifications.
- Controlling the framing of CAN data for error-free transmission of data.
- Performing arbitration to decide which CAN node will transfer CAN data on CAN bus.
- Error Checking
- Message Filtering for received CAN data
- Message Transmission order while transmitting CAN data.
Conclusion
Now we will understand more about CAN protocol by Handson Practical’s. This blog must have given you brief and overview about practical implementation of CAN protocol. How CAN protocol should/can be used in different microcontrollers. Now if you read the datasheet on CAN peripheral, you will be able to understand that and process the terminologies, concepts, topics listed over their. Now further we are going to cover how to do CAN Communication on different Microcontrollers using knowledge imparted on this blog.
We are at first going to start CAN Communication on NXP S32K1xx and NXP S32K3xx Microcontroller series via Autosar MCAL layer software stack. With time would be covering number of other Controllers too. But this blog would be used as starting point for all the practical implementation on CAN technology.
Next Blog to Read
More Blogs to Read
Getting Started with Autosar MCAL Layer
Looking to learn Autosar Software Tech Stack?? Autosar MCAL Layer is the easiest and inexpensive way to start learning your automotive software journey that too with Handson DIY projects and not just theoretical way
Cryptography Do It Yourself (DIY) projects
Learn Cryptography technology in embedded through DIY projects using NXP S32K144 Automotive Chips
How Cryptography in Automotive is implemented.
In the new age of autonomous and connected vehicles, cyber-attacks in automotive are happening frequently. Discover in this blog, what technology is used to make our vehicles safe and secure.
Embedded Hardware kits
ElecronicsV3 Board
Low cost Development Board for NXP S32K144 MCU as beginner friendly automotive kits
Evalution Kits
SmartwheelsV1 Programmable ECU for Automotive STM32_Energy_Metering Energy Metering Evalution Kit Open ECU(STM32F103) Cost Effective board for Automotive
Development Boards
ElecronicsV2(S32K144) Arduino of Automotive World Obseleted ElecronicsV3(S32K144) Arduino of Automotive World On-Board Jlink Debugger IMU+CAN OnBoard VehronicsV1(S32K148) Arduino Mega of Automotive World JN5189 Module Zigbee, Thread and NFC IoT Module
Author: Kunal Gupta
