Adds canal interface#245
Adds canal interface#245felixdivo wants to merge 27 commits intohardbyte:developfrom felixdivo:develop
Conversation
* almost just a copy of the usb2can module which is badly named * the usb2can module is for now left unchanged but should be changed to use the new CANAL interface * TODO serial_selector update...
* autodetect device ID failed * CanalOpen failed
|
The failing test is the problematic |
There was a problem hiding this comment.
I'm unlikely to merge this without a page added to the documentation.
It wouldn't need to cover much - links to the hardware vendor, mention and link to the required libraries. Any comments on compatibility, limitations etc.
|
All requested changes are valid. ;) I will address them as soon as I can, but that will have to wait for one or too weeks probably, since I am very busy right now. |
I would like someone else to do that since I do not really get Sphinx and do not know the hardware behind the interface at all. Can someone else pick that up? |
|
Does it need to be registered in |
|
@krixkrix Could you write some docs? That would be really nice. |
|
This still needs to be done:
Can anyone help to close this ancient issue? |
|
@krixkrix Just mentioning you because I'm not sure if you else get notified by new comments. See above for my comment on docs & tests. |
|
@krixkrix Have you already found time to look at this? As version 3.0 is now released, I want to get this working early in this "iteration" so we can finally release this into 3.1. |
|
What is the difference between this backend and the USB2CAN one? I do have hardware for the latter and it also uses an abstraction layer DLL named CANAL. If it's in any way related, I could do some testing. Would be good to have at least some kind of documentation, to answer questions like this ;-) |
|
This might be the case, yeah. I actually have no idea of the required DLLs, I only copied PR #161 and applied some general patches. Also, I found this through the issue #465: https://github.com/krumboeck/usb2can_canal. If this is redundant, we can close this PR, sure. Apparently, no one had interest to solve this, so that might explain it. |
|
So the real question is why did @krixkrix make a copy of the usb2can backend? I don't get it from the comment, but didn't check the source code either. @felixdivo Would you mind diffing the two backends against each other, to figure out the main differences? |
|
Yeah, I could do that in a few days/weeks. I'm quite busy right now. |
|
According to the VSCP documentation:
Apparently the CANAL API is implemented by a bunch of drivers there, not only USB2CAN. But I wouldn't bet on more people using this interface backend if it were named CANAL, especially since probably no one ever tested with other CANAL implementation DLLs. |
I wouldn't either. |
|
@felixdivo I've started a comparison of the backends, see this Gist. Besides renaming the files and classes, there are some differences in error handling (exceptions) and fewer comments about the backend being targeted to Windows mainly. In some places, I get the impression that some general python-can changes, like My knowledge of python-can internals is very limited though, so I won't try to judge which backend is "better". Some obvious documentation and cosmetic changes could be ported to usb2can easily, though. |
|
I didn't know Github can display .diff files that nicely. ^^ Yeah, there are some changes that should be ported to I can do it this weekend, but I have a question about |
|
The USB2CAN adapters from 8devices apparently always have a serial number starting with 'ED' prefix. I don't know what the resulting strings from the Windows API query will look like, but it seems to slice out the last 8 bytes trying to get the serial number. On the other hand, the USB product ID PID_6001 probably matches an FTDI UART interface chip on the adapter, which will result in pretty much any USB developer gadget without an own vendor id, plus the ones in the linked query. Since the method only returns the first match, the latter might cause problems. It's a rather fragile approach either way. Looking for 'ED' will probably only work for adapters sold by Eight Devices, not @rusoku's TouCAN, for example. Since I'd probably go with the more flexible approach from |
|
"ED" prefix comes from my old company edevices.lt ;-) |
|
Thanks for all the input. ;) Maybe the Win32 API can even reveal the serial numbers directly? Does anyone know the API well enough for that? I couldn't find it via the first search results ...
Then we could simply look for the last regex group with
Do we need to strip the device type number from the serial ID or is it okay to leave it in there? Because how can we detect when to strip it and when not?
Sounds good, combined with variable length IDs. |
For TouCAN devices init string always consists of 3 blocks: device_id ; serial number ; speed. |
This adds the changes that were requested in #161. That older PR can now be closed.