Firmata/Serial issue on Linux

[villares]

Problem running a Firmata serial comms with an Arduino on Python Mode on Linux. The equivalent works on Java mode on Linux, and works OK on MacOS + Python mode (I should test on Windows soon)

• Ubuntu 20.04
• Processing 3.5.4
• Python Mode build 3063 (already not working on 3059)

Minimal example

add_library('serial')
add_library('arduino')

println(Arduino.list())   # to find the USB port
port = 32   # set as appropriate
arduino = Arduino(this, Arduino.list()[port], 57600)

Result:

UnsatisfiedLinkError: jssc.SerialNativeInterface.openPort(Ljava/lang/String;Z)J
	at jssc.SerialNativeInterface.openPort(Native Method)
	at jssc.SerialPort.openPort(SerialPort.java:158)
	at processing.serial.Serial.<init>(Unknown Source)
	at processing.serial.Serial.<init>(Unknown Source)
	at cc.arduino.Arduino.<init>(Arduino.java:159)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at org.python.core.PyReflectedConstructor.constructProxy(PyReflectedConstructor.java:211)
	at org.python.core.PyReflectedConstructor.__call__(PyReflectedConstructor.java:180)
	at org.python.core.PyObject.__call__(PyObject.java:438)
	at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:237)
	at org.python.core.PyMethod.__call__(PyMethod.java:228)
	at org.python.core.PyMethod.__call__(PyMethod.java:223)
	at org.python.core.Deriveds.dispatch__init__(Deriveds.java:19)
	at org.python.core.PyObjectDerived.dispatch__init__(PyObjectDerived.java:1112)
	at org.python.core.PyType.type___call__(PyType.java:1822)
	at org.python.core.PyType.__call__(PyType.java:1805)
	at org.python.core.PyObject.__call__(PyObject.java:515)
	at org.python.core.PyObject.__call__(PyObject.java:519)
	at org.python.pycode._pyx31.setup$1(arduino_input.pyde:53)
	at org.python.pycode._pyx31.call_function(arduino_input.pyde)
	at org.python.core.PyTableCode.call(PyTableCode.java:171)
	at org.python.core.PyBaseCode.call(PyBaseCode.java:125)
	at org.python.core.PyFunction.__call__(PyFunction.java:403)
	at org.python.core.PyFunction.__call__(PyFunction.java:398)
	at jycessing.PAppletJythonDriver.setup(Unknown Source)
	at processing.core.PApplet.handleDraw(PApplet.java:2432)
	at processing.awt.PSurfaceAWT$12.callDraw(PSurfaceAWT.java:1547)
	at processing.core.PSurfaceNone$AnimationThread.run(PSurfaceNone.java:313)

[mpsftw]

I have another fix in for this. It's the same old add_library bug that I've been chasing around for a while now. There's probably a better way to do this. As is, I suspect this would fail on linux arm platforms, but I don't have any arm platforms to test on.

[villares]

Hi @mpsftw, do I understand you need help testing a fix for this on Linux on ARM? (Raspberry Pi?) I can find someone to test for us if you want!

[mpsftw]

The short answer is yes, it needs to be tested on ARM.

So here's the deal with the library bugs. The current solution for adding libraries modifies the java.library.path in runtime, which is not guaranteed to change the behavior of the JVM. My solution is to manually put together likely paths to look for the libraries and load them using the full path. As I'm sure you've noticed, it doesn't always work. Java mode gets around this by forking a new JVM using the required library paths as arguments. That's probably the correct method for python mode as well, but it would be a pretty significant change to how python mode works. So unless someone has a better solution what I'll need (if it doesn't work on ARM) is the output of the logging done in test mode as it looks for the library.

I am a healthcare worker in my day job, though. My free time and energy is extremely limited right now. Sorry about that, but I just don't have a lot of availability to work on this right now.

[villares]

Thank you so much. Take good care of yourself first and thanks again. I'll find someone with Linux ARM and bring here so you can instruct them, but I understand it may take a while for you to have any chance of looking into it.

[tabreturn]

Hi @mpsftw -- I have some Pi's lying about to test this. What build/version of Processing.py should I use?