canalystii: Fix transmitting onto a busy bus

[projectgus]

This is to fix the issue that the CANalystIIBus interface works fine in a quiet setup (like a loopback test) but randomly fails to send messages if the bus is busy.

The "SendType" field has at least two possible values, and value 1 causes the firmware to drop the message if there is bus contention when sending it.

I can make this into a configuration parameter if you prefer, just let me know. I was going to do this but then I couldn't really think of a use case for unreliable transmission. (With SendType 1, there isn't anything in the protocol to tell the software that the message was dropped, it's just silently dropped!)

Also made a small addition in the docs to note the binary library dependency.

Thanks for maintaining this library, it's been a pleasure to work with! (Well, after I worked out why I was randomly losing messages! 😆)

[projectgus]

Also, I have a question: initially when I was debugging this I thought the root cause was a USB race condition in the firmware buffers so I spent some time reverse engineering the USB protocol. In fact I've recreated the entire driver without the binary library, using libusb1. This version has (I think) the same functionality, probably slightly higher performance, and allows customizing the number of messages buffered by software.

... then I realised about the SendType parameter, of course.

If I polished the libusb based driver up a bit, would you be interested in replacing the current binary library driver?

[hardbyte]

Also, I have a question: initially when I was debugging this I thought the root cause was a USB race condition in the firmware buffers so I spent some time reverse engineering the USB protocol. In fact I've recreated the entire driver without the binary library, using libusb1. This version has (I think) the same functionality, probably slightly higher performance, and allows customizing the number of messages buffered by software.

... then I realised about the SendType parameter, of course.

If I polished the libusb based driver up a bit, would you be interested in replacing the current binary library driver?

Yes that sounds great! If you package it up for Pypi we can set it as an optional dependency and have another backend that doesn't require manual driver installation.

[codecov]

Codecov Report

Merging #1114 (1adde85) into develop (5b63bb2) will increase coverage by 0.00%.
The diff coverage is 100.00%.

❗ Current head 1adde85 differs from pull request most recent head 4f7cf12. Consider uploading reports for the commit 4f7cf12 to get more accurate results

@@           Coverage Diff            @@
##           develop    #1114   +/-   ##
========================================
  Coverage    70.49%   70.50%           
========================================
  Files           79       79           
  Lines         7666     7668    +2     
========================================
+ Hits          5404     5406    +2     
  Misses        2262     2262           

[projectgus]

Yes that sounds great! If you package it up for Pypi we can set it as an optional dependency and have another backend that doesn't require manual driver installation.

@hardbyte No problems, will try to sort this out in the next few weeks and submit a new PR for it. To check I'm understanding correctly: you'd prefer me to follow a model like the gs_usb support - where I maintain a "canalystii" package in pypi, rather than putting that part of the driver into python-can?

BTW, please let me know if you need me to do anything to pass the CI check. EDIT: Sorry, my mistake - I thought the failing check was coverage not formatting. Fixed now.