I'm developing a qml UI using Qt Quick 2D Renderer on an ARM embedded device which runs linux. The device has a LCD screen and some standby mode when it is inactive.
For some reasons (network needs to stay active), suspend to RAM is not an option. However, to lower the power consumption in standby mode it would be good to stop the UI rendering. Can this be achieved with some Qt API?
Connect directly (Qt::DirectConnection) to the QQuickWindow::beforeRendering() signal. That will be in the render thread, the program can wait there on your mutex/condition_variable. GUI thread is unlocked during this step so the application logic will continue working.
http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html
Can probably also override the whole sequence by using QQuickRenderControl.
Related
we have developed QT application in QT5 over raspberry pi, in the application, there is multiple classes.
Application runs very well while that classes's ui over screen for long time, but certain classes's ui scrren comes over screen application gets hang after 2/3/4 hrs(sometimes works very well here also).
Our application uses full-duplex asynchronous serial communication in background, but that remains active even RPI gets hanged(we checked that over putty).
our set is - rpi3B model, rpi official 7 inch screen(via ribbion cable), microcontroller in background
I am working on a project where I connect JTAG to SOC and debug the image on the SOC using the JTAG. The image also runs with watchdog timer that runs during core initialization, and which needs to be reset periodically to prevent the board being reset.
Now for my own understanding I was wondering how JTAG connects to the image and lets us set breakpoint during initialization without worrying about the watchdog timer. I have seen the image running for a long time, under JTAG, without the board being reset by watchdog.
I tried talking to multiple people in my team to try understand this but none of the explanations were satisfactory. Can somebody please explain what exactly is going on in terms of both JTAG and watchdog timer.
The answer depends on the type of SoC you are debugging since the watchdog function normally is an independent function inside or outside the SoC, and I don't see a direct relation to the JTAG interface of the CPU.
Still, some controllers do implement features to stop the watchdog time while the CPU is stopped by a breakpoint. For example, STM32F1 controllers offer the DBGMCU_CR register where you can (even through the debugger) configure whether the watchdog timer shall continue running while the core is halted.
An Eclipse RCP application crashes in the jprofilerti.dll code once I move the app from relatively idle status to full operation.
Some initial profile results are available back on the remote GUI session. This suggests that the configuration of Jprofiler GUI, Jprofiler agent, and network settings is ok.
I wonder if the crash occurs due to buffer overruns. I ask because the network link between the remote JVM and the near laptop JProfiler GUI is very poor with a very low effective bit rate. Is it possible that the target JVM will crash if the remote GUI is too slow about consuming buffered profiling data?
I am very new with motorola mc3190 and c#. I can't deploy my application anymore cause the .exe file is in use by another process. I found that process but I can't kill it. How can I kill a process hanging on my mc3190?
Francesco
To stop a process from being hung make sure you are disposing of all of your objects on exiting.. i just noticed that i would have background processors running on similar devices if i hadn't disposed of the scanner object or etc...
Try disconnecting then reconnecting from your base if you are using a base with USB tether. If that doesn't work, then try doing a warm boot on the device (usually by holding down the power button for five seconds on this series of devices).
How many signals at maximum you can connect to a single slot? If more than one how you can do that? How many slots can you connect to a signal? If more than one how those slots will be executed? How a Qt Program/Application written for one platform (Symbian) can be ported/executed in another
You can easily connect more than one slot to a single signal using the usual way (QObject::connect), which are then called in order of connection when the signal is emitted.
Likewise can a single slot be connected to multiple signals, which is then called whenever one of those signals is emitted. You can even chain signals by connecting signals to signals, which are then emitted automatically whenever the source signal is emitted.
Such information can easily be gained by Qt's excellent documentation.
There may be a theoretical limit on the number of slots that can be connected to a signal, but this limit is surely beyond any practical relevance.
Although porting an application from an embedded system, like Symbian, to a desktop system, like Windows, may involve some additional issues, in general the porting of a Qt application to another platform just requires recompilation on/for that platform, assuming you didn't use any platform-dependent code in the rest of your application, which is usually not neccessary when using Qt.
you can connect as many slots to a signal as you wish. They will be executed in order in which they were connected.
Generally if you use only qt and no other platform dependent API, then recompiling it on target platform should be enough. Have no idea about Symbian though - sometimes Symbian seems to have a bit different rules.