What is Acceptance filter and mask in CAN protocol?

[Naren Rover]

Hi guys, I've been studying CAN protocol for a while and I can't understand Filter and Mask in CAN description . I'm referring PIC24H series for studying ECAN.
my Question is
1. why do we need Mask register?
2. won't the filter register be enough to accept incoming CAN messages?
3.How does filter and mask work in CAN?
4.Does each Filter has 3 mask registers or all 16 filters has 3 masks as common?
5.Why is CAN so difficult to learn?
6.Is there any resources I can refer to Learn CAN from basics , I can't seem to find one?

I'm sorry if these basic and silly questions but I can't understand those things...
Thank you in Advance

 

[rjenkinsgb]

Without looking at CAN docs myself at this instant..

Remember CAN is a broadcast system; each sensor or device regularly sends its data or status to the bus.
"What" device is sending is defined by the address it uses and generally similar function devices will be grouped in blocks - eg. in a car system, a block for lighting, a block for engine control, a block for windows etc.

Not all sensors or devices are useful to all other devices, so the filtering and masking part allows relevant blocks or devices to be monitored while ignoring other blocks that are no use.
eg. The engine management system does not need to listen to signals for the audio system or electric windows, but does need RPM, gear, throttle, wheel speed etc.


It just allows things to be pre-filtered so the actual receive software in each device has less work to do.

For your own devices using CAN between them, you can ignore all that stuff and just receive every data frame.

 

[dknguyen]

1, 2, 3:
The acceptance mask tells the peripheral what bits of the ID to ignore when doing the matching. The filter tells the peripheral what the bits of the ID need to be when they are not being ignored. Does that make sense?

Just to elaborate on what rjenkinsgb said, it allows you to send messages to just a single device or multi-drop a message to multiple devices. If you did not have a mask to ignore bits in an address, then you would either have to:

a. point-to-point normal messages but when a multi-drop is required you can only point-to-point an identical payload addressed to each device of interest
b. If all devices you wanted to multi-drop were made to shar the same address then you could just multi-drop but then you could never ever single-drop a message when required.

It's like having a family name or an area code. It lets you give identifiers that are unique to each device but also block them together so you can send individual messages or send a single message to everything in a group if necessary.

5. This isn't really objective fact. It's a very elegant interface. Maybe the problem is you are trying to study the CAN through a processor datasheet instead of studying it through a website that just talks conceptually about how CAN works. If you do it through a datasheet you're going to run into all the nitty gritty before you even know the high level concepts of how the CAN bus works.

I had a good CAN bus website bookmarked that went through everything:
https://www.softing.com/home/en/ind...-bus/more-can-bus/index.php?navanchor=3010320

But it doesn't seem to exist at that link anymore. It went through everything. The elecrical layer, the software layer, why certain things existed and what issues they dealt with. What features existed and what they were used for.

But starting with something like this:
https://www.ni.com/white-paper/2732/en/

Is much better than starting in a MCU datasheet.

6. What do you mean by "learn"? How far are you trying to go? If you are trying to set up a peripheral you don't know, then you do the following:

1. first go get a rough conceptual idea of how it works elsewhere.
2. skim that section in the datasheet just get familiarity with the terms and kinds of things in it
3. Go through the register list one at a time and type out each and every configuration bit and register and put a comment beside it of what it is. Just set the bits to write to zero or registers fields to write to zero because you'll come back afterwards and actually set it to what it needs to be. Give it a good comment that will let you at least 75% know what the hell it does the next morning. I comment in what each bit setting does if it's not really obvious from the name so I don't have to look at the datasheet each time.

4. Then after all that now go through that code and set everything you know or kinda know what it needs to be (referencing the rest datasheet if necessary). Mark and skip the things that seem irrelevant to your purposes or you have no idea what they are.

5. Then go back and for each of the irrelevant or unknown things check the datasheet or manuals and figure out what it is.

It's a lot easier by then because you have a good idea of what's in the peripheral and you aren't focusing on a bunch mass of unknown all at the same time ironing out the kinks that you're really not familiar with.

 

[Naren Rover]

Thnk you guys Very much for you valuable feed backs...Actually i do understand some basic concepts of CAN protocol. What is my difficult part is to code for CAN receive . It's my first time working with PIC24H - 16 bit controller and it is really driving me crazy
as dknguyen stated i read through 24H datasheet and there are so much registers in it to read and many of them i can't even understand why they are used.I found a Applications note AN1249 by Microchip on this subject which I am reading through right now.
will update you guys if i have further doubts. I hope you guys will help me through it

 

[rjenkinsgb]

The CCS C compiler includes an excellent CAN library for PIC24 and DSPIC devices...

All you need with that is to initialise it, then check for any receive packets regularly, or send a packet...

can_init();
can_enable_b_transfer(TRB0);
....


if ( can_kbhit() ) {
        // Get data
        if(can_getd(rx_id, &buffer[0], rx_len, rxstat)) {
        .....

Unfortunately it's their copyright and the only way to get it is to buy the CCS compiler - but I'd say that is worthwhile if you are seriously looking at developing a CAN based device.

One of these is also very useful; I managed to get a good used one on ebay; they work with PC software to display or transmit CAN data, which is good to interact with a device under development:
https://www.zlg.com/tpl/zlg/Public/img/canbus/USBCAN_2E_U.jpg

 

[dknguyen]

Thnk you guys Very much for you valuable feed backs...Actually i do understand some basic concepts of CAN protocol. What is my difficult part is to code for CAN receive . It's my first time working with PIC24H - 16 bit controller and it is really driving me crazy
as dknguyen stated i read through 24H datasheet and there are so much registers in it to read and many of them i can't even understand why they are used.I found a Applications note AN1249 by Microchip on this subject which I am reading through right now.
will update you guys if i have further doubts. I hope you guys will help me through it

Yeah, no other way around it. Writing a buffering and serial parsing code does take a long time. I'm writing a version 2 for work right now and it's taking forever. It's actually a bit easier for CAN since it takes care of you since a bunch of the filtering, addressing, buffering, and signalling stuff is taken cared of for you in hardware already...as long as you figure out how to set it up.

It helps a LOT if you can get a way to view the CAN bus on the PC and see what the MCU is sending, because if you are making CAN code then and need to program two devices just so they can send messages back and forth to each other so you can see if things are sending and receiving properly, you're debugging two things at once blindly which is a nightmare. I needed this when I was coding for RS-485 but it might be a little less useful for CAN bus since it does take care of a lot of things in hardware for you already.