@elypheldia said in How I listen serial port with writing client code?:

Sorry if used the wrong term. I am new on qt. I wanted to indicate that I read the data I wrote to the tnt0 serial port from terminal with using cat /dev/tnt0. But How can I do this with client code instead of reading from terminal. I just wanna open the tnt1 serial port from code., and I wanna read from there.

You are confusing to me.
Do you want to use /dev/tnt0 or /dev/tnt1?

With the code example you have provided, you are writing hello on serial device /dev/tnt0. Is this working?

You have defined a slot MySerialPort::readData() , which is called when data are ready to be read from serial port.
I have proposed you some changes to display debug message when slot is called. Is this slot called?

I don't know:

what kind of device is connected to this serial port? if the serial port configuration is correct according to attached device? the attached device communication protocol: It is a binary or text protocol? Are carriage return or line feed required?

Thanks, @kuzulis for giving me a reference to look at the device side.

The problem is solved by adding line coding settings to the CDC buffer on the STM. It is related to the hardware. STM users should bind USBD_CDC_LineCodingTypeDef data structure to CDC_Control_FS function.

In ready-made examples, this binding does not exist. Users who do not add this binding can face the same problem in long term tests. Maybe it can help people who face the same problem.

Regards

@canerbldk said in QTSerialPort Read/Write doesn't properly work on Windows:

As I stated before I'm thinking that I'm measuring write-to-buffer time while I need write-to-serial timing.

That is hardly possible, as there are many buffers involved: in your app, in Qt, in the OS, in the driver, ...

What you can do is to time the round trip i.e. send a command and measure the time until the answer comes back.

Regards

I know what it says: It's the information about Qt Creator and the version of Qt used to build it.

That in itself has no incidence on the version of Qt you'll be using for your development. You can develop your application with many different version of Qt be it Qt 4 / Qt 5 / Qt for Android etc.

That information can be found in the preferences under Build and Run where you have the Kits and Qt versions you installed or that was detected.

Without seeing the implementation of these classes I can't tell.

Something's not clear: are you using your distribution's Qt or building Qt yourself ?

Hi and welcome to devnet,

A Tech Preview means that the API could change significantly before it's released as an official module. However in facts, for what I've seen until now, there are rarely big changes between the tech preview and the official release. Mostly adaptation and some API changes but rarely big breaking stuff. However you should follow closely the development of the module to stay up to date and ensure you have the latest fixes in.

You have been very clear, thank you very much:

However, trying to do what you explained, I have failed to complete because,.. including termios.h in my class in order to call ::tcsetattr(ps->handle(), TCSANOW, &tio);
then a lot of variables in my class (called B50, B200) match macro definitions in termios, i.e.
#define B50 0000001
so compiler tells me
sas.h:140: error: expected unqualified-id before numeric constant bool B50;
I think I need to wrap termios.h inside a namespace, but: I dont know if this is correct and if it is, how to do that.

Thank you again

Sorry, I'm not expert in licensing issues and others bureaucracies.

Depending on what you need on your target it will take less time to build if you only take the modules you need.

@Digits
Hi
He has not been online for 2 years so its unlike he return to answer this.
Maybe you can use this
https://github.com/QkThings/qkloader
IT implements XMODEM in a more cpp friendly way using QSerialPort

Hi and welcome to devnet,

starting from Qt 5.1 QSerialPort is officially part of Qt: you don't need to build it anymore.

Exact, QSerialPort doesn't call the USB stack directly. Typically for FTDI devices, you would install the FTDI Virtual Com Port driver and then you have a "classic" com port. AFAIK the ARDUINO uses RS232 so it should act also like a serial device.

I have never tried using QSerialPort outside of the message loop (i.e. 'a.exec()' from main() in your program). I do get the impression that it relies on the message loop to function properly so this test may not work.

If you modify your test program a bit I suspect it will work:

Create a class derived from QWidget Add a 'Test' button with associated slot Put all your test code in the test slot.

In Qt4 you had to use the external QSerialDevice class (this, or some variation of it, was migrated into Qt5 but didn't exist internally as part of Qt4). There was something about the open command mode options that I ran into, I don't remember the details unfortunately. There is a namespace called 'AbstractSerial' with various options, at least in the version I have. You might want to use this instead:

if (serial.open(AbstractSerial::ReadWrite)){ qDebug()<<"Opened successfully"; }