liam-geotab opened a new pull request, #20330:
URL: https://github.com/apache/nuttx/pull/20330
## Summary
The changes in the PR are in service of a new CAN socket driver for stm32h5.
### New CAN socket IOCTL requests
SIOCGCANLISTENONLY, SIOCSCANLISTENONLY with arg ifru_can_listenonly.
If the driver supports it, the CAN interface shall operate in listen-only
mode.
SIOCGCANABORTTX, SIOSCANABORTTX with arg ifru_can_aborttx.
If the driver supports it, the CAN interface shall shall abort TX frames
upon TX error.
Both get/set the flag. The union member type is uint32_t and the value is 0
or 1.
### Add can_input_confirm to can.h
Add can_input_confirm to "Handle transmission echo confirmation packet".
Impacts can_recvmsg. Calls netdev_input.
### Use throttled IOB for can_input_confirm
Add a fourth parameter to netdev_input: bool throttled. It is forwarded to
netdev_iob_prepare and iob_trycopyin which were passed false previously. Pass
false at all call sites except in can_input_confirm, where true is passed.
Throttled IOB is used for can_input_confirm.
### **Add STM32H5 alternative CAN driver**
The existing driver is a chardev CAN driver selected by
CONFIG_STM32_FDCAN_CHARDRIVER. Add a socket CAN driver "stm32_fdcan_socket.c"
selected by CONFIG_STM32_FDCAN_SOCKET.
It loosely resembles stm32h7 stm32_fdcan_sock.c but has been reworked and
iterated upon and is its own unique version.
### Add IOB reserve config for CAN confirm frames
Adds config NET_CAN_IOB_CONFIRM. Only relevant for the new CAN input confirm.
## Impact
### New CAN socket IOCTL requests
It should be scrutinized for whether it is a frivolous setting. Maybe it
belongs in a driver-level header or the flag can be folded into another IOCTL
such as SIOCSIFFLAGS. @dakejahl I saw that this might be an area you can
comment on.
### Add can_input_confirm to can.h
**Uses a reserved/padding field to store data!**
### Use throttled IOB for can_input_confirm
Adds a new parameter to netdev_input which is a central API. It's been
updated everywhere in the nuttx tree but is still an out-of-tree build-breaking
change. The value to pass to keep compatibility is "false".
### **Add STM32H5 alternative CAN driver**
Is the name "stm32_fdcan_socket.c" okay?
It imposes board.h definition requirements for STM32H5_FDCANx_PWR and
STM32H5_FDCANx_PWR_STANDBY.
### Add IOB reserve config for CAN confirm frames
Reads a reserved/padding field which is used by the new CAN input confirm
feature. @OceanfromXiaomi you had recently worked on a related struct. Please
review if you want.
## Testing
Testing/validation was done on custom hardware that uses STM32H563ZI. The
CAN bus has a device attached which can both log received CAN frames and
transmit arbitrary CAN frames.
board.h was given GPIO_FDCAN1_RX, GPIO_FDCAN1_TX, GPIO_FDCAN2_RX,
GPIO_FDCAN2_TX, STM32H5_FDCAN1_PWR, STM32H5_FDCAN1_PWR_STANDBY,
STM32H5_FDCAN1_PWR, STM32H5_FDCAN1_PWR_STANDBY, STM32_FDCAN_FREQUENCY,
STM32_RCC_CCIPR5_FDCANSEL (for rcc file).
Enable:
```
CONFIG_CAN=y
CONFIG_CANUTILS_CANDUMP=y
CONFIG_CANUTILS_CANSEND=y
CONFIG_CANUTILS_LIBCANUTILS=y
CONFIG_CAN_ERRORS=y
CONFIG_CAN_EXTID=y
CONFIG_CAN_FD=y
CONFIG_NET=y
CONFIG_NETDEV_CAN_IOCTL=y
CONFIG_NETDEV_IFINDEX=y
CONFIG_NET_CAN=y
CONFIG_NET_CAN_ERRORS=y
CONFIG_NET_CAN_IOB_CONFIRM=2
CONFIG_NET_CAN_SOCK_OPTS=y
CONFIG_SCHED_HPWORK=y
CONFIG_STM32_FDCAN1=y
CONFIG_STM32_FDCAN2=y
CONFIG_STM32_FDCAN_SOCKET=y
```
### **Add STM32H5 alternative CAN driver**
Sending data out to the peer CAN device.
```
nsh> ifup can0
ifup can0...OK
nsh> cansend can0 123#DEADBEEF
nsh>
```
The peer sees the frame with correct ID and payload.
Receiving repeated alternating CAN frames from the peer CAN device.
```
nsh> candump can0
can0 11000614 [8] 01 02 03 04 05 06 07 08
can0 125 [2] 67 76
can0 11000614 [8] 01 02 03 04 05 06 07 08
can0 125 [2] 67 76
```
### New CAN socket IOCTL requests
#### Listen-only
```diff
diff --git a/canutils/candump/candump.c b/canutils/candump/candump.c
index 58958a46f..c5504f4d1 100644
--- a/canutils/candump/candump.c
+++ b/canutils/candump/candump.c
@@ -577,6 +577,15 @@ int main(int argc, char **argv)
}
}
+ struct ifreq arg = {
+ .ifr_name = "can0",
+ .ifr_ifru.ifru_can_listenonly = 1
+ };
+ if(ioctl(s[0], SIOCSCANLISTENONLY, &arg)) {
+ perror("ioctl");
+ return 1;
+ }
+
if (log) {
time_t currtime;
struct tm now;
diff --git a/canutils/cansend/cansend.c b/canutils/cansend/cansend.c
index 42fcffc79..07edcca16 100644
--- a/canutils/cansend/cansend.c
+++ b/canutils/cansend/cansend.c
@@ -186,6 +186,15 @@ int main(int argc, char **argv)
return 1;
}
+ struct ifreq arg = {
+ .ifr_name = "can0",
+ .ifr_ifru.ifru_can_listenonly = 1
+ };
+ if(ioctl(s, SIOCSCANLISTENONLY, &arg)) {
+ perror("ioctl");
+ return 1;
+ }
+
/* send frame */
if (write(s, &frame, required_mtu) != required_mtu)
```
Sending:
```
nsh> ifup can0
ifup can0...OK
nsh> cansend can0 123#DEADBEEF
nsh>
```
The peer sees nothing! In listen-only mode, nothing is transmitted.
Receiving:
```
nsh> candump can0
can0 11000614 [8] 01 02 03 04 05 06 07 08
can0 11000614 [8] 01 02 03 04 05 06 07 08
can0 125 [2] 67 76
can0 125 [2] 67 76
```
Data is recieved as normal in listen-only mode. Although, the frame
reception order is not the same. I can't explain why in this moment.
#### Abort TX on error
Same diff, replace SIOCSCANLISTENONLY with SIOCSCANABORTTX and
ifru_can_listenonly with ifru_can_aborttx.
Sending:
When SIOCSCANABORTTX is *not* enabled and the peer is unresponsive, the
transmission blocks upon trying to send a second frame so the workflow is stuck.
```
nsh> ifup can0
ifup can0...OK
nsh> cansend can0 123#DEADBEEF
nsh> cansend can0 123#DEADBEEF
```
When SIOCSCANABORTTX is enabled and the peer is unresponsive, there is no
blocking despite the unresponsive peer.
```
nsh> ifup can0
ifup can0...OK
nsh> cansend can0 123#DEADBEEF
nsh> cansend can0 123#DEADBEEF
nsh> cansend can0 123#DEADBEEF
nsh> cansend can0 123#DEADBEEF
nsh> cansend can0 123#DEADBEEF
nsh> cansend can0 123#DEADBEEF
nsh>
```
Receiving:
```
nsh> candump can0
can0 11000614 [8] 01 02 03 04 05 06 07 08
can0 125 [2] 67 76
can0 11000614 [8] 01 02 03 04 05 06 07 08
can0 125 [2] 67 76
```
Data is recieved as normal in abort-tx-on-error mode.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
