B4J Question byte in binary format to number conversion after reading on usb

here is the error on run_debug.bat

C:\B4J\crono-timer\Serial_Test\Objects\temp\build\bin>java.exe @release_java_modules.txt -m b4j/b4j.example.main
main$ResumableSub_AppStart.resume (java line: -1)
java.lang.UnsatisfiedLinkError: Could not load the jssc library: Couldn't load library library jssc
at b4j/jssc.SerialNativeInterface.<clinit>(Unknown Source)
at b4j/jssc.SerialPortList.<clinit>(Unknown Source)
at b4j/anywheresoftware.b4j.serial.Serial.ListPorts(Unknown Source)
at b4j/b4j.example.main$ResumableSub_AppStart.resume(Unknown Source)
at b4j/b4j.example.main._appstart(Unknown Source)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at b4j/anywheresoftware.b4a.BA.raiseEvent2(Unknown Source)
at b4j/anywheresoftware.b4a.BA.raiseEvent(Unknown Source)
at b4j/b4j.example.main.start(Unknown Source)
at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(Unknown Source)
at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(Unknown Source)
at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Unknown Source)
at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(Unknown Source)
at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(Unknown Source)
at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)


C:\B4J\crono-timer\Serial_Test\Objects\temp\build\bin>pause

thanks

I suggest to SEARCH The forum first every time you encounter a new problem.

The solution is here:
https://www.b4x.com/android/forum/threads/solved-jssc-error-with-b4jpackager11.112846/
See point 5) in that thread.

mario53 said:

maybe I'm giving up

Click to expand...

Just to confirm...

1/ is your program receiving and decoding 12-byte packets from your USB tool?
2/ are there any other packet types to be decoded? ie with different START bytes and probably different number of packet bytes

I am a big fan of if it ain't broke, don't fix it
and so if your program is receiving packets ok without any problem, then I am happy to leave it as it is,
but if there is more to do eg extra packet types, then I would enjoy helping taking on that puzzle challenge aka two heads are better than one
(or are you more of a too many cooks spoil the broth person?) (or troppi galli a cantar non fa mai giorno?)

emexes said:

Just to confirm...

Click to expand...

Even if he decodes the right 12-Byte-Packets then he´ll encounter another problem. Not using prefixmode results in splitted packets
Byte 1-8
Byte 9-12 and bytes 1-4 from the next packet maybe...

He has to capture the bytes coming in the stream and parse them accordingly ;-)

The checksum looks easy enough. Only question is whether it includes the START and/or STOP bytes. I've seen all combinations.

now that I have solved the problem of compiling in exe. I would like to review and try your example (@emicrania) to bring the buffer back to all 12 byte packets.
for now thanks to @DonManfred and @emicrania

emexes said:

The checksum looks easy enough. Only question is whether it includes the START and/or STOP bytes. I've seen all combinations.

Click to expand...

mario53 said:

The checksum looks easy enough. Only question is whether it includes the START and/or STOP bytes. I've seen all combinations.

Click to expand...

Are you replying to me? Am I "@emicrania"?

mario53 said:

Only question is whether it includes the START and/or STOP bytes.

Click to expand...

My guess would be that the checksum does NOT include the STOP byte, because:

(1) the STOP byte is after the checksum, and it feels unusual for a checksum to be in the middle of what it is checking, and
(2) the STOP byte (and the START byte) can be assumed to be correct (ie not corrupted) because, without them, we have no packet to check

emexes said:

My guess would be that the checksum does NOT include the STOP byte, because:

(1) the STOP byte is after the checksum, and it feels unusual for a checksum to be in the middle of what it is checking, and
(2) the STOP byte (and the START byte) can be assumed to be correct (ie not corrupted) because, without them, we have no packet to check

Click to expand...

yes I am answering you sorry for the translation error.
now I am passing your very fair questions to the manufacturer of the machine.
we will see the answer.
thanks