-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
drivers/mcp2515: enable filtering #18062
drivers/mcp2515: enable filtering #18062
Conversation
3dfdad6
to
c9bcbfd
Compare
22646f0
to
9fa1535
Compare
9fa1535
to
fcfbf78
Compare
drivers/mcp2515/candev_mcp2515.c
Outdated
@@ -421,7 +421,7 @@ static int _get(candev_t *candev, canopt_t opt, void *value, size_t max_len) | |||
static int _set_filter(candev_t *dev, const struct can_filter *filter) | |||
{ | |||
DEBUG("inside _set_filter of MCP2515\n"); | |||
bool filter_added = true; | |||
bool filter_added = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like before this change, filter_added
was always true. However, that doesn't mean this function always returned true, because on failures -1 was returned.
Currently there's three types of returns in this function: bool filter_added
, int res
and regular -1
indicating failures. Maybe it might be a good opportunity to streamline this?
0 means success (filter added), any negative number indicates an error.
tests/candev/main.c
Outdated
|
||
/* do not care, receive all message id */ | ||
} | ||
/* Add filters here when needed. Currently do not care, receive all message id */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add an example on how to use it? The reason for writing this candev application was because the CAN system was extremely complex before. This showed a very basic and easy way to use CAN in RIOT. Now that you've enabled another feature, maybe this feature can also be demonstrated in the candev test?
686120d
to
58f8bfe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
Only checked code, did not test it out on hardware.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, after checking out the other PR, it dawned on me... now that we changed the return type... do we still need this filter_added variable? It's being set, but no longer returned.
The only place where it's still being used for something useful, is to break out of this while loop. But maybe we can replace that with a simply break
statement?
(Github didn't link my comment to the relevant line. I must have done something wrong here. This comment relates to line 456 in file drivers/mcp2515/candev_mcp2515.c)
Another question: Now that you've set the filters in the test-application, shouldn't the RX_callback also be adapted? It currently does not take into account mailboxes. |
IMHO I think it shouldn't be adapted because the driver itself considers the mailboxes when triggering the reception interrupts (INT_RX0 or INT_RX1). So the RX callback will keep receiving only the data matching the filters and to see on which mailbox the data is received, the debug should be enabled in |
Did you forget to push? I don't think I see the changes? |
Sorry you're right! Fixed now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
f1f7626
to
0bf4a54
Compare
Rebased and squashed commits |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Proxy-ACK for @wosym
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for late reply. Since it's only a rebase&squash, still all good for me.
There's just one question I would raise: do we really need to remove all those (unused) defines? What's the RIOT way of doing things in this case? For my personal projects I sometimes leave these defines in, because they can still be useful for when someone starts adapting this driver for his own personal use case. The current driver doesn't use all capabilities of this chip, but some user might need a specific function. For that user, it is useful that the registers are already defined and readily available.
Just my two cents. Doesn't need to block merging and can even be ignored.
drivers/mcp2515/mcp2515_defines.h
Outdated
#define MCP2515_RXB1CTRL_RXM0 0x20 | ||
#define MCP2515_RXB1CTRL_RXM1 0x40 | ||
#define MCP2515_RXB1CTRL_MODE_RECV_STD_OR_EXT 0x00 | ||
#define MCP2515_RXB1CTRL_MODE_RECV_STD MCP2515_RXB1CTRL_RXM0 | ||
#define MCP2515_RXB1CTRL_MODE_RECV_EXT MCP2515_RXB1CTRL_RXM1 | ||
#define MCP2515_RXB1CTRL_MODE_RECV_ALL (MCP2515_RXB1CTRL_RXM1 | \ | ||
MCP2515_RXB1CTRL_RXM0) | ||
#define MCP2515_RXB1CTRL_MODE_RECV_FILTER 0x00 | ||
#define MCP2515_RXB1CTRL_MODE_RECV_ALL 0x60 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that dropping the unused defines is unnecessary since they just encode information about the hardware and could become useful in the future.
drivers/mcp2515: enable filtering The current driver implementation initializes the driver in a way to receive all the CAN messages without matching the filters. This commit changes that by adding a macro definition that will be enabling or disabling the filtering and accordingly set the appropriate mcp2515 acceptance mode
0bf4a54
to
285ba27
Compare
Contribution description
The MCP2515 driver initialization sets the acceptance mode to receiving all packets without checking the filters set for each mailbox. This leads to the situation where the node is receiving all messages on the CAN bus.
This PR goal is to enable filtering the CAN messages that are having a CAN ID that matches the CAN filters.
Testing procedure
This was tested using a SAME54-xpro and a MCP2515 breakout board following these steps:
MCP2515_RECV_FILTER_EN