Initial J1939 changes #57
Conversation
|
If I understand the can-utils code below correctly, then you can only write to sockets after connect() (so you have a known destination address for write()) and and you can only read from sockets after bind() (so you have a known receive address for read())
(can-utils is mostly using send, sendmsg, recv and recvmsg because they also process message attribute, they are equivalent to read and write for JavaCAN's purposes) |
|
Ahh ok, I hadn't quite made sense of the J1939 docs yet. |
|
Well, I'm getting a bit closer. Now it fails during write with a: tel.schich.javacan.platform.linux.LinuxNativeOperationException: Unable to get FD frame support - errorNumber=22, errorMessage='Invalid argument' |
|
that exception does not happen during write, but during the setOption call of the FD_FRAMES option. not sure why it would be invalid, I guess J1939 might not support FD frames? |
|
It's happening on the test code line 202 - which is commented out. |
|
your read() method does call getOption(FD_FRAMES) to allocate a correctly sized buffer, which I assume you copied over from the raw channel. When J1939 doesn't support FD, you can just hardcode |
|
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/can/j1939/socket.c#n681 there you can see the supported socket options for J1939 sockets. |
|
Yeah, lots of copied code. |
|
Whee!!! that test passed! |
|
In my hunt for actual documentation on the options, I did find this: |
|
I think that's what you are looking for |
|
Not really, that's pretty much the same as a couple of the other pages I've found, where it mentions the options, but gives no description of what they do, or what values are valid. |
|
What are you looking for? Except for |
|
I'm used to full docs on an API. |
|
Their domain is actually documented, though not as explicitly as you'd hope. I think the "issue" is that they assume knowledge of the specs which are sadly not as accessible as I would prefer them to be. I learned that when I tried implementing ISO-TP in user space. If you want to improve on this, the can subsystem mailing list is pretty responsive. Given you are at the point that this is working for an initial set of tests, I'm thinking about merging this early and cleaning it up a bit on master. What do you think? |
|
Sure , I take it need to do another pull request? |
|
I would merge it and refine it on master to be a little more in line with the rest of the codebase. Is there any major functionality left you'd like to add? |
|
Not that I can think of right now. |
|
I've locally reworked your commits to remove noisy whitespace changes, I'll also do some other cleanups |
|
Not surprised at the whitespace changes. I'm so used to letting eclipse clean up the little things... |
|
I've setup a tiny test app, and getting a weird error: john@raspberrypi4:~/PiCanTest $ java -cp PiCanTest_lib -jar PiCanTest.jar I've even tried forcing it to 16, like this: Same error. |
|
have you checked how many bytes have actually been read? Also: you shouldn't be reading CAN frames from the J1939 socket. the read() syscall reads the data bytes only. I've already deleted the |
|
I think we might have to add send* and recv* style APIs as J1939 doesn't seem to be useful without metadata in certain situations. ISO-TP is only point-to-point (with a tiny exception), so that got away with just read and write, but J1939 supports multicasts more similar to raw. |
|
So, it looks like I need to add the Send and Recv calls? |
|
I was actually about to start on it |
|
If you want to, that would be great! You are likely far more experienced with these updates, and won't mess up the formatting like I do. |
|
Oh, and yes it's my fault for not properly reading the javadocs. |
I think it's pretty common for read/write operations to return the bytes read/written. Java's various stream and channel APIs do the same, also all the posix IO functions.
Don't worry
great. |
|
I considered adding some function to parse the PGN fields, would that be of interest to you? |
|
I don't think so. When I send, the code is simple. The PGN is a constant 0x00xxxx. (I have it in an enum) What it's looking like I DO need, is some way to write a log file in the Canoe .asc file format. |
|
I've just split out the tools package into a separate module: https://github.com/pschichtel/JavaCAN/tree/master/tools/src/main/java/tel/schich/javacan/tools feel free to add additional tools there. |
|
I am running into one issue - that I'm not sure WHO is causing it. Resetting the equipment doesn't help. Hmm, if I do a JavaCan.allocateOrdered(), do I need to release it? I just found a place in my code that assumes they get garbage collected like any other Java object. |
|
ByteBuffers will be GCed, yes, even direct buffers. The APIs auf JavaCAN are also all designed to be able to re-use buffers across operations. I'd recommend to re-use buffers as much as possible instead of allocating for each operation. |
|
@JohnLussmyer I just remembered that I have the TROUBLESHOOTING.md that documents some pitfalls and how to detect/resolve them. It doesn't currently have anything on J1939, maybe some of your experiences are worth documenting there? |
|
So far the only real problem I had was using ByteBuffer.get(byte[], off, len) I'm currently running into an issue where after running for 10 minutes or so, it just stops receiving any messages. |
|
can you attach strace to the program when it is stuck ? also a thread dump might be interesting. |
|
Note that I am primarily (nowadays) a Java programmer. It's been many years since I had to debug native code. |
|
Simply install strace and run For the thread dump you can just use the jstack tool from the jdk: The outputs might be very long, so paste them into github gist or pastebin or so. |
|
Well, it's obvious that I need to know more about those tools. Attaching to process ID 2389, please wait... |
can you provide what ever little output it produced? |
|
I'll try again, and copy/paste the console since redirection failed. (and I didn't notice until I got back to the desk.) |
|
probably tomorrow. Monitor out in the shop just failed, so I have to find another that will work with that unit. |
|
get a pikvm if you have power and wifi or lan available: https://pikvm.org/ |
|
I still need a real monitor out in the shop. It's 200' from my desk, and I have to be at the equipment to work with it. (power switches, etc...) |
|
I'll probably drag a spare laptop out there and SSh into the Pi. |
|
Ok, found the lockup issue. |
what do you mean? bytebuffers do perform range checks (actually several). |
int fldcnt = 0x0FF & buf.get(0);
int len = buf.remaining();
log.debug("parseSoftwareIdentification: fldcnt={}, len={}", fldcnt, len);
if (len > 0) {
byte[] data = new byte[len];
buf.get(data, 0, len);
}If you make a mistake, and put a "1" for the middle param of the last line - you will hang the thread. |
|
It would really surprise me if that actually hangs the thread, that would be a JVM bug worth reporting upstream. Sure there is no IndexOutOfBoundsException that somehow triggers a loop in your program? |
|
Hmm, possibly. My usual app framework has an unhandled exception handler. |
Your thread gets blocked until |
|
Note: That I am receiving 56 byte messages just fine. |
|
@splatch Java's ByteBuffer doesn't wait, it's pretty "dumb" and doesn't have any synchronization. If the buffer doesn't have enough bytes remaining to satisfy the request, then it just throws. Ignore that I'm using scala:
That matches what the javadocs say. I'm wondering though, why didn't you program log the exception if there was no other default exception handler configured? |
|
Exceptions only get written to the log if you catch them. |
|
HI, thank you for your work! I'm working on the kernel documentation for the CAN_J1939 socket, https://lore.kernel.org/all/20241013181715.3488980-1-o.rempel@pengutronix.de/ |
Initial set of changes, test failing
see #54