search

jdf / Processing.py-Bugs

A home for all bugs and feature requests about Python Mode for the Processing Development Environment.
41 stars 8 forks source link

Firmata/Serial issue on Linux #301

Open villares opened 4 years ago

villares commented 4 years ago

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)

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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