Difference between Basic and Full CAN
Initially there was only one “CAN controller”, which was designed to have some amount of object buffers. This was the now deceased Intel 82526 (up to 5 message buffers). It was followed by the 82527 with 15 message buffers. Then Philips tried to cut cost to produce a even cheaper version, hence 82C200 which has two receive buffers and one transmit buffer, and of course the partial mask-match filtering as well. In order to differentiate between these two CAN controllers, some guys started to call the original version as FullCAN, and the low cost version as BasicCAN.
There is no real definition of what FullCAN and BasicCAN is in the spec, only by manufacturers. FullCAN should really be called DPRAM mode instead, since the underlying paradigm is a DPRAM, and the BasicCAN should really be called FIFO mode instead. Note that FullCAN is in no way a fuller implementation of CAN than is BasicCAN.
The original 82527 implementation was later used by Siemens in their controllers and can now be found in devices like C505C/C515C/C164/C167 etc.
New CAN controllers extend the basic functionality, e.g they have up to 32 object buffers as FullCAN implementation, or they have a large FIFO for several messages like the Philips SJA1000, called PeliCAN, as a BasicCAN implementation. With many controllers you can have a mix of these. They are basically implemented as FullCAN, but you can use some of the object buffers to build FIFOs and use them as BasicCAN.
Often the question arrives: Which CAN controller is the best to use?
FullCAN and BasicCAN are two different principles in the architecture of a CAN controller. Full CAN controllers do have normally more than one so called message object buffers. The acceptance registers can be programmed in this way, that only one specific message (or a group) is passed into this object. Most implementations do not buffer messages for such a object in a receive queue, that means a following message passing the acceptance filter will replace the previous one, and the old message is lost. If two messages with the same ID but different data are sent very fast (consider: 11 bit ID, 2 data bytes, 1Mbit/s =app. 70 us) the CPU has to transfer the content of the message buffer before the second message arrives and overwrites the first one.
Typical BasicCAN controllers (Philips SJA1000) have a receive queue and no message buffers per se.
What principle is better depends really of the application. If an application only uses a number of different messages that is smaller then the number of message objects in hardware, then a FullCAN could be the best. Newer CPUs integrate two CAN controllers. If the two CAN controllers can share the same RX/TX pins, we have 32 message objects. On the other hand, if you want to see all messages in the system you should use a FIFO-style CAN controller.
CAN's maximum defined speed is 1 Mbit/s, it can happen that you get an interrupt every approximately 55 us (frames without data). It depends on the system load. (Ethernet, serial, PID-loop, etc.) All of these have interrupt latencies and different priorities that may affect CAN Bus reception, although having 15 message buffers helps with buffering, and reduces the chance of a lost CAN frame.
New CAN controllers like the Infineon SAK82C900 can be used in two ways: ( oe: Infineon SAK82C900 is obsolete since 2006 or so)
- using each of the available (32 at the 82C900) message object buffers as a FullCAN like buffers,
- arranging 2,4,8,16 or 32 message buffers to build a FIFO buffer so they are offering the positive advantages from both worlds.
— Heinz-Jürgen Oertel 2013/03/21 10:45, used some ideas from Dr K H Tang and Lars Wictorsson