I mean chapter "18.4.3 Identifier Acceptance Filter", in particular figure 18-40 for receiving messages. I think that with 2 32bit masks (1 for standard protocol and the other for extended) the reception is possible.
I can receive both standard (e.g. 0x500, 0x518, 0x570, ...) and extended (e.g. 0x18DAC3F1).
Again, understanding of all of this is in these two pictures:
The difference is IDE bit. Then, since Std and Ext ID bit mapping in buffer and acceptance filters is different, you need one filter(s) for standard message(s) and another one(s) for extended message(s). If you do it wrong (the same filter for both Std and Ext), you may falsely accept standard ID=1 (ID0 bit = 1) message in filter for extended ID=(1<<18) = 0x40000 (ID18 bit = 1). Do you see already that they are in the same locations? Message filters have the same mapping as ID bits in message tx/rx buffers.
Here’s what ID, RTR, IDE etc bits different filters apply to:
As you may see to make filter properly filtering correctly standard or extended messages from the mix of Std and Ext messages, filter has to include IDE bit location, that’s why 16 and 32 bit filters are good for your application and 8 bit filters are not good.
standard (e.g. 0x500, 0x518, 0x570, ...) to msg buffer
IDR0 = (unsigned int)id >> 3;
IDR1 = id << 5;
Back to id
Id = ((unsigned int) IDR1 >> 5) + ((unsigned int)IDR0 << 3);
extended (e.g. 0x18DAC3F1) to msg buffer
IDR3 = id << 1;
IDR2 = id >> 7;
IDR1 = ((id >> 15) & 7) | 0x18 | ((id >> (18-5)) & 0xE0);
IDR0 = id >> 21;
All these shifts are very slow and ineffective on S12(X). It would be better if you could use compile time constants for ID mappings or at least calculate them few times and reuse many times. But that’s up to you.
