I am trying to connect a Qt client to a LabVIEW server (acquiring analog signals). Can this be done with data sockets ?
Datasockets is an NI technology. It would depend if you can find a Datasocket library that you can call from Qt. I am not well-versed in Qt, but if it possible to call a C++ dll, then this is definitely available with Measurement Studio.
An simpler solution may be just to use TCP/IP which both LabVIEW(for sure) and Qt (presumably) support.
If you need further help, post more details about your app here, or on NI's forums.
Cheers!
Related
I may ask a stupid question. I want to use FreeRTOS as the OS on my NXP MCU MIMXRT1062XXXXB. The MCU connects to a display. I want to use QT to development user interface application. I want to know if it is possible to run QT application base on FreeRTOS on MCU?
Yes it is possible - lots of people do it. My first Google search for this hit this page on the QT website: https://doc.qt.io/QtForMCUs-2.1/qtul-using-with-freertos.html
Hi i am writing a small Qt Application and part of that would be a webRTC video stream for which planned to use Gstreamer.
This is where i can into problems.
Naturally my app is a QtApplication and is thus managed by Qt a processes. Now while planning the code I learned that The component webrtcbin from Gstreamer relies on GLib and the GTK signaling.
so things like
g_signal_emit_by_name
or
g_signal_connect
will run into nirvana without the GLib main loop.
Now after researching and getting a headache over this i hope that i overlooked something and that the power of the crowd-brain can help me with a hint.
An answer to any of the following would help
Is it possible to have Glib signaling inside a QT app?
Is it feasible/possible to run both main loops (QT and GLib)?
Is there a good example on how to connect a gstremer pipeline with pure webrtc (not using webrtcbin)
I'm going to write simple c++ application, server-client, client-client. I would like to develop server in Java or C++ and client in C++.Since now i haven't got any experiences with networking.
So what C++ and Java library or framework do you recommend to begin with?
I've heard that Java is better that c++ for network applications, is that true?
So what C++ and Java library or framework do you recommend to begin with?
Protocol Buffers is likely the easiest framework. It allows cross-platform communication between Java, C++ and Python (and probably a few others by now).
I've heard that Java is better that c++ for network applications, is that true?
No.
Java better than C++ for network applications? False.
If you need to use a framework will depend on what you need to do. For example, to have persistent connections among clients and server, you can use XMPP protocol. There are very good implementations for Java and C++ so you won't need to write a lot of networking code.
Otherwise, just using C++ and Java socket's API will do just fine.
I would like to know if there is some port of QT for On-Time RTOS-32.
Is there any place where I can found more information about this kind of port?
Thanks in advance.
Regards,
Guillermo
Could you not simply use On-Time's own RTPEG-32 GUI library?
There is a slide presentation on porting Qt to an RTOS here, but is a bit general perhaps. You would need at least a pthread implementation for RTOS-32 since that is what the Qt source uses.
The article Porting Qt for Embedded Linux to Another Operating System lists five things you have to do to port Qt for Embedded Linux to another OS. From the article:
There are several issues to be aware of if you plan to do your own port to another operating system. In particular you must resolve Qt for Embedded Linux's shared memory and semaphores (used to share window regions), and you must provide something similar to Unix-domain sockets for inter-application communication. You must also provide a screen driver, and if you want to implement sound you must provide your own sound server. Finally you must modify the event dispatcher used by Qt for Embedded Linux.
Is it really this easy to port Qt to another OS, or have i missed some information?
Another important component to port would be QAtomic, to ensure that you can have atomic operations and implicit sharing working well. See also
http://labs.trolltech.com/blogs/2007/08/28/say-hello-to-qatomicint-and-qatomicpointer/
Since Qt has been ported a large number of times it seems logical that it would be inherently simple. However the issue really is on the platform you are porting to and how many features it currently supports.
Assuming you find all those things easy, then the port is easy.
After investigating this in more detail I have come to the conclusion that the article "Porting Qt for Embedded Linux to Another Operating System" assumes that you are porting Qt to a very "linux-like" OS.
I have attempted this and currently making progress.
Some difficulties:
IDE - I have to manually add all Qt files and fight the compiler with #ifdefs until it builds with all dependencies in place.
Linux(ness) - I've had to disable all Linux/Windows things that are not supported in my target OS: threads, sockets, processes. Even the timers are slightly different.
Tips:
Start small : I compiled QtCore as a standard lib within my IDE, next up is QtGui which is a behemoth compared to QtCore.
I plan to run only a single QThread, so I have to artificially made a Thread object to avoid null pointers. You cannot compile out Thread information as it is key to all QObjects.
So far I have an qeventloop running within a qcoreapplication.
I wrote some inline assembly but had serious difficulties with my IDE and compilation. I left it in C++ and let the assembler handle it for me. Because I am single-threaded, I am not too concerned with shared data/ exclusive access as required by the atomic operations.