Skip to content
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

Add protocol property to BusABC to determine active CAN Protocol #1532

Merged
merged 34 commits into from
May 15, 2023

Conversation

lumagi
Copy link
Collaborator

@lumagi lumagi commented Mar 5, 2023

Something that I have been missing in the past about the generic BusABC is to introspect CAN-FD support independent of the bus implementation. The way I would imagine this is to simply have an attribute called is_fd or something similar that will return True if the bus supports the CAN-FD protocol.

As an example, I have implemented this for the PCAN bus to gather some feedback. If this gets support, I will implement it for all interfaces.

@zariiii9003
Copy link
Collaborator

Just to clarify: you say

return True if the bus supports the CAN-FD protocol

but you actually just want to know whether CAN FD is currently active, right?

Generally i don't mind standardizing this for all interfaces, but with CAN XL coming soon it might make sense to use an enum instead of a boolean flag. Otherwise we would need to add is_xl soon.

@lumagi
Copy link
Collaborator Author

lumagi commented Mar 6, 2023

Sure, I can implement this as an enum. Let me know what you want it to look like, something along the lines:

  • CAN_ISO_11898
  • CAN_FD
  • CAN_XL

@zariiii9003
Copy link
Collaborator

CAN FD is already part of ISO 11898 and CAN XL will also be part of 11898. So instead of CAN_ISO_11898 i'd suggest CAN_20 or something like that. Do you have any ideas for the class name? CanSpec? Protocol? PhysicalLayer?

@hardbyte not sure how to contact you but i recommend @lumagi as maintainer ;)

@hardbyte
Copy link
Owner

hardbyte commented Mar 7, 2023

@lumagi - Lukas thanks so much for your contributions so far. As suggested I've invited you to the repository as a collaborator. Use your new powers for good! In essence, please be sensible and request reviews for non-trivial changes 👍

Great idea @zariiii9003!

@lumagi
Copy link
Collaborator Author

lumagi commented Mar 7, 2023

@hardbyte Thank you for the invitation, I appreciate it! And thanks for the recommendation @zariiii9003 ;)

@lumagi
Copy link
Collaborator Author

lumagi commented Mar 7, 2023

Regarding the naming of the enum, I think I like Protocol. But I would like make it a bit more specific like CANProtocol, otherwise this might clash with a different symbol when importing it into the module scope.

Edit: Maybe BusProtocol would fit better with the naming.

@zariiii9003
Copy link
Collaborator

Here is an interesting sentence

The third generation of the CAN data link layer supports all three protocol types (Classical CAN, CAN FD, and CAN XL)

So it is either "DataLinkLayer" or "Protocol". I'm not sure which one is technically correct in our case. I prefer CanProtocol over BusProtocol btw if we take the protocol option.

@lumagi
Copy link
Collaborator Author

lumagi commented Mar 10, 2023

Ok, to me either one would be fine: CANLinkLayer, CANProtocol. But I wouldn't want to make the names too long.

super().__init__(channel, **kwargs)
super().__init__(
channel, **kwargs, protocol=CANProtocol.CAN_FD if fd else CANProtocol.CAN_20
)

self.is_fd = fd
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zariiii9003 Would you consider this is_fd flag as a public attribute that would lead to a breaking API change if it were removed? With the protocol field it's technically redundant and could be removed.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we could replace it with a property and raise a DeprecationWarning with a removal scheduled for version 5.

@zariiii9003
Copy link
Collaborator

Ok, to me either one would be fine: CANLinkLayer, CANProtocol. But I wouldn't want to make the names too long.

I just looked through the rest of the code, can you rename it to CanProtocol? That's more in line with the rest of our code:
image

@lumagi
Copy link
Collaborator Author

lumagi commented Mar 12, 2023

Done

@lumagi
Copy link
Collaborator Author

lumagi commented Apr 1, 2023

Yes sure, I don't mind. I only have a couple Bus implementations left, so this can probably change state away from draft soon. But I imagine there's gonna be some feedback :D

# Conflicts:
#	can/__init__.py
#	can/interfaces/canalystii.py
#	can/interfaces/cantact.py
#	can/interfaces/etas/__init__.py
#	can/interfaces/gs_usb.py
#	can/interfaces/ics_neovi/neovi_bus.py
#	can/interfaces/iscan.py
#	can/interfaces/ixxat/canlib_vcinpl.py
#	can/interfaces/ixxat/canlib_vcinpl2.py
#	can/interfaces/kvaser/canlib.py
#	can/interfaces/neousys/neousys.py
#	can/interfaces/nican.py
#	can/interfaces/nixnet.py
#	can/interfaces/pcan/pcan.py
#	can/interfaces/robotell.py
#	can/interfaces/serial/serial_can.py
#	can/interfaces/slcan.py
#	can/interfaces/systec/ucanbus.py
#	can/interfaces/udp_multicast/bus.py
#	can/interfaces/usb2can/usb2canInterface.py
#	can/interfaces/vector/canlib.py
#	test/serial_test.py
#	test/test_interface_canalystii.py
@zariiii9003
Copy link
Collaborator

I resolved all the merge conflicts from #1551. I hope i didn't break anything.

@lumagi
Copy link
Collaborator Author

lumagi commented Apr 2, 2023

Thanks for resolving the conflicts! And also the rogue black test - It was not able to come to terms with my local black version.

@zariiii9003
Copy link
Collaborator

Thanks for resolving the conflicts! And also the rogue black test - It was not able to come to terms with my local black version.

You could install the correct versions with pip install -r requirements-lint.txt

@lumagi lumagi marked this pull request as ready for review April 13, 2023 06:25
@lumagi lumagi requested a review from zariiii9003 April 13, 2023 06:25
@lumagi
Copy link
Collaborator Author

lumagi commented Apr 13, 2023

@zariiii9003 I think I'm through with all the implementations, if you would like to take a look.

can/bus.py Outdated Show resolved Hide resolved
The attribute is now set as class attribute with default value
and can be overridden in the subclass constructor.
Copy link
Collaborator

@zariiii9003 zariiii9003 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! The enum comparisons should be fixed though 😄

can/interfaces/pcan/pcan.py Outdated Show resolved Hide resolved
can/interfaces/pcan/pcan.py Outdated Show resolved Hide resolved
can/interfaces/pcan/pcan.py Outdated Show resolved Hide resolved
can/interfaces/udp_multicast/bus.py Outdated Show resolved Hide resolved
can/interfaces/udp_multicast/bus.py Outdated Show resolved Hide resolved
can/interfaces/vector/canlib.py Outdated Show resolved Hide resolved
can/interfaces/vector/canlib.py Outdated Show resolved Hide resolved
lumagi and others added 3 commits May 12, 2023 07:17
Fix property access and enum comparison

Co-authored-by: zariiii9003 <52598363+zariiii9003@users.noreply.github.com>
@lumagi
Copy link
Collaborator Author

lumagi commented May 12, 2023

Great, thanks for the review! How many reviewers do you normally have for greater changes like this one?

@zariiii9003
Copy link
Collaborator

Great, thanks for the review! How many reviewers do you normally have for greater changes like this one?

At some point 2 reviews were required. But we had more active maintainers at that point. I will merge this after a 4.2.1 bugfix release to avoid backporting headaches.

@zariiii9003 zariiii9003 changed the title Add FD property to BusABC to determine CAN-FD support Add protocol property to BusABC to determine active CAN Protocol May 15, 2023
@zariiii9003 zariiii9003 merged commit 09213b1 into hardbyte:develop May 15, 2023
32 checks passed
@lumagi
Copy link
Collaborator Author

lumagi commented Oct 12, 2023

@zariiii9003 When do you think this will make it into a release? Will this have to wait until a major release or will this go into the next minor? To be honest, I am quite looking forward to having this feature available :D

@zariiii9003
Copy link
Collaborator

@lumagi I was hoping to include #1611. But i could release 4.3 anytime. I'll try to get it ready by the end of the week.
You could accelerate it by updating the changelog to include all relevant changes since 4.2.2 😄

@lumagi
Copy link
Collaborator Author

lumagi commented Oct 12, 2023

Sure, I can take care of that. I'll probably get around to doing that over the weekend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants