qnx and windows

[souske]

Hi,

This problem is a mix of several smaller ones but I suppose the RT is the common ground here.

Most of the drivers for a given OS are developed and copiled under given OS. How to solve the problem of software (and driver) development on a computer

with a different OS than the target machine? For example software development in LV on Windows and execution on QNX OS?

I know that it is possible to use EDM mod (Microprocessor SDK) to compile for other OS and architectures (I've done that and it works).

But where do hardware drivers compiled for QNX fit in? Even if you use MHDDK (if I understand correctly) one compiles the driver (which is written in C)

on the machine with QNX OS. How am I able to use it in a software that I'm developing under Windows?

Including external code is limited. CIN and System Exec are not supported by qnx target and CLFN will probably join that group too (I'm checking it now).

Does any one has any suggestions how to bite this problem? Or maybe my approach is wrong?

Just to clarify. I develop software under Windows with LV8.2 and want to communicate with Hilscher Profibus card on a machine with QNX Neutrino 6.3.2.

--

regards

souske

[Rolf Kalbermatter]

QUOTE(souske @ Jan 31 2008, 04:32 AM)

Hi,

This problem is a mix of several smaller ones but I suppose the RT is the common ground here.

Most of the drivers for a given OS are developed and copiled under given OS. How to solve the problem of software (and driver) development on a computer

with a different OS than the target machine? For example software development in LV on Windows and execution on QNX OS?

I know that it is possible to use EDM mod (Microprocessor SDK) to compile for other OS and architectures (I've done that and it works).

But where do hardware drivers compiled for QNX fit in? Even if you use MHDDK (if I understand correctly) one compiles the driver (which is written in C)

on the machine with QNX OS. How am I able to use it in a software that I'm developing under Windows?

Including external code is limited. CIN and System Exec are not supported by qnx target and CLFN will probably join that group too (I'm checking it now).

Does any one has any suggestions how to bite this problem? Or maybe my approach is wrong?

Just to clarify. I develop software under Windows with LV8.2 and want to communicate with Hilscher Profibus card on a machine with QNX Neutrino 6.3.2.

How do you get your QNX system to work with LabVIEW? To my knowledge there is no direct support for QNX by NI other than possibly through LabVIEW Embedded.

If you use LabVIEW Embedded there should be the C code node (a bit similar to the Formula Node) that allows you to link to external code by writing calls to external libraries. Those libraries of course must have been created outside of LabVIEW with the toolchain for your target. How you do write these libraries and device drivers is entirely outside of the scope of LabVIEW. It does not care nor could it!

So for your main question you will have to take it up with the QNX support people for sure.

If you are not using LabVIEW embedded, the only way I see that your LabVIEW software could communicate with your QNX system would be a server application on the QNX system that access your Hilscher card and provides an RPC interface through TCP/IP for instance to your LabVIEW application. Only LabVIEW Embedded could possibly produce code that could directly run on your QNX target. But unless NI provides a ready made example for integrating LabVIEW Embedded with your specific hardware plattform and OS however (they obviously can't and won't create this for every possible target system out there), providing the necessary glue code to integrate your platform and OS into LabVIEW Embedded is a tedious job that takes up some serious time even if you are completely familiar with both your target plattform and LabVIEW Embedded (and if you are not, expect even a lot more time to be needed).

Rolf Kalbermatter

[souske]

Thanks for the reply.

As I wrote I'm using LabView Embedded Developmnet Module with some add-on that I found on ni.com that allows me to cross compile for QNX.

The standard C code node (I assume you mean Code Interface Node) is not supported by QNX target, at least that's what the error says:

"Code Interface Node: Node not supported in current target".

Right now I'm trying to use Call Library Function Node. I compiled the windows dll example for qnx (I used QNX Momentics) but I still get

some linking errors when I try to build it the project in LV:

C:\tmpo\sysexec\QNX_Console\QNX_Application\sysexectest.o: In function `sysexectest_BlockDiagram':

C:\tmpo\sysexec\QNX_Console\QNX_Application\sysexectest.o(.text+0x2b3): undefined reference to `avg_num'

cc: C:/QNX632/host/win32/x86/usr/bin/ntox86-ld caught signal 1

Any ideas what might cause the error?

Thanks for the idea client-server arch. here, but I will keep trying to use EDM.

--

souske

[Rolf Kalbermatter]

QUOTE(souske @ Jan 31 2008, 10:21 AM)

Thanks for the reply.

As I wrote I'm using LabView Embedded Developmnet Module with some add-on that I found on ni.com that allows me to cross compile for QNX.

The standard C code node (I assume you mean Code Interface Node) is not supported by QNX target, at least that's what the error says:

"Code Interface Node: Node not supported in current target".

Right now I'm trying to use Call Library Function Node. I compiled the windows dll example for qnx (I used QNX Momentics) but I still get

some linking errors when I try to build it the project in LV:

C:\tmpo\sysexec\QNX_Console\QNX_Application\sysexectest.o: In function `sysexectest_BlockDiagram':

C:\tmpo\sysexec\QNX_Console\QNX_Application\sysexectest.o(.text+0x2b3): undefined reference to `avg_num'

cc: C:/QNX632/host/win32/x86/usr/bin/ntox86-ld caught signal 1

Any ideas what might cause the error?

No sorry. It's some time that a played with the LabVIEW Embedded Module, and that was with LabVIEW 7.1 too. Also I didn't incorporate any external code at all. Just played with the provided example framework for the Linksys WRT-54L router.

But no I didn't mean the Code Interface Node or CIN. As I have written many times here and in other places, CINs are legacy and NI is not going to go into any trouble to support CINs on newer platforms. They maintain them on the platforms where it is already working but for the rest CINs are dead. If and how the Call Library Node can work on your system is also a big question. If there is a clear and well defined standard for shared libraries on QNX it is quite possible that LabVIEW supports it. But I never went as far as using external shared libraries for LabVIEW Embedded so I'm not sure how they would support that. It looks likely to me that this would have to be part of the extra code one needs to write to interface LabVIEW Embedded with the external toolchain, but on the other hand I'm not sure how LabVIEW Embedded would provide hooks to do just that.

What I meant is that I think to remember that LabVIEW Embedded should have a C Code structure. It would sit on the diagram, look like a Formula Node and allow to type in C code that is then interfaced to the variables at the border. This C code will then be passed to the external C code compiler and of course could also contain calls to library functions present on the target system including your own shared libraries or object modules. I'm not fully sure that exists, never used it, but believe that I read once something about it. It is in that way much like the VHDL Structure for LabVIEW FPGA where you can write in VHDL code to be passed to the FPGA compiler.

Note: Ok I read on the NI site about it and it is called there the "Inline C Node".

Rolf Kalbermatter

[souske]

Well I found the "C inline node" but this one is also "Not supported by current target". This structure is visible in functions palette only

if you writing software for a target that supports it so It took me some time to even find it, because if you're in qnx (or even blank vi without

a project) it won't be there and you won't be able to find it using search option. I don't know if it's a problem of a trial version of my MicroSDK

or is it just THAT limited? I find it hard to believe especially when you mention that NI treats CIN as a legacy.

I'll keep on hitting that wall

--

souske

[souske]

Now that is really strange. Maybe mondays are not that bad. Today the inline C nodes ARE supported

I really don't understand how is that possible, but I'm not going to agrue.

After including .o file (in console application properties) C code works like a miracle and there problem

with profibus drivers is no more

--

souske