How do I connect via COM port?
I've been struggling to establish a connection from an app to an Arduino board. I'd like to control the Arduino via the app - right now I'm in the connection phase.
My most recent attempt looks something like this:
QSerialPort serial; serial.setPortName("COM4"); const QString name = "COM4"; QSerialPortInfo info; info = QSerialPortInfo(name); serial.setPort(info); serial.setBaudRate(serial.Baud19200); serial.open(QIODevice::ReadWrite);
I moved some stuff around because it's in headers/whatever. I've tried various different versions of this - assuming I know I'm on COM4 (I'm going to make a config file for it later), how can I establish a connection to the Arduino?
@IAIPDS Hi, welcome to the Qt forum! You already did everything that's needed (configure the port and open it). You now have more or less direct access to the read write buffers of the port hardware and that's it. There is nothing like a "connection" except the physical connection you have to establish by connecting the two devices with a cable.
Did u see the
has nice dialog for setting serial port up etc.
very good for testing.
It also shows how to setup the class so that when it
reads some data - your function is called.
connect(serial, &QSerialPort::readyRead, this, &MainWindow::readData);
Often you will not have
QSerialPort serial; in a function
as you want serial to live as long as the application to read data from it.
so normally it should live in the class and not in a function as it will go out of scope and be deleted.
Thank you both for answering.
Well, that's kind of frustrating that I should have a working channel because the third party app I'm trying to get this to work in is throwing an error that it doesn't have an established connection. It might need that readyRead operation or something but I'm not sure why it would be throwing this error...
Also thanks mrjj but I actually do have QSerialPort serial in the header file :) those other lines are tied to a specific button that is meant to establish a link. Honestly once I have one established I should be able to write the rest of the driver in no time flat, but until then... any other thoughts? Is it possible I'm ruining the "connection" somehow?
The third party application speaks some kind of protocol. E.g. it might send a "hello" and wait for a "hi" reply and if your program doesn't reply within a second or so the application will say there's an error. So your first task is to find the specification of that protocol.
That's what I thought, but since I've only been working with manufactured drivers I haven't been seeing if something underlying like that has been happening.
Still, to me it doesn't make sense that this would be the case, because as I'm writing a "driver" for the third party app, I have to return whatever values on my own. Right now I have the connection function returning no error, and I'm setting the app's "connected" option to true. Seems like that should be sufficient, no? Unless I'm screwing up something with Qt, I thought.
Hi and welcome to devnet,
One thing you don't check: if the open call was successful.
Ah, I think I misunderstood how your setup looks like; I thought said third party application was running on the microcontroller board and that you were writing a PC program that tries to communicate with the 3rd party application.
Sort of inverted actually, I'm writing a program for the microcontroller board and writing a driver to interface it with a PC program. The driver I'm using is sort of from a template.
And it's true that I'm not checking to see if it's open, but I'm also fairly confident it's not opening.
I don't have much/any experience with COM ports but is it possible that for some reason the COM port itself is being "blocked"? Like only one program can access the port at a time, essentially?
Hi, I've also struggled with COM ports (connecting a PC to cigarette vending machines :-) and to see what's going on in the COM port, I use PortMon
Run it before starting your Qt app, and it will show everything that happens with your COM port.
(Note: Last time I tested I couldn't get PortMon to run in Windows 10, but Windows 7 works fine.)
Edit: forgot to answer you question: yes, it's true that only one program at the time can use a specific COM port, so you have to check that open() worked. (PortMon uses some low-level tricks to open it anyway, but that's another story.)
I'm taking a look at PortMon now! Thanks.
Although, I do wonder if it will work - since it's a driver for an application and not an application itself, I actually can't even really test my code except via the third party app itself. And at that point, the program is already in DLL form. That said, if PortMon is supposed to show port requests - and assuming there are no setup steps I'm missing - it doesn't appear to be really doing anything. I didn't see anything pop up when trying to execute the connection for my program.
Hi, about PortMon, it doesn't show any popups, to see what's happening, you need to have PortMon's window visible, it will show the events in it, for example if a program opens that COM port, or changes the speed etc.
Edit: also in the Capture menu in PortMon, check in the Ports submenu that your COM port is captured ok, that helps :-)
Hmm.. right now nothing is popping up in the window (that's what I meant by pop up, my mistake) and the window says Portmon - not connected. Is there some step I'm missing?
If it's not connected, perhaps you didn't start PortMon before starting your driver and app; it needs to be launched before your stuff. Also check that Capture submenu (as I said in my prev. post).
Ah, didn't refresh my site to see that edit - well, the Ports submenu is grayed out and I tried closing and reopening the apps in the proper order and still nothing...
Hnmm, perhaps this StackOverflow post can help (look at the answer at the bottom)
That method's throwing a file not found error... haha I can't even work the thing that's supposed to work the thing I can't work
It's called yak shaving :-)
COM ports are indeed finicky to debug. In the old days I used a hardware dongle with LEDs and RS232 male/female connectors as a "hardware" debugger, when the LEDS flashed you'd know something was afoot.
Another alternative is to use ol' HyperTerminal if you have Windows XP somewhere it's included.
Yeah I tried opening Portmon and then just moving the program into my arduino to see if the activity popped up in the feed but nothing happened, though the program loaded successfully (although that was never a problem). I'm also not using XP, unfortunately. Seems that port checking may not be the way to go for this troubleshooting?
Yeah sorry PortMon may well have past its prime. You could try connecting the cable to another PC instead of the Arduino board, and on that other PC run Qt's chat demo program or something similar.
Also another trick I remember, take a paperclip and connect/shortcircuit pins 2 and 3 with each other, easiest on the male RS232-connector. When you connect the Tx and Rx pins that way, it means everything you transmit comes back directly (echo). Sometimes that can be a helpful diagnostic, just to see if anything arrives...