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

Expand library for more transports #42

Open
splatch opened this issue May 12, 2022 · 4 comments
Open

Expand library for more transports #42

splatch opened this issue May 12, 2022 · 4 comments

Comments

@splatch
Copy link
Contributor

splatch commented May 12, 2022

Recently I had a look on CAN-over-ethernet as I was forced to do a remote debug of some CAN communication.
I realized that it is not that hard to make basic client of socketcand as I was able to do that using telnet client. This made me curious if we could get other drivers which would work under Windows and not require native libraries. I started to look at other known CAN drivers/transports/interfaces out there such as slcan and gs_usb. I think these are not that far away and could be implemented. Effectively it would open JavaCAN to wider pool of users who are stuck to Windows.

I am not certain if it would fit into idea of JavaCAN as for now this project is strictly speaking focused on socketcan bridge. It will bring also more dependencies (ie. serial port handling).
I wouldn't want to implement that in Apache PLC4X cause its internal transport mechanism is bound to netty which complicates a lot basic protocol work.

What your take on that?

@pschichtel
Copy link
Owner

pschichtel commented May 12, 2022

I like the idea and I did think about that in the past, but it definitely complicates things. JavaCAN is currently very strongly focused on socketcan. However this doesn't mean that other transports couldn't live under the same JavaCAN umbrella in additional modules, possibly reusing some core bits and pieces.

As part of #38 I also thought about further restructuring of the current module structure to support both the cross-compiled JNI approach and project panama at the same time.

I think the abstractions as they are now are not well suited for reuse in other transports, but that could be something to be worked towards once we have a first version of another transport.

What would be the first protocol you'd go for?

@splatch
Copy link
Contributor Author

splatch commented May 12, 2022

Hey Phillip,
Thanks for fast answer. I am aware that bounding between socketcan and JavaCAN is present. I don't really mind it cause it gave this project a structured approach. The CanFrame is good enough for beginning, requires minor adjustments I believe. BCM and ISO-TP support you made is also an interesting area which appears in socketcand.

I think that first one I would try is socketcand as it is just a TCP read/write interface for socketcand. It can be done with fairly basic socket client, without extra dependencies. It also solves my immediate need to have a remote access to can interface with diagnostics software. I would put other implementation for later, if we get over socketcand. I have few ucan devices dongles (yet another fork of candleLight), their firmware can be swapped to slcan and cross tested under windows.

One thing I noted while playing with socketcand is the timing information which is provided as part of frame which is currently not supported by API (see #5):

rcv: < hi >
snd: < open can0 >
rcv: < ok >
snd: < rawmode >
rcv: < ok >
rcv: < frame 738 1652295808.477464 05 >
rcv: < frame 738 1652295808.479889 058A010000000000 >
rcv: < frame 728 1652295809.835495 05 >

(receive frame format is < COB sec.usec data >, not sure about sending as I didn't go that far.

@pschichtel
Copy link
Owner

I think a better approach for this would be a layer on top of JavaCAN

@pschichtel
Copy link
Owner

if I tackle this, it will come with breaking changes to the API, so javacan 4.

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

No branches or pull requests

2 participants