Difference Between Full CAN And

Basic CAN Controller

/ Automotive Electronics / By piembsystech

Table of Contents
Introduction To Full CAN and Basic CAN Controller
History of Full CAN and Basic CAN Controller
Full CAN and Basic CAN Naming Convention
Design Architecture of Full CAN and Basic CAN Controller
Basic CAN Controller in CAN Protocol
Full CAN Controller Feature in CAN Protocol
Working Principle of Full CAN & Basic CAN Controller
Full CAN Controller
Basic CAN Controller
Use of Full CAN & Basic CAN Controller in AUTOSAR
Full CAN Controller Feature Configuration in AUTOSAR
Basic CAN Controller Feature in AUTOSAR
Selection of Full CAN and basic CAN Controller for Your Project
How Efficiently use Full CAN and Basic CAN Controller In Your Project

The full CAN and Basic CAN Controller are used to provide the feature of
full or partial access or receiving of CAN messages. That means, this is
feature in CAN protocol configuration by which we need to configure
either of them for how to receive a CAN message.

This article written by doing some Research on CAN configuration to make

sure that the real and original information will reach to the CAN system
engineers or automotive engineers for better understanding. It will also
help to fresher engineers to learn this from PiEmbSysTech instead of
asking to your mentors always for small queries. This will help in savings
of Company resource time and money. So that the freshers willlearn
quickly and kick start working on the project independently.
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
Full CAN Controller
Basic CAN Controller
1. Full CAN uses Hardware buffer for message filtering.
2. It does not require the controller to be interrupted for each message
as it can filter from hardware level itself.
3. A single type of message can be received per mailbox using full CAN.
4. Full CAN configured Mail-Box supports Random Transaction Rate
(RTR) feature.
5. Full CAN feature is easy to code or configure in case of AUTOSAR
standard tools. Because it requires to configure all the parameters
need to be configure with some AUTOSAR CAN expert engineers.
6. Full CAN requires more memory as compared to Basic CAN, as it
needs to store more information about the network and the
messages being transmitted.
7. It takes less time and money in development due to its less
configuration.
8. Full CAN is typically used in larger networks where multiple nodes are
connected to the network and more advanced error handling and
filtering is required.

1. Basic CAN uses software buffer for message filtering.

2. Basic CAN requires the CPU to be interrupted every time a message
is received to determine whether it should be accepted.
3. Basic CAN configuration can accept messages with a range of
identifiers per mailbox.
4. Basic CAN configured Mail-Box does not supports Random
Transaction Rate (RTR) feature.
5. Basic CAN feature is complex to code or configure in case of
 AUTOSAR standard tools.
6. It does not uses any extra RAM memory as it stores pre-defined
register memory of CAN controller.
7. It takes more time to configure and more money in developement due
to its complex work feature.
8. Basic CAN is used in smaller networks where the number of nodes is
limited and a simpler communication architecture is sufficient

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.