I am using a module to convert CAN to UART. This module has 2 programmable masks and 6 programmable filters.

There are 13 message IDs that come in over the CAN bus and I only want 9 of them. The IDs are as follows.

The messages I dont want :

 - 0x404
 - 0x6f1
 - 0x114
 - 0x11c

The ones I do want :

 - 0x36C
 - 0x33C 
 - 0x34C 
 - 0x35C 
 - 0x314 
 - 0x31C 
 - 0x324 
 - 0x32C 
 - 0x37C

I have found masking quite confusing and I would love if someone could help me better my understanding of it. Would I set my mask to 0x3ff or 0x300? Then the 0x11c messages will come in?

  • \$\begingroup\$ If the device excludes anything with non-mask bits, i.e. keeps anything where !(~MASK & ID) == true then MASK = 0x3ff will keep everything you want to keep, but I think you would still get the 0x11c and 0x114 \$\endgroup\$
    – Pete W
    Jan 10 '21 at 22:34
  • \$\begingroup\$ if it includes only codes with all the mask bits, then MASK = 0x300 and you're good \$\endgroup\$
    – Pete W
    Jan 10 '21 at 22:39
  • \$\begingroup\$ I need to make sure I dont have 0x3ff coming through unfortunately. I will try 0x300 now. Thanks :) \$\endgroup\$
    – Adam
    Jan 10 '21 at 23:10
  • \$\begingroup\$ Can't hurt to try! To make the question clearer for future readers, could you describe the logic of how the mask works? I described two possibilities, no idea which one your device actually implements, or if it is something else entirely. \$\endgroup\$
    – Pete W
    Jan 10 '21 at 23:11
  • 2
    \$\begingroup\$ Pete, Thank you very much. Filter at 0x300 and mask at 0x1FFFFF00 was the solution. \$\endgroup\$
    – Adam
    Jan 11 '21 at 15:25

If you want as many as 9 out of 13, then acceptance masking is pretty pointless. It is generally an overrated feature of CAN from the time before "mailbox" CAN controllers were invented. The main use of masking is when you expect a whole lot (hundreds) of identifiers on the bus that you aren't interested in.

Acceptance masking tends to make things needlessly complicated, which in turn leads to bugs. In this case you don't need to use neither masks nor mailboxes, just an identifier look-up table in software and sufficiently regular checks of the CAN rx buffers. Keep it simple.

  • \$\begingroup\$ The problem is that the frequency of the ones I dont want is really fast. I dont want my main processor to have to deal with conditions for these. \$\endgroup\$
    – Adam
    Jan 11 '21 at 15:17
  • \$\begingroup\$ @Adam Then something is off with your design. Most CAN controllers at least have a FIFO buffer option. You just need to empty the (whole) FIFO as regularly as FIFO size multiplied by the time to send a short CAN message with your given baudrate. If your MCU can't handle that requirement, it will go haywire whenever unexpected CAN traffic appears on the bus. If polling is not an option, then as mentioned there are other modern ways to deal with the problem: CAN controller mailboxes or DMA. If that's still not an option, then the problem is that you picked an ancient crappy CAN controller. \$\endgroup\$
    – Lundin
    Jan 12 '21 at 8:08
  • \$\begingroup\$ @Adam Also, "CAN to UART" implies that you must act very quickly on every CAN frame to reduce latency overhead caused by your gateway. A gateway firmware can't sit around doing other stuff while there's pending traffic in rx buffers. What MCU and/or CAN controller are you using? \$\endgroup\$
    – Lundin
    Jan 12 '21 at 8:11

Pete W answered with the help of the following link : http://www.cse.dmu.ac.uk/~eg/tele/CanbusIDandMask.html

The solution was a filter for 0x300 and a mask of 0x1FFFFF00


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.