Skip to content
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

Merged
merged 2 commits into from
Jun 26, 2022

Conversation

firas-hamdi
Copy link
Contributor

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:

  • Enable filtering macro MCP2515_RECV_FILTER_EN
  • Set the CAN filters for both mailboxes to reject totally the CAN message. If not, the message will be accepted on the second mailbox (according to Figure4.3 in the MCP2515 datasheet)
  • Send CAN messages with matching and not matching CAN IDs

@github-actions github-actions bot added Area: drivers Area: Device drivers Area: tests Area: tests and testing framework labels May 5, 2022
@benpicco benpicco requested review from wosym and fjmolinas May 5, 2022 22:03
@firas-hamdi firas-hamdi force-pushed the mcp2515-enable-filtering branch from 3dfdad6 to c9bcbfd Compare May 9, 2022 14:36
@benpicco benpicco requested review from vincent-d and toonst May 10, 2022 09:12
@firas-hamdi firas-hamdi force-pushed the mcp2515-enable-filtering branch 4 times, most recently from 22646f0 to 9fa1535 Compare May 11, 2022 12:17
@github-actions github-actions bot added the Area: tools Area: Supplementary tools label May 11, 2022
@firas-hamdi firas-hamdi force-pushed the mcp2515-enable-filtering branch from 9fa1535 to fcfbf78 Compare May 11, 2022 13:58
@@ -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;
Copy link
Member

@wosym wosym May 15, 2022

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.


/* do not care, receive all message id */
}
/* Add filters here when needed. Currently do not care, receive all message id */
Copy link
Member

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?

Copy link
Member

@wosym wosym left a 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.

Copy link
Member

@wosym wosym left a 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)

@wosym
Copy link
Member

wosym commented May 27, 2022

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.

@firas-hamdi
Copy link
Contributor Author

firas-hamdi commented Jun 7, 2022

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 candev_mcp2515.c

@firas-hamdi firas-hamdi requested a review from wosym June 7, 2022 13:46
@wosym
Copy link
Member

wosym commented Jun 10, 2022

Did you forget to push? I don't think I see the changes?

@firas-hamdi
Copy link
Contributor Author

Did you forget to push? I don't think I see the changes?

Sorry you're right! Fixed now

Copy link
Member

@wosym wosym left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

@firas-hamdi firas-hamdi force-pushed the mcp2515-enable-filtering branch from f1f7626 to 0bf4a54 Compare June 17, 2022 14:58
@firas-hamdi
Copy link
Contributor Author

Rebased and squashed commits

@firas-hamdi firas-hamdi requested a review from wosym June 21, 2022 12:22
Copy link
Contributor

@benpicco benpicco left a 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

@benpicco benpicco added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Jun 24, 2022
@gschorcht gschorcht changed the title MCP2515: enable filtering drivers/mcp2515: enable filtering Jun 25, 2022
Copy link
Member

@wosym wosym left a 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.

Comment on lines 315 to 311
#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
Copy link
Contributor

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
@benpicco benpicco force-pushed the mcp2515-enable-filtering branch from 0bf4a54 to 285ba27 Compare June 26, 2022 15:38
@benpicco benpicco added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Jun 26, 2022
@benpicco benpicco merged commit d9fc082 into RIOT-OS:master Jun 26, 2022
@chrysn chrysn added this to the Release 2022.07 milestone Aug 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: drivers Area: Device drivers Area: tests Area: tests and testing framework Area: tools Area: Supplementary tools CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants