Page 3 of 4

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Posted: Fri Jan 18, 2019 5:20 am
by John Myers
The Arduino code base is meant to be user friendly not necessarily quick and efficient. So even though an Atmel AVR chip can handle 'sensing' frequency's above 3Mhz the Arduino library and the skill of the programmer will limit the actually max frequency that can be counted accurately.

Micro-controllers like AVR's are terrible at accurate in-sync measurements. At higher frequency a CPLD/FPGA is a better option (or buying a module).

Trying to use old USB drivers in a VM seems like a very hit-and-miss idea to me. When I used VirtualBox even newer common USB devices would give me trouble trying to get them to work.

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Posted: Fri Jan 18, 2019 7:33 am
by Rex Allers
John Myers said,
Micro-controllers like AVR's are terrible at accurate in-sync measurements.

I don't have much experience beyond simple stuff with AVR chips. What are you getting at? The timing of measurements is hard to keep consistent or maybe there are accuracy issues with ADC?

Can you be more specific about why FPGA is better on some issues?
(Not surprised that specific hardware configuration would be, just not sure exactly what aspects would be improved.)

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Posted: Fri Jan 18, 2019 3:07 pm
by Harald_Consul
USB is a standardized interface. Thus, a generic USB driver can be used for any USB controller (instead of an individual one), right?

Aren't new USB controllers (USB 3.0, 3.1) downward compatible to USB 2.0, so that also USB 2.0 drivers might be used on them?

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Posted: Fri Jan 18, 2019 6:23 pm
by John Myers

It's being able to consistently sync multiple discrete IO and interrupt signals that older micro-controllers like AVR can't do well. More modern MCU's like Xmega's do have special modules built in to address these issues. Most ADC's in MCU aren't designed for high speed, their just meant for basic voltage readings.

CPLD/FPGA's are just gate-logic so they don't have the multitasking issues like latency and interrupts that an MCU has.

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Posted: Fri Jan 18, 2019 6:35 pm
by John Futter
I personally would never use labview for any real time application
for a start it sits atop a non real time operating system.
Getting reliable data in real time keeps many experts very busy
one very good example is ... f=13&t=640

One place real time data is important is in the automotive industry, engine control, self drive etc and these applications use
an RTOS "Real time Operating System" such as QNX a real time unix
What they do is not possible with windows or whatever Linux flavour
let alone along with a resource hungry application like labview that wants 110% of a processors resources

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Posted: Fri Jan 18, 2019 6:53 pm
by John Myers
Although there are generic USB drivers for things like keyboards and mice even these have special buttons that require a specific driver in order to utilize all the features on the device. There are many standard compliant ways a manufacture can TX/RX the data so even something like the scroll wheel on a mouse wouldn't necessarily work if only using a generic driver.

The issue with USB drivers and VM's has more to do with the VM's ability to translate the actual USB hardware signals into an emulated USB hardware. If it can't do this properly the USB driver on the virtual OS can't communicate properly.

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Posted: Sat Jan 19, 2019 9:45 am
by Harald_Consul
John, I thought you were talking about an old USB port driver (from an old Windows) for a newer version of a USB port controller chip (hardware on the mainboard).

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Posted: Sat Jan 19, 2019 2:53 pm
by Chris Mullins
The USB hardware on a PC motherboard is the host controller. Naturally the reality is a bit complicated (e.g. there multiple standards, some proprietary), but the USB host controller interface to the OS is standardized enough that a mainstream motherboard's USB hardware is usually OS-independent, even across several Windows versions.

Things are much more problematic on the peripheral side. The Windows driver model changed from XP to Vista, so there are drivers in the pre-Vista era that don't work in later Windows versions. There are also compatibility issues with 32 bit drivers and a 64 bit OS (or vice versa). In addition, some drivers target specific versions of Windows unnecessarily and would work in later versions except for the explicit OS targeting in the installer. The .inf file for a driver is a text file with some of those rules - occasionally that can be hand-edited to get a driver to work in a new OS if there are no other incompatibilities.

Like John said, running old USB drivers and software in a VM is hit or miss, and success depends on the tools used to build the driver, the nature of the incompatibility, and the VM software itself (e.g. VirtualBox vs. VMWare) and how it passes the USB interface to the host. I've had mixed results even using the same OS in the host and VM, and with a compatible USB driver for that OS.

Linux and Windows both include some standard USB peripheral drivers - keyboard, mouse, virtual comm port, network adapter, etc. If an instrument like a scope, meter, etc. implements a standard USB interface like one of those in its hardware/firmware, there's no need to install a USB driver on the host PC. That greatly increases the odds of longevity through multiple OS versions. On the other hand, if an instrument implements some proprietary interface over USB involving a custom driver, the risk of obsolescence is much higher. This is true even the interface presented by the driver to the OS (e.g. virtual comm port or network adapter) is a standard one (as opposed to the instrument using the OS built-in driver for that same interface).

USB is my last choice for interfacing to any sort of instrumentation.

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Posted: Sat Jan 19, 2019 7:55 pm
by Harald_Consul
To let me get this straight what you have said:

I thought, there are two levels of drivers:
  1. A lower level USB port driver between the OS and the USB port controller chip (hardware on the mainboard)
  2. A higher level driver between the OS (or the application) and the periphal hardware - e.g. a scope - (that uses the lower level USB port driver as some kind of protocol)
But you say, both of my imagined drivers are bound in one driver for the peripheral hardware?

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Posted: Sat Jan 19, 2019 8:33 pm
by Chris Mullins
Sorry, I may not have been clear earlier.

With USB, one side of the interface is the host, and the other is the peripheral. The host is the PC, and the peripheral is the device connected to the PC (e.g. a scope). Technically there is a provision for swapping these roles, but it's not common.

There are usually two drivers involved with USB, but they're typically not thought of together. One is the device driver that runs the USB host controller on the motherboard. This is what you're calling the USB port driver. This driver is usually part of the operating system, or installed with the operating system, and is almost never modified by the user (except as part of an OS upgrade). There may even be BIOS support for some portion of the USB host controller (in reality the situation is complicated, because the USB host itself is composed of several pieces, each with their own driver). No USB peripheral device comes with a host controller driver.

The other driver is the one for the peripheral. Without this driver, the peripheral can interact with the host USB controller itself, but there's no ready mechanism for any PC application to communicate with it. Technically you could write software that reached directly through the USB host controller down to the peripheral - that's how the peripheral's driver itself does it. The function of the driver is to provide a standardized programming interface to application software for that device. For example, a scope USB driver may provide functions for interacting with the scope to higher level software. The scope only needs to install the peripheral driver, relying on the OS to already have a driver and standard interface to the USB host controller.

There are standardized device classes and types of interfaces defined in the USB spec, including a virtual comm port. A USB device driver can implement one of those standard classes, or make up its own device. If the driver implements a standard device, then others can create software that interacts with it more easily. If the device hardware itself implements a standard device that already has a built-in OS driver, then no peripheral driver needs to be installed at all. For example, a scope may have a USB virtual comm port. The scope itself could implement that directly without requiring a driver install on the OS. That's best for long-term compatibility, but puts more burden on the device. Or, it could have some proprietary USB software interface, requiring a driver install. That driver could then present a standard virtual comm port to the OS, or some other non-standard interface, or both. But, you'd have to have the driver installed to work with the scope. Without the driver, the host controller can still talk to the scope's USB port (and there's a lot of talking going on just at that level, since USB is a shared bus), but programs running in the OS won't be able to talk to the scope.

USB in general is far more complicated than RS-232, Ethernet, or GPIB, and changes much more rapidly - it's driven by the consumer electronics technology treadmill. How many USB connectors have come and gone compared to RS-232, Ethernet, or GPIB?