Parsing Mac OS X's `system_profiler` for USB information is a blunderbuss.

[mralexgray]

I constantly see Arduino.app spawning the process

-+= 00001 root /sbin/launchd
 \-+= 10895 me /.../Arduino.app/Contents/MacOS/Arduino
   \-+- 13588 me /usr/sbin/system_profiler SPUSBDataType
     \--= 13594 me /usr/sbin/system_profiler -nospawn -xml SPUSBDataType -detailLevel full

The system_profiler is notoriously slow, resource hungry, and certainly not the appropriate tool to query the USB subsystem's capabilities. It may be "easy" just to parse some XML that Apple graciously provides.. but that unfortunately does not make it prudent and/or sane to do so.

I see the java code calling out to this API command-line tool in arduino-core/src/processing/app/macosx/Platform.java ...

    try {
      CommandLine toDevicePath = CommandLine.parse("/usr/sbin/system_profiler SPUSBDataType");
      executor.execute(toDevicePath);
      return new String(baos.toByteArray());
    } catch (Throwable e) {
      return super.preListAllCandidateDevices();
    }

I confess to have never even glanced at a piece of Java software before - nor do I hope to start now.. but I'd imagine that there are plenty of (more) native bridges - between the Cocoa/ObjC subsystem and Java (or at least some way to access the hardware that isn't as brutal and archaic as parsing the output of a utility designed for only the most occasional of system inquiries).

Please let me know if this kind of integration is outside of your team's comfort zone, and I'm sure myself or some other issue onlooker can help. I definitely think this constant polling is affecting Arduino.app's performance, as well as needlessly burdening the host system as a result. I would guess offhand that IOKit and/or SystemConfiguration frameworks would be a good place to start to find an alternative method to obtain the information you need re: the serial ports / whatnot. If not, there are great alternatives such as ORSerialPort that may also be of some service in this endeavor.

[ffissore]

Uhm so our current implementation is notoriously slow, resource hungry,
brutal and archaic. Wow.

Alex Gray ha scritto il 30/11/2015 alle 03:16:

...but I'd /imagine/ that there are plenty of (more) native bridges...

Please let us know if you come up with an implementable solution, which
is faster than the current one. ORSSerialPort is an ObjC library, which
means we could use it only if you could code a JNI wrapper around it, or
if you can make a command line version (they have a CLI demo, but it's
interactive, so it won't work)

Looking forward for your proposals

[lmihalkovic]

I guess this is the true wonders of open source, when it becomes synonymous for we-can-bestow-any-blunderous-code-on-users-and-make-it-your-responsibility-if-you-want-anything-better.

[mralexgray]

@lmihalkovic, hey.. it's better than a lot of devs... who would simply close the issue! @ffissore is a JNI wrapper anything like an ffi wrapper? i guess I'm asking.. is a JNI blah blah blah a textual means of IPC, or some other method that hooks into standard C static / shared libraries? Also,what exact information are you getting from the system_profiler now_, so I can narrow down the scope of what this would actually need to do? PS: Didn't mean to sound dramatic.. I just do get frustrated with this software. Has anyone brought up the lack of a "Window" menu, lol? I'm gonna go look now!

[lmihalkovic]

@mralexgray IMHO you speak like someone who has not read many of the closed issues yet. better is interesting... as a dad I try everyday to teach my 8 y/o the difference between better-than-x and the many shades of good

[ffissore]

@mralexgray glad you asked.

From system_profiler we look for the device file (eg: /dev/cu.usbmodemfa121) and return related VID&PID. vid/pid are then used to display the name of the board (eg: Arduino/Genuino Uno).
We have a test for that parser, and some example outputs.

A JNI (Java Native Interface) wrapper is a way the jvm can load, introspect and use native libraries (.dll, .so). You wrap the actual native code with something the jvm can use. And while you're at it you also wrap only the functions you'll use (supposing the lib has 10 functions but you're interested in only one). Even better, you code a utility method that wraps a complex call chain, providing the jvm with a simple method like String findVIDAndPIDOf(String serialDeviceName)

[mralexgray]

OK, I did it. Please refer to Examples/Lib on my usbquery branch. This is a fix for #4230. Hopefully someone can take it from here so I don't have to learn what a JNI is, lol. So far I...

• forked ORSerialPort
• Added a category to it, enabling USB introspection.
• Made it into a dynamic library.
• Created a demo app to illustrate usage.
• Integrated into Arduino.app

So there is a SINGLE function to call after linking to usbserialquery (via -lusbserialquery ?)...

NS_INLINE char* getInfoForSerialUSB(id name);

It expects an NSString *, but that could be changed, or a wrapper can be created to pass it one. It returns a char pointer. There is no source file. It is implemented solely in the single header file usbserialquery.h. Compiler magic, yadda yadda. The library itself is simply a compiled dylib of the files included with ORSerialPort, so theoretically, those files could just be compiled into Arduino.app.. but again, don't know if that is even possible with a Java-driven app bundle.

In the demo, passing my Teensy's USB name of /dev/tty.usbmodem935591 results in

000016c0_00000483

I can tweak the output if needed. Is this OK? How do you want it? In a pull request? Not sure how best to do it, you guys don't seem to use submodules.. Please advise.

[ffissore]

Thank you @mralexgray ! Way to go! Best thing you can do now it make a pull request against ORSerialPort repo, so that your changes gets merged into their master, thus receiving their feedback (osx hackers), which is much more apt than ours (osx users)

I'm looking at your code to see what remains for turning it into a JNI lib

[ffissore]

Two things you can improve are: don't commit binary files (they'll probably ask you to remove it anyway), don't convert VID and PID to int, use the original hex value

[ffissore]

Ah, and don't append a newline, it's useless

[ffissore]

One last comment: you can avoid using break and continue and write it this way

for (ORSSerialPort * obj in ORSSerialPortManager.sharedSerialPortManager.availablePorts) {
  if ([q isEqualToString:obj.name]) {
    info = [NSString stringWithFormat:@"%08x_%08x\n", obj.vendorID.intValue, obj.productID.intValue];
    return (char*)info.UTF8String;
  }
}
return (char*)info.UTF8String;

Although I don't know if ObjectiveC allows early returns

[mralexgray]

@ffissore RE: merging OR upstream.. I don't think we need to... the changes are all for our benefit.. and my fork can be tagged and/or submodularized into arduino-core... or imported as a freestanding files into this repo. I don't think my changes, although fabulous, necessarily are interesting to OR's maintainers.

more importantly, and why I included the compiled binary,... is how can this be a drop-in replacement for you system_profiler_shenanigans. are you actually going to "receive" the byte-code char * return pointer, or are you going to continue to parse the textual output. eiter way I can update the code to just return EXACTLY what you had/need so nothing else has to change.