periph_can,candev: socketcan pkg for native, candev test cleanup

[DanielLockau-MLPA]

Contribution description

• add libsocketcan as a package to resolve its reduced availability (Ubuntu dropped it for i386 builds)
• allow switching between OS provided and package provided libsocketcan for cpu/native
• make tests/candev more readable

Testing procedure

On Ubuntu 20.04 with libsocketcan2:amd64 available, libsocketcan-dev available, libsocketcan2:i386 unavailable.

In tests/candev:

• make -j BOARD=native CAN_DRIVER=PERIPH_CAN should fail
• make -j BOARD=native CAN_DRIVER=PERIPH_CAN USEPKG=libsocketcan should build
• sudo modprobe vcan; sudo ip link add dev vcan0 type vcan; sudo ip link set up dev vcan0 should create a virtual can device
• install can-utils for the OS
• run the native build, run candump vcan0 in another terminal
• run receive in the native build's terminal
• run cansend vcan0 1234567f#123456 in another terminal -> both candump and the native build's terminal should show similar output
• run send 1 2 3 4 in the native build's terminal -> candump should show the data

Issues/PRs references

None.

[benpicco]

Can't we

USEPKG += libsocketcan

here to make sure this is compile tested by CI?

[aabadie]

By adding the following in a Makefile.board.dep, that should be possible:

ifeq (native,$(BOARD))
  USEPKG += libsocketcan
endif

[aabadie]

Or just in the Makefile.dep of native cpu if the periph_can feature is used => that would be my preferred solution

[fjmolinas]

@DanielLockau-MLPA could you apply the following patch?

diff --git a/boards/native/Makefile.dep b/boards/native/Makefile.dep
index f0e996ae56..dedea2cc63 100644
--- a/boards/native/Makefile.dep
+++ b/boards/native/Makefile.dep
@@ -9,6 +9,7 @@ ifneq (,$(filter mtd,$(USEMODULE)))
 endif

 ifneq (,$(filter periph_can,$(FEATURES_USED)))
+  USEPKG += libsocketcan
   ifeq ($(OS),Linux)
     CFLAGS += -DCAN_DLL_NUMOF=2
   endif
diff --git a/tests/candev/Makefile b/tests/candev/Makefile
index 7f956d7406..b323ce96e0 100644
--- a/tests/candev/Makefile
+++ b/tests/candev/Makefile
@@ -1,21 +1,7 @@
-BOARD ?= nucleo-f767zi
-
 include ../Makefile.tests_common

 USEMODULE += shell
 USEMODULE += can
 USEMODULE += isrpipe

-
-# define the CAN driver you want to use here
-CAN_DRIVER ?= MCP2515
-
-ifeq ($(CAN_DRIVER), PERIPH_CAN)
-  FEATURES_REQUIRED += periph_can
-else ifeq ($(CAN_DRIVER), MCP2515)
-  USEMODULE += mcp2515
-else ifeq ($(CAN_DRIVER), CAN_ALT)
-  # other can modules can be defined here
-endif
-
 include $(RIOTBASE)/Makefile.include
diff --git a/tests/candev/Makefile.board.dep b/tests/candev/Makefile.board.dep
new file mode 100644
index 0000000000..3ccc5453ed
--- /dev/null
+++ b/tests/candev/Makefile.board.dep
@@ -0,0 +1,14 @@
+ifneq (,$(filter native,$(BOARD)))
+  CAN_DRIVER ?= PERIPH_CAN
+endif
+
+# define the CAN driver you want to use here
+CAN_DRIVER ?= MCP2515
+
+ifeq ($(CAN_DRIVER), PERIPH_CAN)
+  FEATURES_REQUIRED += periph_can
+else ifeq ($(CAN_DRIVER), MCP2515)
+  USEMODULE += mcp2515
+else ifeq ($(CAN_DRIVER), CAN_ALT)
+  # other can modules can be defined here
+endif

I tested that it works, I'll ACK right away:

Initializing CAN periph device
> receive
receive
Reading from Rxbuf...
id: 1234567f dlc: 3 data: 0x12 0x34 0x56
> send 1 2 3 4
send 1 2 3 4
> ^C
native: exiting

[DanielLockau-MLPA]

@DanielLockau-MLPA could you apply the following patch?

@fjmolinas I tried it locally but it seems to refer to a rebased version of this branch to a recent version of RIOT/master. Your patch touches code which was added by @kfessel to upstream but not by me. I will still rebase & apply as this part should only concern the CI, if anything.

[fjmolinas]

@DanielLockau-MLPA could you apply the following patch?

@fjmolinas I tried it locally but it seems to refer to a rebased version of this branch to a recent version of RIOT/master. Your patch touches code which was added by @kfessel to upstream but not by me. I will still rebase & apply as this part should only concern the CI, if anything.

Since I was not able to push, I opened a PR with your changes rebased #17967, ci seems to be passing so far, if its green maybe we can just get that one in to avoid another CI run? I don't really mind either way, I opened the PR just to get this in faster :)

[DanielLockau-MLPA]

Since I was not able to push, I opened a PR with your changes rebased #17967, ci seems to be passing so far, if its green maybe we can just get that one in to avoid another CI run? I don't really mind either way, I opened the PR just to get this in faster :)

Damn. I just did the push. I don't mind as well. You can just go with your PR. Seems cleaner to me as well.

[fjmolinas]

Since I was not able to push, I opened a PR with your changes rebased #17967, ci seems to be passing so far, if its green maybe we can just get that one in to avoid another CI run? I don't really mind either way, I opened the PR just to get this in faster :)

Damn. I just did the push. I don't mind as well. You can just go with your PR. Seems cleaner to me as well.

Let's see what happens faster, this PR finishing building or another maintainer taking a look at #17967, maybe @benpicco could proxy-ACK that one.

[fjmolinas]

ACK, tested, and murdock is building this now! ACK

[fjmolinas]

Thanks @DanielLockau-MLPA!