Correct semantics in exodriver?
Posted 06 January 2011 - 12:57 PM
1) I was reviewing the exodriver source code (labjackusb.c) and found multiple cases where exit(1) was being called. Unfortunately, this poses a problem for any application using the labjack exodriver as the application cannot correctly do application specific cleanup and handling in the event of a labjack failure. The labjack libraries do not know the context in which they are executing, and thus, cannot correctly determine if exiting the process is a safe or correct thing to do. They should be returning an error code, and leaving the decision of how to handle the error up to the caller of the function.
2) We'd like to use the labjack for some hardware in the loop system integration testing, and our software is using libusb-1.0 to communicate with our hardware. In reviewing the labjack code, I see that it is using the default libusb context (note the NULL being passed to the libusb_init() and libusb_exit() functions). Our software also uses the default context. This is going to cause a problem when I go to link and initialize the application as the two pieces of software will be manipulating the libusb context of the other piece of software. Realizing this, I have to go thru our code and define and use a context specific to our application, but the labjack exodriver should also be doing the same thing if it expects to integrate with 3rd party software. More commentary can be found here: http://libusb.source...group__lib.html
Questions? Comments? Thoughts?
Posted 06 January 2011 - 07:06 PM
Posted 06 January 2011 - 09:44 PM
Exodriver v2.04 is available on GitHub. This version addresses the issues you brought up.
Wow, that was fast! I think that literally the fastest driver update response I've ever seen... Nice work and thank you! :)
Well I guess while I'm in the mode of posting requests, maybe I can throw out and idea and see if has any appeal...
Our company sells a USB wigit. We use libusb-1.0 to interface with our USB wigit. We are using the libusb-pbatard branch to provide the underlying infrastructure for windows support. The combination of these libraries allows us to have a common USB library interface on Linux 32/64, MacOS 32/64 and Windows 32/64. The libusb-pbatard branch interfaces with WinUSB, so it's all userspace, which means we don't have to develop a kernel driver and simplifies our development cycle...
On top of this sits a set of C-libraries that provide a more abstract, human understandable interface to our USB wigit, thereby hiding the low level protocols. This is analogous to your windows UD libraries. However, since our libraries sit on top of a platform independent USB library, we can have the same abstract libraries work on all OS's... This is all implemented in C, as we provide our libraries to 3rd parties for integration into their applications, which include Linux/mac GCC based apps, MS Visual Studio apps, matlab, and many others. DLLs/SOs/DYLIBs are provided. So long as the 3rd party can load up a dynamic library, they can access all our hardware, on all platforms, using the same library interface...
On top of the abstract C interfaces, we use SWIG to auto-generate other language bindings, such as JNI bindings, python bindings, and anything else that SWIG supports. This is pretty handy because SWIG does 97% of the tedious, time-consuming and error prone grunt work. For some things we go in after the fact and provide even further refined interfaces, but the nice thing is that any number of language bindings can all be automatically generated at the same time.
The particular type of hardware in the loop testing we're trying to do requires that we run on Mac/Windows/Linux, 32/64, so we have interest in full cross platform support with API semantics common across all OS variants.
I'm not trying to convince you to do anything in particular, but rather highlighting various techniques that a company could utilize to get full cross platform support, with abstract APIs, and many language bindings, all with one piece of infrastructure....
Food for thought...
Thanks so much,
Posted 11 February 2011 - 08:52 AM
Posted 11 February 2011 - 10:11 AM
Posted 18 August 2011 - 03:02 AM
Posted 18 August 2011 - 08:51 AM
Posted 20 August 2012 - 06:12 AM
Posted 20 August 2012 - 03:10 PM
Also, LabJackPython provides a cross-platform interface.
I will point out that for operating systems that the Exodriver does not support, the source code is available on github if people want to port it. Libusb 1.0.9 added Windows support I believe.
Posted 22 August 2012 - 02:10 AM
Posted 22 August 2012 - 02:07 PM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users