In my qt program I include the headers for i2c/smbus (as I did for other projects, also with yocto but different SoC vendor).
Kernel 4.14.24
extern "C"
{
#include <linux/i2c.h>
#include <linux/i2c-dev.h>
#include <i2c/smbus.h> << FAIL: i2c/smbus.h: No such file or directory
#include <fcntl.h>
#include <sys/ioctl.h>
}
In the conf/local.conf file I added the i2c-tools
IMAGE_INSTALL_append = " i2c-tools "
Built the toolchain and checked the rootfs for i2c/smbus.h. No luck.
i2cdetect/get/set works (did before adding the i2c-tools too).
Functionalities implemented by /dev/i2c-0:
I2C yes
SMBus Quick Command yes
SMBus Send Byte yes
SMBus Receive Byte yes
SMBus Write Byte yes
SMBus Read Byte yes
SMBus Write Word yes
SMBus Read Word yes
SMBus Process Call yes
SMBus Block Write yes
SMBus Block Read yes
SMBus Block Process Call no
SMBus PEC yes
I2C Block Write yes
I2C Block Read yes
I don't see the smbus.h in the rootfs: /usr/include/i2c/
There is a i2c-core-smbus.c where the functions i2c_smbus_......() are located but no h-file.
edit: added Kernel version.
The comment from #0andriy is correct, you need the libi2c-dev package.
Related
I wonder if there is any command to show the enabled features of an MVAPICH installation similar to the one that we can find for OpenMPI:
ompi_info
Especially, I am interested in knowing if multi-thread support is enabled.
I would recommend just running a simple test program like this:
#include <stdio.h>
#include <stdlib.h>
#include <mpi.h>
int main(void)
{
int lvlrequired, lvlprovided;
lvlrequired = MPI_THREAD_MULTIPLE;
MPI_Init_thread(NULL, NULL, lvlrequired, &lvlprovided);
if (lvlprovided < lvlrequired)
{
printf("Required level of threading support *not* available\n");
}
else
{
printf("Required level of threading support *is* available\n");
}
MPI_Finalize();
return(0);
}
On my Ubuntu laptop with standard OpenMPI:
me#laptop$ mpicc -o threadcheck threadcheck.c
me#laptop$ mpiexec -n 2 ./threadcheck
Required level of threading support *not* available
Required level of threading support *not* available
which agrees with ompi_info:
me#laptop$ ompi_info | grep THREAD_MULTIPLE
Thread support: posix (MPI_THREAD_MULTIPLE: no, OPAL support: yes, OMPI progress: no, ORTE progress: yes, Event lib: yes)
but if I request MPI_THREAD_SERIALIZED
me#laptop$ mpiexec -n 2 ./threadcheck
Required level of threading support *is* available
Required level of threading support *is* available
Hope this is useful.
David
i'm trying to create a simple QT program that allows me to launch avrdude without using command line operations.
I saw that with Qprocess it's easy to launch any kind of program and I tried succesfully with simple programs like Explorer Word and Others.
The problem is that when i try to open cmd.exe nothing happens, even if i try to pass a batch file containing all the information to launch correctly avrdude.
Here's the code
QProcess *process = new QProcess(this);
process->startDetached("cmd.exe",QStringList()<<"C:/avrdude/avr.bat");
I wrote a minimal sample application which shows how to start cmd with a command using QProcess::startDetached() (on button click):
// standard C++ header:
#include <iostream>
// Qt header:
#include <QApplication>
#include <QMainWindow>
#include <QPushButton>
#include <QProcess>
int main(int argc, char **argv)
{
// main application
#undef qApp // undef macro qApp out of the way
QApplication qApp(argc, argv);
QMainWindow qWin;
QPushButton qBtn(QString::fromLatin1("Start cmd"));
QObject::connect(&qBtn, &QPushButton::clicked,
[](bool) {
bool ret = QProcess::startDetached(
#if 1 // let Windows search for cmd.exe in %PATH%
QString::fromLatin1("cmd.exe"),
#else // define exact path of cmd.exe
QString::fromLatin1("C:\\Windows\\system32\\cmd.exe"),
#endif // 1
QStringList()
<< QString::fromLatin1("/K")
<< QString::fromLatin1("echo Hello"));
std::cout << "QProcess::startDetached():"
<< (ret ? "OK." : "Failed!") << std::endl;
});
qWin.setCentralWidget(&qBtn);
qWin.show();
return qApp.exec();
}
The Qt project file is left as exercise. (Sorry, I used CMake for this.)
Please, note the #if 1. If 1 is replaced by 0 the alternative code with full path is used. (During chat session we examined special problems with starting the cmd.exe.) On my system, both alternatives did as well.
(My system: Windows 10, VS2013, Qt 5.7)
I too have been working on a Qt program where there are a couple calls to AVRDUDE. This is what worked for me. Here's the code I made for a read of the AVR device through AVRDUDE, followed by a couple of comments.
void MainWindow::call_AVRDUDE_read() //AVR READ
{
QProcess CommandPrompt;
QStringList Arguments;
QString COMPortUsed = (ui->COM_Port_Used->text()); // get the COM port from the user off UI
Arguments << "/C avrdude -c arduino -P "+ COMPortUsed +" -b 115200 -p ATmega328P -e -U eeprom:r:fromEEPROM.bin:r";
CommandPrompt.start("cmd",Arguments);
CommandPrompt.waitForFinished();
}
Here's something else which may well influence things in your application. In my case, I am reading the AVR's EEPROM. There is another routine that writes the EEPROM, but it is essentially the same as above, but a different script is sent.
In BOTH these cases, the AVRDUDE operation takes a few seconds to perform its task. When you use the QProcess::startDetached(), it has the disadvantage that control will return IMMEDIATELY after the AVRDUDE script is called through the QProcess. This can cause problems, if for instance you wanted to (as in my case) read the contents of the EEPROM and try to do so before the read actually completes.
An alternative to startDetached() you might consider trying is shown below. This will retain control until the process is finished, which may be pretty important to you. Use these two lines to replace the startDetached() call you are currently using.
CommandPrompt.start("cmd",Arguments);
CommandPrompt.waitForFinished();
This will wait for the AVRDUDE process to finish before control is returned.
The take away here though is that QProces::startDetached() may return prematurely in your application. Just beware of that.
I am using Arduino and NetBeans in my project. My final work is to switch from Arduino program to Java. I managed to install an Arduino-NetBeans plugin as described in Arduino - NetBeans Plugin detail
My Arduino program includes
Serial.begin(9600); /////// Serial.print();
I get an error saying that "Unable to resolve identifier Serial". How can I solve this?
this is what you have to add to your source file:
#include <Arduino.h>
// imports the Serial class to allow log output
extern HardwareSerial Serial;
then it will work.
As answered by cgo you can add extern HardwareSerial Serial;
Or into your Project Settings, go to BUILD > C++ COMPILER > PREPROCESSOR DEFINITIONS and add: __AVR_ATmega328P__ (if you are working with Arduino UNO)
The message "unable to resolve identifier Serial" means that the compiler is searching for the variable Serial, but cannot find its declaration. You should check if you include all header files properly. I don't know the NetBeans plugin, but I guess the Serial-structure/class is initialised there.
If that is not helping, you should check the compiler otions and set them to default, as described on the project-site.
I run a Qt application, what I want to know is this running binary file name.
I must (partially) disagree with the other comments that it is not a Qt question: There is a Qt method QCoreApplication::applicationFilePath() which gives the directory+filename of the executable.
On Linux this will try to use /proc, and on Windows perhaps GetModuleFileName(). According to the docs it will fall back to argv[0].
You could then use QFileInfo to split it into an executable name and a directory.
QFileInfo(QCoreApplication::applicationFilePath()).fileName()
The Qapplication parses the commandline arguemnts, the first entry is the name of the executable - this is roughly the same as argv[0] in standard C but has a few extra complexities on windows if you have a Unicode build or if the application is started as a service
See http://doc.qt.io/qt-5/qcoreapplication.html#arguments
Again not really a Qt question. To find the name of the binary file executed it would be something like.
#include <iostream>
using namespace std;
int main(int argc, char **argv)
{
cout << argv[0] << endl;
return 0;
}
Here is the code:
#include <QtCore/QCoreApplication>
#include <QProcess>
#include <QProcessEnvironment>
int main(int argc, char *argv[])
{
QProcessEnvironment env;
// Environment variables required by CGI apps
env.insert("QUERY_STRING", url.encodedQuery());
env.insert("REQUEST_URI", url.toString());
env.insert("REQUEST_METHOD", "GET");
env.insert("REMOTE_ADDR", pSocket->peerAddress().toString());
//==========
QProcess process;
process.setProcessEnvironment(env);
process.start("php-cgi",QProcess::ReadWrite);
process.write("<?php print_r($_GET); ?>");
process.closeWriteChannel();
process.waitForFinished();
qDebug(process.readAll().data());
return 0;
}
Qt Creator reports more than 14000 errors. Here is a small sample of them:
In file included from ../QProcess/main.cpp:2:
../QProcess/QProcess:1: error: stray ‘\177’ in program
../QProcess/QProcess:1: error: stray ‘\2’ in program
../QProcess/QProcess:1: error: stray ‘\1’ in program
../QProcess/QProcess:1: error: stray ‘\1’ in program
In file included from ../QProcess/main.cpp:2:
../QProcess/QProcess:1:8: warning: null character(s) ignored
../QProcess/QProcess:1: error: stray ‘\2’ in program
Here is a simple example instance of this error. The contents of a file called new.cpp:
#include <iostream>
int main(int argc, char *argv[])
{
std::cout << "Brand new." << std::endl;
return 0;
}
Now compile it:
ppu32-g++ new.cpp -o new
No problem. Let's compile it again:
ppu32-g++ new.cpp -o new
OMG! Screen after screen of errors! Most of these errors look like this:
./new:1: error: stray '\177' in program
The problem is that the compiler is trying to use the new file in the current directory, as the C++ standard library <new>; used by <iostream>. In fact any file in the current directory, named after a C++ standard library header, which is used in the code being compiled, will likely cause an error. That our problem file is an executable obfuscates the error messages.
It doesn't occur on all the gcc machines I've tried. ppu32-g++ 4.1.1 on PS3 Cell Fedora Linux certainly chokes.
If that problem arises not on every host then probably difference in the compiler. Difference is likely in the header files directory scan order.
Such error should not arise if standard headers directory scanned before others.
As a workaround its enough to remove project target file manually befor building target. But this is not a programmers way (which are very lazy creatures).
Programmers way - is to learn QMake to delete target file just before project sources compilations (but under this way link phase will be done permanently). For me (QMake 2.01a under Linux) this is achived by addition of following lines into project file:
deltarget.commands = $$QMAKE_DEL_FILE $$TARGET
QMAKE_EXTRA_TARGETS += deltarget
PRE_TARGETDEPS += deltarget
This declares target deltarget which becomes built before current project.
This sample uses undeclared in QMake's manual variable QMAKE_DEL_FILE which used to remove files (its content of course platfrom-dependent).