I am developing a project using the QCanBusDevice library provided by Qt in 5.10 version. However, the readFrame() API to read can frames from a QVector input buffer is too slow. It can't keep up with the amount of CAN messages the processor is throwing.
I want to be able to flush the buffer and obtain the latest data on the wire, however, the library doesn't provide any API to flush the input buffer (please let me know if I missed that).
Is it possible to modify this library and add a flush API?
Thanks!
"Is it possible to modify this library and add a flush API?"
Of course it is. Qt is open-source, you can download the source code, make the modification you need, recompile the library and then use your modified version with your application.
At the place I work we do exactly this to add a few bits and pieces we need and fix some bugs.
But if you do this, please submit your changes back to the project so a) others can benefit, and b) you don't have to maintain your own fork indefinitely (at my company we, of course, also do this).
Related
I need to extract audio from video and save it. FFmpeg has command for this purpose. I wonder if it is a right way to execute ffmpeg from my code and not to write code with their API functions.
The lack of this approach is that I use Qt Framework and need cross-platform application. Sometimes (especially in windows, because PATH variable doesn't set up automatically so call ffmpeg won't work) a user will need to indicate path to executable file to run in command line.
So both variants are possible to realize, but which is the best and correct one?
I don't really want to use their API because it is not so easy to understand and will take time to write my own code.
Thanks for any advice!
Using standalone ffmpeg seems to be preferred in your case. You will have to bundle ffmpeg and it's dependencies along with your application. However there is no need to set or use PATH or other environment variables to launch ffmpeg. You should do it by supplying full path to ffmpeg executable.
Using libav API is indeed rather tricky. And I would like to mention that in general (depending on codec) ffmpeg and libav should not be considered stable and you should spawn a separate process to protect main executable from potential crash in this case as well. So complexity of this approach is much higher compared to first one.
Disclaim: I never used Qt with ffmpeg together myself, but have much experience with Qt especially.
Qt tends to try having everything in their library, wrapping many other content for convenience. Most of the time (All those I tested), it is still possible quite easily to use the original library without troubles, but the Qt facilitate integration.
As an example: QOpenGLWidget is a wrapper for OpenGL with their widget system, adding signals and slots, etc. I made some test using normal OpenGL and it worked fine.
In another project, we(my team, not me particularly) used ffmpeg to display video on a QtWidget. It works with limited problems (due to other architectural requirements).
Considering your use case, and especially that you are using ffmpeg for background processing and not for displaying video, you may IMO go ahead with high probability of success.
I am able to use the aux clock API's from Kernel Image project, but when tried to use the same API's for example sysAuxClkRateSet( int ticksPerSecond ) in the RTP Project, i am getting undefined reference to the sysAuxClkRateSet error. I'm working on Vxworks 7.0. I added the API to the custom system call list and tried it, the compiler errors are getting resolved, but when the control hits that API, it is failing to work and the board is rebooting. I'm using TI Sitara a9, 4377 board. Any inputs on how to get it worked would really help. Thanks in advance !!
sysAuxClkRateSet is a Kernel Space API, and is not present in the user mode header files.
In order to use this functionality from an RTP you can either use a mechanism such as a msgQ, to send commands from an RTP to a kernel space task, or write a custom system call to expose this function.
For this particular use case, you would probably want to create a static system call, which means you can call sysAuxClkRateSet directly from the RTP. This would require modifications to, and rebuild of, the VxWorks libraries, so you will probably want to base your kernel on a VSB project rather than the default libraries - although if you are using VxWorks 7 you will already have a VSB.
sysAuxClkRateSet is kernel space API hence will not work in RTP.
For fun i'd like to write code that runs on OSless hardware. I think writing code that will run in a VM (like VMware or virtualbox) would be good. However i don't want to start from scratch. I'd like the C++ runtime to be available. Something that allows me to read/write (maybe FAT32 filesystem code). Graphics for text and if i can graphics for drawing on screen (pixel by pixel. sdl support would be a bonus but not essential).
I'll write my own threads if i want them. I'll write everything else (that i want to use) needed for an OS. I just want a basic filesystem, gfx and keyboard/mouse support.
Take a look at the list of projects on osdev.org - (http://wiki.osdev.org/Projects) - most of these are hobbyist, open-source and range from just-a-bootsector through to proper threads/graphics/terminal support.
Minix3 targets your desires pretty well.
You should definitely take a look at OSKit (links to source code on this site are dead but there is a mirror here). Unfortunately, OSKit has no support for C++ but using this information you may be able to use GCC libraries.
What logging facilities do you use whit Qt ?
Do you choose qDebug(), qWarning(), qCritical(), qFatal() methods, or maybe something like Log4cpp (Log4cplus etc.), or maybe some custom-maked code ?
If you are just working in a single thread, qDebug and such work pretty well, or you can modify them somewhat by installing your own handler with qInstallMessageHandler in QT 5.0+, or qInstallMsgHandler in old versions.
Note: Older versions of qDebug() etc., where you used qInstallMsgHandler (now deprecated, e.g. http://doc.qt.io/archives/4.6/qtglobal.html#qDebug) were not thread-safe. If you use threads, they would crash/break badly. Internally it was using QTextStream, which was reentrant, but not thread-safe.
Since Qt 5.2 supports categorized logging: http://qt-project.org/doc/qt-5/qloggingcategory.html . This allows you to split up your logging messages into a (hierarchy of) categories, and fine tune which is logged, and what not.
Existing C++ logging libraries are too heavy for my tastes, so I have created a custom front-end based on ideas from Logging in C++ for the Qt qInstallMsgHandlerq back-end. It's cross-platform and thread-safe. Someday I'll clean up the code and release it to the world :)
An interesting alternative for Qt is QxtLogger.
Log4Qt is a port of famous log4j to the Qt world.
QDebug is the best way to go, as it presents out-of-the-box integration with the rest of the framework, doesn't make you dependent on 3rd party code and covers pretty all of the logging needs.
I'm not using Qt, but for logging I'm using a modified version of Dr'Dobb's Logging in C++. The original code can be found here.
My modifications are specific to the Microsoft Windows platform (fopen doesn't allow file read sharing) and can be found here.
Regarding the answer saying "Unfortunately qDebug() etc. are not thread-safe. If you use threads, they will crash/break badly. Internally it uses QTextStream, which is reentrant, but not thread-safe."
I seriously doubt that, qDebug is designed to be used concurrently. File a bug if that isn't true.
Depends on how you want to use that log data.
If it is used for debugging at runtime, qWarning() would do just fine.
If you need to debug retrospective (usually server side code), plain old text files are the best. It is best to organize these log files by day log is written.
You can have a look at: https://github.com/netresultsit/uniqlogger
LGPL
thread-safe
multiple backends: file, colored console, network, rsyslog
file rotation by size and number of files
support compression of previous files
etc.
The subject says it all - normally easy and cross platform way is to poll, intelligently. But every OS has some means to notify without polling. Is it possible in a reasonably cross platform way? (I only really care about Windows and Linux, but I use mac, so I thought posix may help?)
Linux users can use inotify
inotify is a Linux kernel subsystem
that provides file system event
notification.
Some goodies for Windows fellows:
File Change Notification on MSDN
"When Folders Change" article
File System Notification on Change
The Qt library has a QFileSystemWatcher class which provides cross platform notifications when a file changes. Even if you are not using Qt, because the source is available you could have a look at it as a sample for your own implementation. Qt has separate implementations for Windows, Linux and Mac.
There's File System Events API as of Leopard.
I don't think POSIX itself has facilities for that. The closest to cross-platform I've seen is FAM, which seems to work for Linux, BSD, and Irix, but I'm not how easy it would be to port it to Windows and MacOS.
I've actually built this system before for use in a commercial C++ code base- as long as you don't need every weird thing under the sun, the Windows and POSIX systems have a lot of overlap you can abstract.
POSIX: Use inotify- it is a whole system literally built for this job
Windows: Use "change events". You have to build more of the glue and reporting yourself (all the APIs you need are available, there's just not the 1-stop-shopping inotify gives you).
The common things you can detect in your "notification thread" for forwarding events are:
1) Basically any invasive operation boost::filesystem supports, with the (possible) exception of modifying permissions. This is things like moving, creating, deleting, copying folders and files.
2) Reads and writes to files (esp. writes). Be aware that if you're using async I/O the notifications can show up out-of-order.
3) When a new volume comes in, such as somebody connecting a flash drive.
inotify especially gives you an insane level of fine-grained control, Windows less so. With inotify you can literally monitor everything the filesystem is doing in near-real time if you really want to. I know #3 is possible with both without polling, but be aware that it can be really tricky to get it working correctly- on either system.
I believe OS X now has appropriate hooks/callbacks because they were needed for Spotlight indexing.
On linux you'll have the additional trouble that there are multiple file systems commonly used. If you need the functionality for only a limited amount of files/directories, I'd try about actively looking for modifications at regular intervals.
libevent or libev seem to be what you want, though I haven't used them.