Qserialport Not Found

[Shelly Takacs]

Ichecked the file path from my friend's Pi which works without error is /usr/include/arm-linux-gnueabihf/qt5/QtSerialPort/, and the files exist in the same path on mine but Qt creator still shows the "can't found" message. And the Project MESSAGE: Warning: unknown QT: serialport.

Also, my friend's pi has a weird problem is the QSerialPort including only works(I mean included without error) under one specific user, this makes me wondering maybe this only works for the user who executed the apt install ?

There seems to be a regression in QSerialPort from Version 5.12.4 to 5.12.5. I'm not receiving any data from QSerialPort, QSerialPort::readyRead is never emitted. Data written to QSerialPort does arrive at the device though.

The regression is confirmed by the auto test in qtserialport/tests/auto/qserialport/qserialport.pro using two virtual ports set up with com0com. Tests with Qt 5.12.4 are a pass, several tests with 5.12.5 are failing with "Timed out when waiting for the read or write".

In part one of this blog series, I gave an overview and described the hardware setup for an IoT example application that uses a Qt-based desktop program and an Arduino with XBee wireless modules. In part two, we'll cover the software configuration and programming.

The XBees need to be programmed and configured so that they can communicate with each other. Both applications interact with the XBee as a serial port device. Our Qt application will use Qt's QSerialPort class to interact with the XBee and the Arduino will use Arduino's built-in SoftwareSerial class to control the XBee.

In a Qt application the static function QSerialPortInfo::availablePorts() will return a list of QSerialPortInfo objects that tells us information about available serial ports such as port name, manufacturer, serial number, and other information. Some of these properties may be empty and will depend on the device you're using.

You can decide which is the best way to find your device using the available information given in the QSerialPortInfo object. The downloadable source code uses the serial number to select the device, and also confirms that the port name is correct for the platform. (It will be different for each platform.) If running the example code, make sure to change the serial number that is hardcoded in the m_deviceSerialNumber property in serialportdesktop.h. If you don't know the serial number of the device, run the application and look at the debug output. It will print out the serial number, among other information, for each serial device it finds.

When you create the QSerialPort object, pass to the constructor the port name as it is found in the QSerialPortInfo object, then call the object's QSerialPort::open(QIODevice::ReadWrite) function to open it as a readable and writable device.

To configure an XBee you must put it in 'Command Mode' before sending commands. Once in command mode it will acknowledge and, if necessary, respond to commands. Command mode will exit automatically after a set amount of time (by default 10 seconds) or when the exit command mode command is sent. Each command will return "OK\r" if it is successful. Enter command mode by sending the string "+++", when the "OK\r" string is returned then you can begin sending other commands. The command to exit command mode is "ATCN\r".

The XBee device should now be ready to send and receive data. In Qt 5.7, QSerialPort has several ways to read data. Normally, I would connect to QSerialPort's readyRead() signal to catch when data is available, but in this use case I found that this signal is not always emitted even when there is data ready to be read.

To work around this I set up a timer to intermittently call QSerialPort's waitForReadyRead() with a small wait time and then used QSerialPort's read(char* buffer, int maxLength) function, which returns the amount of data read into the buffer and can be used to determine if any data was read and set to the buffer passed in as the first argument. QSerialPort::write(char* data, int maxLength) can be used to send data.

Creating a SoftwareSerial object with 2 arguments passed to the constructor, 2 as the first argument and 3 as the second argument indicates Arduino pin 2 will be the RX pin and pin 3 will be the TX pin. After this, the object function call begin(9600) will initialize the serial port and make it ready to read and write to, the 9600 argument sets the baud rate to 9600 bps. The SoftwareSerial class sets the serial port's other properties to the same as we set in the C++/Qt application (SERIAL_8N1, or 8 data bits, no parity, one stop bit).

Just like with the C++/Qt application, we need to put the XBee in command mode and set the channel and network ID to 18 and 68 respectively. Notice these values are the same values set to the other XBee. The matching values are required for two XBees to communicate with each other. We can use the SoftwareSerial object's write() function to send commands, and the available() function to see if data is available to read, and read() to read new incoming data.

Two other commands you may find useful are "ATRE\r" and "ATWR\r". "ATRE\r" resets the XBee to default settings. "ATWR\r" saves the current configuration to non-volatile storage, respectively. Expect an "OK\r" response for both of these commands, as well. A larger list of XBee commands, along with other XBee info, is available here.

When running the example code, look for a switch on the Arduino/XBee shield with options for DLINE or UART and make sure it is on DLINE. Deploy and run the Arduino application first and open the debug output window. When you see a message telling you the XBee is configured successfully, run the C++/Qt application. Look at the GUI window or the debug output for the C++ application. When you see a message indicating the XBee configuration is successful, you can then hit the 'Turn On' or 'Turn Off' buttons to send messages over the XBee devices to control the LED on the Arduino.

Now, when the Arduino application receives the 'Turn On' message from the XBee (simply a 'T' char), pin 4 will output power and the LED will turn on. When the Arduino application receives the 'Turn Off' message from the XBee (a 'F' char) the application will turn power off to that pin and the LED will shut off.

You'll also see that the desktop application intermittently sends a ping to the Arduino (a 'P' char) and when the Arduino receives this it will respond with a ping back to the Desktop XBee (also a 'P').

I hope this blog has helped you understand XBees enough that you can integrate them into your own applications, whether you have two desktops chatting with each other, or a Raspberry Pi application controlling an Arduino robot.

Yea you are right but I was I guess hoping that there was something I was missing in a pass through serial driver or something that would allow access to things. As at this moment I am kind of clueless on how to write my own serial driver program to read what is needed ON the windows side of things.. Im learning the arduino OK but windows programming seems WAY more daunting.

bsohn:

Yea you are right but I was I guess hoping that there was something I was missing in a pass through serial driver or something that would allow access to things. As at this moment I am kind of clueless on how to write my own serial driver program to read what is needed ON the windows side of things.. Im learning the arduino OK but windows programming seems WAY more daunting.

No, what you are asking for can not be done easily. However, writing a program to read serial data is not as complex as you would think. Espicaly if you use something like QT that has a QSerialPort class.

OK well I am trying to read an SDK output from a Game in Windows. It actually have since found out gets written to a .dll file from the Mapped Memory Files for the game.. Or at least that was what was explained to me by some who have done Windows Programs for it.. Basically I am sort of wondering if I can read an SDK output over serial with the Teensy without having to actually have a helper program to find the file and the information if I know where to point it..

So in a way it is sort of what Coding Badly mentioned in that I am wondering if I can make API type calls calls directly from the teensy to read information rather than having to have a program that makes those calls and translates them into a different Serial format for the Teensy to read and use.

Having an issue with Lightburn crashing, usually it happens while the computer is connected to the laser. After making a cut if I go back to the computer it is locked up and I have to close the program and restart the laser. Today while working on a design it crashed continually. I have a brand new computer which should handle the program easily. After reading through several forum posts I found where a call stack should be captured. Just looking to see if anyone else is having the same issue. I am getting a not responding error and the whole screen dims.

I also ran reliability monitor on the laptop and this is the explanation given for the crash.

Description

A problem caused this program to stop interacting with Windows.

Faulting Application Path:C:\Program Files\LightBurn\LightBurn.exe

Hi, I'm trying to build a diy ambilight system for my monitor. I'm using a Arduino nano and ws2812B 60LEDs/m 5V, powered with a 5V 8A ps.

First I installed hyperion, then flashed the arduino with this sketch and tried to start Hyperion with: sudo systemctl start hyperiond@root (Looks like hyperion needs to get root permissions access the serial port where my arduino is connected, I read on this forum it'scommon with arduino and ws2812B). Anyway, I set up everything (I'm able to access and use the web interface), but nothing will happen on the LED side, even if I try to use "Identify" to make the LEDs blink. Log says:

Do you have any idea why this is happening? Am I missing something, or maybe it's some permission conflict?

Additional info: I'm working on arch linux, Kernel is mainline updated today (1st feb) to v6.1.8.

uname -sro

3a8082e126