-
-
Notifications
You must be signed in to change notification settings - Fork 105
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
Implement gs_usb interface #212
Conversation
Okay. Please tag me when unblocked. |
One test fails here, but it's because Also opened an issue on |
This is not just an assertion check, this is a unit test. Removing the test will make it pass but break the production code. |
I know, I know. I might not have been clear enough. What I was trying to say is that this issue is more of a unit test quirk and only affects virtual can sockets, it would not affect a real socketcan adapter. But anyway, let's wait if this is resolved at the python-can repo. |
@chemicstry any update here? do we still want this open? |
There was a big discussion in An alternative without touching |
I rebased the PR and made hardware loopback to be explicitly specified per interface instead of auto detection. This should fix the failing socketcan tests. I'm not sure about other interfaces, but I believe their loopback support can be enabled in the future if someone confirms that it's working. But this still has to wait for the new python-can release 😕 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please add your remark regarding the possibility of enabling the hardware loopback for the other interfaces to the class docstring?
Updated docs and while at it also realized that gs_usb supports hardware monotonic timestamps. Added that as well. |
…es with old Pythons This crutch should be removed at the end of the year when 3.7 has EOLed.
@chemicstry do we have any eta? |
I don't know, probably not very soon, Although if this was merged it wouldn't cause any issues unless Since this contains more relevant changes for other interfaces ( EDIT: sorry, it probably wouldn't work, because |
Indeed, that sounds reasonable.
…On Wed, Jun 22, 2022, 19:54 Jurgis ***@***.***> wrote:
But this still has to wait for the new python-can release
@chemicstry <https://github.com/chemicstry> do we have any eta?
I don't know, probably not very soon, python-can is really short on
maintainers.
Although if this was merged it wouldn't cause any issues unless gs_usb
interface was selected, then you would get interface not found error. But
you could still use it if you installed python-can from git.
Since this contains more relevant changes for other interfaces (
PythonCANMediaOptions), maybe adding a note to gs_usb docs that it
requires latest python-can from git would be fine for now?
—
Reply to this email directly, view it on GitHub
<#212 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZFIZBF74RJOV6WYSWIME3VQNALZANCNFSM5PZAAAYA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Added the note. This is the error, when you attempt to use
|
Another attempt on supporting
Canable
adapters by implementinggs_usb
interface after #210 failed.This is currently blocked on upstream changes: hardbyte/python-can#1270
I was not sure how to go about implementing hardware loopback frames. Specifying boolean for each interface seemed too verbose. Instead, I made it switch to hardware loopback as soon as it receives a TX frame.
This seems to be working fine with yakut monitor/call/subscribe on windows and canable adapter with candleLight firmware.