topic Re: Linux I/O Drivers for LabVIEW in Linux Users

Linux I/O Drivers for LabVIEW

modest — Thu, 23 Jun 2011 19:37:13 GMT

I am new to LabVIEW and I do not fully undestand what it takes to support LabVIEW under Linux for DAQ cards in general and that's what I am trying to understand here.

We have an LPC bus based ADC and DAC card for an x86 board. We would like to support LabVIEW under Linux for these cards, however, we do not have kernel I/O driver for these cards and it is my understanding that in order to support LabVIEW, we first need to write these I/O drivers.

My questions

1.Does NI provide any tools that enable us to write these Linux I/O drivers (.ko) for 3rd party DAQ cards such as ours. I read about NI-VISA product but I am not sure how that fits into the overall picture.

2. Let's assume after the I/O drivers are available, what is the next step in order to make LabVIEW development environment support these DAQ cards? Is there another layer of drivers,"LabVIEW drivers", that sits on top of the OS I/O driver that we further need to develop?

Any help/information on this topic is greatly appreciated. Thanks.

Re: Linux I/O Drivers for LabVIEW

rolfk — Fri, 24 Jun 2011 07:17:33 GMT

Well, depending on the interface your hardware uses, there are various options. If it is a hardware board directly plugged into the PC, I believe you will have to provide some sort of kernel driver, as there is no way to access hardware directly from user space in a feasible way. If this hardware is however connected to the computer through a standard interface such as USB you can quite likely get away with accessing the according user space API to communicate through that interface.

As to your other questions:

1) No NI won't tell you how to create kernel device drivers. You can download DAQmx Base and get an idea what they did but you will have to come up with your own solution. NI is not in the business of teaching about kernel device drivers in general, and on Linux for sure. Their Linux support until now is a very delicate balance between protecting their own IP and complying with strict and continously increasing open source requirements from the Linux kernel developers. And kernel driver development, while not exactly magic, is a very specific technical ability that only a few people really can master. Last but not least it is not in their interest to support a competitor to their own hardware.

In the case of Linux kernel device drivers, the most easy path is to look at various types of the already present device drivers. Almost anything that gets distributed and residing inside the Linux kernel has to be more or less open source nowadays. So there are a lot of fully functional device drivers to look at and get an idea how they work. Writing your own still is a project that you should not take lightly. It costs a lot of time, coffee and nerves to get a kernel driver right, because every time something goes wrong, you are likely having to restart the whole system from scratch to be sure that you don't have corrupted kernel tables and what else messing with your whole system.

For Windows you would have to look at the DDKs, although the example drivers there, while they show how things are supposed to work, are usually very far from fully working drivers and other sources than the DDK are sparse and far in between.

2) Yes a kernel device driver while technically usually the hardest part to get really right (just working 99% of the time is really not enough for something that has the potential to take down your whole system very hard), is just the first step in the whole picture. After that you usually need a user space shared library that communicates with the kernel driver and provides an easy API for the applications to use your hardware. This API is what any application including LabVIEW written applications will use. Once you have the user space API you want to create a LabVIEW VI library that accesses this API through the Call Library Node. This is the only real LabVIEW specific part of the whole picture. All the rest up to this is simply necessary infrastructure to access hardware in a modern OS, be it from a C application, Python, or LabVIEW. And this applies to any modern OS, including Linux, Mac OS X, and Windows.

Re: Linux I/O Drivers for LabVIEW

modest — Fri, 24 Jun 2011 16:50:32 GMT

Rolfk, That's a great answer!!! Probably the best explain than any of the resources that I have been able to find. I have one follow-up question regarding the "user space shared library":

1. Should these libraries be written keeping LabVIEW in mind? In other words, does LabVIEW requires certain specific API calls to be present in that shared user space library?

The reason I am asking this is that we would like to avoid a situation where we write kernel I/O drivers and the user space shared library and then find out that the target application (LabVIEW in this case) will not work because certain functions/calls are missing in the user space shared library.

To summarize, should these I/O drivers and API be agnostic to LabVIEW?

Re: Linux I/O Drivers for LabVIEW

rolfk — Fri, 24 Jun 2011 22:42:37 GMT

Yes and no! The kernel driver is whatever works best for you. The shared library will translate between the kernel driver interface and whatever makes most sense to your user space API.

The user space API does not require specific functions to be present for LabVIEW. But you should take care to design the API in such a way that it accepts simple datatypes. The LabVIEW Call Library Node does not support function pointers, nor does it lend itself to supporting parameters consisting of structures containing non flat data (embedded array or string pointers).

Re: Linux I/O Drivers for LabVIEW

modest — Mon, 27 Jun 2011 16:57:36 GMT

Ahh..I see. Is there a list of data types that LabVIEW recommends? I found the following link but not sure if what's that you are referring to:

http://zone.ni.com/devzone/cda/tut/p/id/12344

Also, on NI's LabVIEW Linux support pages, I see a lot of mention regarding NI-KAL. Is that the user space API that you are talking about that support all of NI's DAQ cards?

Re: Linux I/O Drivers for LabVIEW

AdamKemp — Mon, 27 Jun 2011 19:21:50 GMT

NI-KAL is a kernel-mode component on top of which NI builds its drivers.

A typical pattern for developing drivers for LabVIEW is to build a C API and then build a LabVIEW-specific DLL on top of that API for better integration with LabVIEW. For instance, if your driver returns an array then it would integrate better with LabVIEW if you use the LabVIEW memory management APIs to work directly into a LabVIEW array handle. You don't want that code in your standard driver, though, so you would build a layer that sits between LabVIEW and your regular driver. This is what DAQ does, for instance.

Re: Linux I/O Drivers for LabVIEW

rolfk — Wed, 29 Jun 2011 12:04:23 GMT

No these are the various datatypes that LabVIEW supports internally. Some of them are not useful for the Call Library Interface.

Basically you can use all kinds of C scalar datatypes such as single, double, char, short, int, and long and their unsigned types directly as parameter, either by value or by reference, arrays of these scalars, and structures that contain any combination of these scalars. In addition you can pass ASCII Null terminated strings as a parameter. Anything else is asking for trouble.

Absolutely unsupportable without specific LabVIEW wrapper library that translates between your C API and a more suitable LabVIEW type are function pointers, such as callbacks (need to be translated in the wrapper into LabVIEW occurrences or user events), and structures containing any type of pointer.

Re: Linux I/O Drivers for LabVIEW

AdamKemp — Wed, 29 Jun 2011 15:55:10 GMT

Also keep in mind that LabVIEW uses non-default alignment for structures on 32-bit Windows. If your driver is Linux only then you don't have to worry about that, but if you want it to be cross platform then even structures will require a special LabVIEW wrapper (unless you want to impose LabVIEW's alignment on your C clients as well).

Re: Linux I/O Drivers for LabVIEW

modest — Wed, 29 Jun 2011 17:28:12 GMT

Guys, all this is great info! So just to be clear:

NI-KAL is a kernel mode componenet/framework on top of which NI builds their DAQmx kernel drivers for their cards. Also, where can I find the corresponding user-space C API that sits between the DAQmx driver and the Linux equivalent of LabVIEW Windows DLL.

Lastly, can somebody point me out to some set of basic example code (or a HOWTO) showing the entire process of supporting LabVIEW under Linux?

Re: Linux I/O Drivers for LabVIEW

AdamKemp — Wed, 29 Jun 2011 20:08:21 GMT

The DAQmx driver is not open source. We don't ship the C code.

As for documentation showing the "process of supporting LabVIEW under Linux", assuming you mean supporting drivers on Linux, I'm not aware of any documentation specifically about that. We have some general guidelines for writing drivers for LabVIEW at ni.com/idnet, but those tend to focus on writing drivers using VISA or IVI. A lot of the general concepts in the guidelines still apply, at least in terms of how to write your LabVIEW API, but that won't help you figure out how to write the C glue code that sits between LabVIEW and your underlying driver. For that you mostly just need to understand how to call C code from LabVIEW. We have some documentation for calling external code from LabVIEW, which includes information about the data types and memory management functions (look for "calling external code" in the help). That's the kind of stuff you need to understand so that you can do any necessary translation between the LabVIEW side and the C side.

Re: Linux I/O Drivers for LabVIEW

modest — Thu, 30 Jun 2011 00:15:12 GMT

I understand that DAQmx is not open source, however, what I am trying to understand is what is the difference between NI-KAL and NI-DAQmx?

As far as I have understood, NI-KAL is a low level kernel driver and the NI-DAQmx is the user space C API (a.k.a C glue code) that sits between NI-KAL and LabVIEW drivers? Am I correct?

Re: Linux I/O Drivers for LabVIEW

rolfk — Thu, 30 Jun 2011 10:41:00 GMT

KAL is Kernel Abstraction Layer. This is in fact mostly a kernel driver that abstracts anything kernel related in a way, that the drivers that are above it can mostly use the same code base independant of the actual platform. So this driver handles the actual management of kernel memory, DMA, interrupt service configuration and handling, etc. On top of that there is usually another kernel driver that is specific to your type of hardware. The KAL driver had to be open sourced since the Linux kernel developers have defined various kernel APIs that a closed source driver may not call anymore without violating the GNU license.

Theoretically one could write one single generic KAL type driver and call it then from user space libraries. However such a driver would need to be very involved, since you do not want to do a kernel driver call for every register address access when setting up hardware. Every translation from user space to kernel space is rather expensive in time, and if you need to program lets say 100 registers to prepare a certain operation, that would be very expensive if you would do it from user space and use one KAL driver call per register.

Also kernel driver calls are usually not convinient to do from an application level, therefore most kernel drivers come with a user space shared library that provides a C function API and calls the kernel driver through the required OS specific device driver access method. In Windows for instance you open a kernel driver as a device and invoke FileRead(), FileWrite(), and IOControl() calls on it. Linux will be probably rather similar. While you could write VIs that call these system APIs through the Call Library Node, setting up the parameter list for IO Control in LabVIEW would be at best a huge pain in the a$$ and most likely not possible for most of the calls.

Not to forget that you would have to do all the work again for every other application you write, such as Visual Basic, Python, LabVIEW, etc and each time use the environment specific methods to implement this. So there it's much easier to do the involved kernel driver access once in a C shared library and then call a much easier to use C API from all those environments.

Re: Linux I/O Drivers for LabVIEW

AdamKemp — Thu, 30 Jun 2011 17:36:34 GMT

KAL is not a driver per se. It's more of a framework on top of which our drivers are built. It abstracts the kernel differences between various platforms. We write as much of the platform-specific stuff as we can in the KAL layer (reimplementing it for each platform), and that exposes a unified API and driver architecture across all platforms. Then we build our specific drivers on top of that. Those drivers still have a kernel component and a separate user mode component. DAQmx, then, is still multiple componets: a kernel part, a common user mode part, and then a separate component still that sits between LabVIEW and the common user mode part.

DAQmxBase, by the way, is a totally separate driver which is built in LabVIEW itself using the VISA API. The DLL you use for DAQmxBase in a C application is actually a LV-built DLL (that is, a DLL written in LabVIEW). That may still be an option for you.

Re: Linux I/O Drivers for LabVIEW

modest — Thu, 30 Jun 2011 21:27:11 GMT

Not sure what you mean by "single generic KAL type driver"?

And last but not th least, regarding your comment about platform independent (Windows, Linux, etc.) code, what is the best way to ensure that we have to do minimal work (code re-write) when we port, say for example, Linux LabVIEW stuff (kernel drivers, user space shared library, LabVIEW VIs library) to Windows? Is there a document explaining porting from Linux to Windows?

Re: Linux I/O Drivers for LabVIEW

AdamKemp — Thu, 30 Jun 2011 22:51:18 GMT

Aside from a file name it's not "called" anything. From a user's perspective it doesn't exist. There's just the API, which is DAQmx. If you ask "is DAQmx user mode or kernel mode" then the answer is "yes". It's both. Don't think of DAQmx as a single component or a single file. It's the whole stack. It's just layered. That's how drivers typically work.

What I meant about NI-KAL is that it is not a driver. It's not for a specific device. It's not even for a specific driver. It's a shared component on top of which other drivers sit. Any kernel mode components of any driver from NI is probably going to sit on top of NI-KAL.

"And last but not th least, regarding your comment about platform independent (Windows, Linux, etc.) code, what is the best way to ensure that we have to do minimal work (code re-write) when we port, say for example, Linux LabVIEW stuff (kernel drivers, user space shared library, LabVIEW VIs library) to Windows?"

If you're porting C code you're on your own. We obviously aren't in the business of helping people port C code across platforms. We have a cross-platform development tool (LabVIEW) which we maintain so that users can write their code using our tool and not have to worry as much about platform differences. We handle those differences so you don't have to. If you're working outside our tool then you have to do all the stuff we have to do, and you're pretty much on your own to figure that stuff out.

We can help you figure out how to integrate with LabVIEW, but that's not going to vary much across platforms. Doing a kernel driver, though, will be totally different on Linux than on Windows, and this is not the proper forum to figure out how to write cross platform kernel drivers.

Re: Linux I/O Drivers for LabVIEW

modest — Thu, 30 Jun 2011 23:28:54 GMT

Understood about DAQmx, that confusion is now clear!

AdamKemp wrote:
If you're porting C code you're on your own. We obviously aren't in the business of helping people port C code across platforms. We have a cross-platform development tool (LabVIEW) which we maintain so that users can write their code using our tool and not have to worry as much about platform differences. We handle those differences so you don't have to. If you're working outside our tool then you have to do all the stuff we have to do, and you're pretty much on your own to figure that stuff out.

OK, I completely understand that NI cannot help with writing cross-platform kernel drivers, which is totally fine. Also I understand porting of VIs based on this article.

All I need to figure out now is to how can the user-space shared library (C function APIs) porting problem can be avoided if we use NI's corss-platform development tool (LabVIEW)? Based on the above discussions, I always thought that these C function APIs are a "requirement" and is outside the LabVIEW tool. For what you are saying, it seems that one can avoid (get away with) writing these C function APIs (that sits between the LabVIEW and user mode part of the device driver), if we use the LabVIEW tool. Did I understood that correctly?

Also, how does the Call Library Function Node (CLFN) fits in this picture overall? It seems that if your VIs uses CLFN than they may or may not be portable. How can one avoid using CLFNs?

Re: Linux I/O Drivers for LabVIEW

rolfk — Thu, 30 Jun 2011 23:45:40 GMT

You may want to read through these 3 posts by me at http://expressionflow.com/author/rolfk/. They should give you an answer to how to make your C API such that you do not have problems to port a VI library accessing this through CLFNs. And you can not really avoid using CLFNs if you want to access your own hardware.

Re: Linux I/O Drivers for LabVIEW

AdamKemp — Fri, 01 Jul 2011 15:14:42 GMT

Some drivers don't require a kernel component. Some can even be written entirely using the VISA API primitives available in LabVIEW. If your hardware allows for that (don't ask me what's required, because I'm not a harcdware person, so I honestly don't know) then you don't need a kernel component or a C DLL. You can just write your whole driver in LabVIEW. That is what DAQmxBase is. It's a driver written in LabVIEW. There is no C DLL under it. It's just LabVIEW code.

If for whatever reason you can't do that (again, I don't know enough to tell you what the requirements are) then you may have to write a C DLL and you may also have to write a kernel component under that. At that point a lot of driver developers would prefer to have a C driver usable outside of LabVIEW (and with an API that works well for C) and then build a LabVIEW driver on top of that. For that to work well you usually want to insert yet another layer between your normal C driver and your LabVIEW code, which is that extra DLL. So a complete stack might look like this:

User's LabVIEW code
Your LabVIEW Driver
Your LabVIEW-C driver glue DLL (called via Call Library Node)
Your normal C driver DLL
Your driver's kernel component

The top 3 layers can be entirely portable if you do it right, but the normal C driver may have to be very different under the hood on each platform, and obviously the bottom layer will very different on each platform. DAQmx tries to reduce those cross-platform issues by doing this:

User's LabVIEW code
DAQmx LabVIEW driver
DAQmx-C driver glue DLL (nilvaiu.dll)
DAQmx C driver
DAQmx kernel component
NI-KAL

The bottom two layers are kernel mode components, but we pushed the platform specific stuff down into NI-KAL so that the rest of the kernel component wouldn't have to change as much. Writing NI-KAL is non-trivial, though. It's a big undertaking to understand driver architectures on multiple platforms and write an abstraction layer for them. It may not be worth it for you. Basically, the fewer of those layers you have to write the better.

I have to say at this point that I am not a driver developer. This about the extent of my knowledge of drivers, and if you need more help figuring out how to architect a driver then you should really find a more appropriate forum. I really don't have much more information to give you at this point.

Linux I/O Drivers for LabVIEW

modest — Fri, 01 Jul 2011 18:44:11 GMT

AdamKemp wrote:
So a complete stack might look like this:
User's LabVIEW code
Your LabVIEW Driver
Your LabVIEW-C driver glue DLL (called via Call Library Node)
Your normal C driver DLL
Your driver's kernel component

That's what I was looking for i.e. a completel overview of the stack from OS to application level!

Is this stack model true for Linux too? In particular, do we need the Linux equivalent of the component "Your normal C driver DLL"? In other words, can the "C driver glue code" directly talk to the Linux kernel driver component?

I really appreciate your help and explanation so far! You guys are awesome!

Linux I/O Drivers for LabVIEW

AdamKemp — Fri, 01 Jul 2011 18:55:18 GMT

"Is this stack model true for Linux too?"

I think so, but the DAQmx driver on Linux hasn't been revved in years as far as I know. There's only DAQmxBase, which is totally different (built in LabVIEW directly).

"can the "C driver glue code" directly talk to the Linux kernel driver component?"

It can. That makes sense if you only ever plan on supporting LabVIEW clients. If you want to support C clients then it makes more sense to build the LabVIEW support into a separate layer. That's why we do it.