Difference Between Full CAN and Basic CAN Controller

History of Full CAN and Basic CAN Controller

In the past, there were two main types of programming interfaces for CAN controllers: the Intel 82526, which used a DPRAM-style interface, and the Philips 82C200, which used a FIFO-oriented interface with limited filtering capabilities. The Intel interface was referred to as “Full CAN” and the Philips interface as “Basic CAN,” but today, most controllers support both programming models and therefore, these terms should be avoided to prevent confusion.

If we can analyze it in technically as per the CAN Controller, then CAN protocol started with one controller called the Intel 82526, which had a limited number of message buffers (up to 5 message buffer). Later, the 82527 was created with more message buffers (15). Philips then made a cheaper version called the 82C200, which had fewer buffers (2 for receiving and 1 for transmitting) and less advanced filtering. To distinguish between these two types of controllers, people began referring to the original version as FullCAN and the cheaper version as BasicCAN.

Full CAN and Basic CAN Naming Convention

The terms “FullCAN” and “BasicCAN” are not officially defined in the CAN protocol specifications and are used by manufacturers. They should really be referred to as “DPRAM mode” and “FIFO mode” respectively, as the underlying structure of these controllers is different. It’s important to note that “FullCAN” does not necessarily have more features or capabilities than “BasicCAN”. The design of the 82527 controller was later adopted by Siemens and can now be found in their devices such as the C505C, C515C, C164 and C167, among others.

Newer CAN controllers have added advanced features to the basic functionality. Some controllers, known as FullCAN, have up to 32 object buffers. Other controllers, known as BasicCAN, have a large FIFO for storing multiple messages, such as the Philips SJA1000, also known as PeliCAN. Some controllers also allow a combination of these features, they are implemented as Full CAN but can use some of the object buffers to create FIFOs and operate as BasicCAN.

Design Architecture of Full CAN and Basic CAN Controller

Full CAN and Basic CAN are different architectural approaches in the design of a CAN controller. Full CAN controllers typically have multiple message object buffers that can be programmed to only accept specific messages or groups of messages. These buffers do not usually store multiple messages, so if a new message arrives that matches the acceptance filter, it will replace the previous message and the old message will be lost. This can be an issue when two messages with the same ID but different data are sent very quickly. In this case, the CPU may not have enough time to process the first message before the second message arrives and overwrites it.

Basic CAN Controller in CAN Protocol

A Basic CAN Controller has limited filtering capabilities that are built into the CAN controller hardware. This means that there is reduced message handling, which results in a higher load on the central processing unit (CPU). When using a Basic CAN Controller, the CPU is required to handle multiple interrupt signals from the CAN controller in order to receive, acknowledge, and interpret the message. From the application side, the CPU must also determine whether or not a response should be sent based on the identification (ID) of the received message.

Generally, Basic CAN Controllers should only be used in communication networks that have low baud rates and a low number of messages being transmitted. This is because the CPU needs to handle additional tasks outside of communication, and using a Basic CAN Controller in a larger or more complex network would put a significant strain on the CPU.

Full CAN Controller Feature in CAN Protocol

A Full CAN Controller provides a comprehensive implementation of message filtering and parsing capabilities in the hardware, which frees up the CPU from the task of responding to every received message. This type of CAN Controller can be configured to only interrupt the CPU with messages that have been specifically designated as acceptance filters.

Full CAN Controllers have multiple message storage units, called mailboxes, which can store information about specific messages such as the ID and data bytes received. The CPU can retrieve this information from the mailboxes at any time, but must complete the task before receiving an updated version of the same message and overwriting the current contents of the mailbox.

This issue is resolved in the final type of CAN controllers, which will be addressed in a different context. The Full CAN Controllers offer a more advanced and flexible way of managing messages in a communication network, compared to Basic CAN Controllers. But the next version of CAN Controllers are availaible now in the name of Extended full CAN controller.

In contrast, Basic CAN controllers like the Philips sja1000 typically have a receive queue and do not have individual message buffers. The controller stores all incoming messages in the queue and the CPU can retrieve them in the order they were received. This approach eliminates the issue of messages being overwritten before they can be processed.

Working Principle of Full CAN & Basic CAN Controller

When any message received from the CAN bus, it will receive by the CAN controller Mail-Box or buffer memory we say. Each Mail-Box can receive and store a single message with a single message Identifier at a time. But if the same message Identifier sends continuous messages with different data, but the previous message data was not being used or sent to the application layer, then we will lost the older message data. Because the new data will be overlapped by the older data since both are the same message Identifier. A single Mail-Box in CAN controller can be configured with a single CAN Identifier. So that we can only receive a single and same CAN message with the CAN identifier configured. Then we can not configured more CAN messages than the number of Mal-Box of buffers are there in this Microcontrollers. Because it is limited from chip itself, this is what we say that Full CAN configuration in CAN protocol. In this case we have configured each CAN Controller Mail-Box or memory buffer with each CAN Identifier, for which we can not keep more than one same message Identifier data. This works like a FIFO Buffer.

But, when or suppose we will use the Basic CAN feature. We can have a software level variable or Memory buffer with array[] like you can say like the above image. So that we can configure as Basic CAN feature by using this software level Buffer to store more than one CAN Identifier message buffer. So, if the same CAN Message Identifier sends multiple messages back to back with different data or information, we can store it in our extra memory or buffer which is configured in software level.

I hope you might have understood well that what is and how the Full and Basic CAN feature is working. So lets conclude it by making a differentiation between them.

Basic CAN verses Full CAN Controller Configuration Feature

Use of Full CAN & Basic CAN Controller in AUTOSAR

Even though, the Full CAN and Basic CAN Controller are not defined by any controller company, but feature wise it is known by everyone. This name is also is being used by all the developer and testing engineers. Since it is to understand when we talk technically an ddo the development, it is also used in the automotive companies. The AUTOSAR also started using this naming and in Configuration Tool like Vector Davinci Configurator, EB Tresos etc…

Full CAN Controller Feature Configuration in AUTOSAR

In AUTOSAR, a Full CAN controller is a type of controller that supports the FULL CAN programming model. This model assigns a single IPDU (Inter-ECU Protocol Data Unit) to a single CAN frame, which eliminates the need for software filtering. This allows for a simpler and more direct communication between the ECUs (Electronic Control Units) in a system. Additionally, the Full CAN controller in AUTOSAR includes the necessary hardware and software to implement the CAN protocol and provide the necessary interfaces for communication with other ECUs.

When a single IPDU is assigned to a single CAN frame, it is referred to as FULL CAN. FULL CAN does not require software filtering, but for BASIC CAN, software filtering is necessary to select which PDUs should be forwarded during reception.

The Full CAN feature will prevent the upper layers from getting overloaded.

Basic CAN Controller Feature in AUTOSAR

In AUTOSAR, a Basic CAN controller is a type of controller that supports the Basic CAN programming model. This model involves combining multiple IPDUs (Inter-ECU Protocol Data Unit) into a single CAN frame, which requires software filtering to select which PDUs should be forwarded during reception. The Basic CAN controller in AUTOSAR includes the necessary hardware and software to implement the CAN protocol, including the ability to add headers to the PDUs and combine them into a single frame. Additionally, it provides the necessary interfaces for communication with other ECUs. The Basic CAN controller is designed to provide more flexibility and scalability in communication between ECUs, but it comes with a trade-off of additional complexity in the software.

The IPDUs grouped in the Communication module are sent to the CAN IF module for further processing. The CAN IF module is responsible for adding the necessary header information, as specified in the arxml file or dbc file that is loaded. If the size of the IPDUs is only 24 bits, additional space can be added to the CAN frame. The CAN IF module can then combine multiple IPDUs from the COM Module into a single CAN frame and transmit it. This method is known as BASIC CAN.

Selection of Full CAN and basic CAN Controller for Your Project

The choice between FullCAN and BasicCAN depends on the specific requirements of the application. If an application only uses a limited number of different messages, a FullCAN controller with multiple message object buffers may be more efficient. However, if the application needs to process all messages in the system, a BasicCAN controller with a receive queue may be more appropriate. Some newer CPUs now have the capability to integrate two CAN controllers which can share the same RX/TX pins, providing up to 32 message objects. Ultimately, the best approach will depend on the specific needs of the application.

How Efficiently use Full CAN and Basic CAN Controller In Your Project

The maximum speed defined for the CAN protocol is 1 Mbit/s. However, the actual rate of interruptions, which occur every 55 microseconds on average, may vary depending on system load factors such as Ethernet, serial, and PID-loop. All of these factors have interrupt latencies and different priorities that may affect CAN Bus reception, although having 15 message centers helps with buffering, and reduces the chance of a lost CAN frame.