Vector support using XL Driver (#68)

* WIP

* WIP

* WIP

* Almost finished all init for Vector

* Fixed issue

* WIP

* Stashing before update from Tom machine

* Added changes for working vector

* Removed vector example

* Removed windows dir

* Removed vector adapter test

* Reverted permissions

* Reverted formatting

* Make basic Tx/Rx working

* Get config based on glabal channel index

* Pass adapter tests

* bring in latest test from main

* weird diff

* Add todo

* Fix clippy

* Add behind feature

* fmt

* Small cleanup

* Properly gate build script on features

* Disable vector by default because of dll

* Update README.md

* Update README.md

* Delete vector.rs

---------

Co-authored-by: Willem Melching <[email protected]>

.gitignore

@@ -1,2 +1,5 @@
 /target
 .vscode/
+
+windows/
+bindings.rs

Cargo.toml

@@ -10,11 +10,19 @@ repository = "https://github.com/I-CAN-hack/automotive"
 # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
 
 [features]
-all = []
+default = []
+all = ["all-adapters", "serde"]
+all-adapters = ["vector-xl"]
+serde = ["dep:serde"]
+
+# adapters
+vector-xl = []
+
+# adapter tests
 test_panda = []
 test_socketcan = []
+test_vector = []
 test_vcan = []
-serde = ["dep:serde"]
 
 [dependencies]
 async-stream = "0.3.5"
@@ -37,3 +45,6 @@ libc = "0.2.154"
 futures = "0.3.30"
 tracing-subscriber = "0.3"
 serial_test = "3.0.0"
+
+[target.'cfg(target_os = "windows")'.build-dependencies]
+bindgen = "0.69.4"

README.md

@@ -47,20 +47,23 @@ The following CAN adapters are supported.
 ### Supported CAN adapters
  - SocketCAN (Linux only)
  - comma.ai panda (all platforms using [rusb](https://crates.io/crates/rusb))
+ - Vector Devices (Windows x64 only)
 
 ### Known limitations / Notes
 This library has some unique features that might expose (performance) issues in drivers you wouldn't otherwise notice, so check the list of known limitations below.
 
 This library supports awaiting a sent frame and waiting for the ACK on the CAN bus. This requires receiving these ACKs from the adapter, and matching them to the appropriate sent frame. This requires some level of hardware support that is not offered by all adapters/drivers. If this is not supported by the driver, an ACK will be simulated as soon as the frame is transmitted, but this can cause issues if precise timing is needed.
 
- - SocketCAN drivers without `IFF_ECHO`: This class of SocketCAN drivers has no hardware support for notifying the driver when a frame was ACKed. This is instead emulated by the [Linux kernel](https://github.com/torvalds/linux/blob/master/net/can/af_can.c#L256). Due to transmitted frames immediately being received again this can cause the receive queue to fill up if more than 476 (default RX queue size on most systems) are transmitted in one go. To solve this we implement emulated ACKs ourself, instead of relying on the ACKs from the kernel.
+ - SocketCAN Devices
+   - SocketCAN drivers without `IFF_ECHO`: This class of SocketCAN drivers has no hardware support for notifying the driver when a frame was ACKed. This is instead emulated by the [Linux kernel](https://github.com/torvalds/linux/blob/master/net/can/af_can.c#L256). Due to transmitted frames immediately being received again this can cause the receive queue to fill up if more than 476 (default RX queue size on most systems) are transmitted in one go. To solve this we implement emulated ACKs ourself, instead of relying on the ACKs from the kernel.
+   - PCAN-USB: The Peak CAN adapters have two drivers:
+     - Kenel built in driver (`peak_usb`). The kernel driver properly implements `IFF_ECHO`, but has a rather small TX queue. This should not cause any issues, but it can be inreased with `ifconfig can0 txqueuelen <size>`.
+     - Out-of-tree driver (`pcan`) that can be [downloaded](https://www.peak-system.com/fileadmin/media/linux/index.htm) from Peak System's website. The out-of-tree driver is not recommended as it does  not implement `IFF_ECHO`.
+   - neoVI/ValueCAN: Use of Intrepid Control System's devices is not recommended due to issues in their SocketCAN driver. If many frames are transmitted simultaneously it will cause the whole system/kernel to hang. [intrepid-socketcan-kernel-module#20](https://github.com/intrepidcs/intrepid-socketcan-kernel-module/issues/20) tracks this issue.
  - comma.ai panda
    - The panda does not retry frames that are not ACKed, and drops them instead. This can cause panics in some internal parts of the library when frames are dropped. [panda#1922](https://github.com/commaai/panda/issues/1922) tracks this issue.
    - The CAN-FD flag on a frame is ignored, if the hardware is configured for CAN-FD all frames will be interpreted as FD regardless of the FD frame bit (r0 bit).
- - PCAN-USB: The Peak CAN adapters have two drivers:
-   - Kenel built in driver (`peak_usb`). The kernel driver properly implements `IFF_ECHO`, but has a rather small TX queue. This should not cause any issues, but it can be inreased with `ifconfig can0 txqueuelen <size>`.
-   - Out-of-tree driver (`pcan`) that can be [downloaded](https://www.peak-system.com/fileadmin/media/linux/index.htm) from Peak System's website. The out-of-tree driver is not recommended as it does  not implement `IFF_ECHO`.
-  - neoVI/ValueCAN: Use of Intrepid Control System's devices is not recommended due to issues in their SocketCAN driver. If many frames are transmitted simultaneously it will cause the whole system/kernel to hang. [intrepid-socketcan-kernel-module#20](https://github.com/intrepidcs/intrepid-socketcan-kernel-module/issues/20) tracks this issue.
+ - Vector Devices are supported through the Vector XL Driver Library, and support can be enabled using the `vector-xl` feature. Make sure to distribute `vxlapi64.dll` alongside your application.
 
 
 ### Implementing a New Adapter