I have an Arduino-based device which connects through USB.
I'd like to detect it from my Qt 4 application, using QExtSerialPort (or whatever necessary), when it's plugged in.
If this weren't possible, I thought I could somehow get a list of the system's port names and just try all of them in search for my Arduino (where I'd implement some kind of handshaking procedure for it to detect it correctly). My concern in this approach is that I'm not sure if a device (for example, printer) would get damaged if I send some kind of handshaking ack at a different baud rate.
So, I don't really know where to start for any of them. Which would be the best approach? How would I implement it?
I believe you can find list of serial ports on Windows by looking into
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM
registry key
Each serial port on a UNIX system has one or more device files (files in the /dev directory) associated with it:
System Port 1 Port 2
IRIX® /dev/ttyf1 /dev/ttyf2
HP-UX /dev/tty1p0 /dev/tty2p0
Solaris®/SunOS® /dev/ttya /dev/ttyb
Linux® /dev/ttyS0 /dev/ttyS1
Digital UNIX® /dev/tty01 /dev/tty02
more details on serial programing on POSIX systems here
Since your device is USB, your UART port will be emulated by some kind of conversor in his hardware. So first you must understand what driver is being used on your system.
The most common SERIAL->USB conversor uses PL2303/PL2301 chip, so it would create a path on /dev, if its the first device, it will appear as "/dev/ttyUSB0", but you may also see the list reading the proc path (like "cat /proc/bus/usb/devices").
Under Windows it usually creates a virtual "COM", just go to device manager and check the port.
When you are sure about how the HW talks to your system, you may use QExtSerialPort for wrapping the system API and talk to the device.
Way too hard and too platform specific, using weird Windows Registry keys or rely on hard wired device nodes on Linux.
You are on the right way. Get QextSerialPort or QSerialDevice (which I preffer in my projects, because it got integrated in Qt5), have a look at the examples and simply use it. In both libraries you get some kind of port enumerator class which returns you a list of all configures serial ports. Only platform/device specific settings you will have to do manually (like getting RS485 in half-duplex mode on my current embedded project), but "standard" problems are perfectly encapsulated in a QIODevice implementation.
You can use both QextSerialPort and QSerialDevice like a file. Open it (instead of a filename you specify the device name ie. "COM1" on Windows or "/dev/tty0" on Linux, depending on your configuration) and then read or write like you are doing it with an ordinary QFile, QBuffer, Qwhatever-inherits-from-QIODevice.
If you have any problems opening the port and communicating, don't hesitate to ask! :)
Related
I seem to only be able to access physical ports. I do want to access virtual ones like ones created with virtual null modem or virtual serial port driver.
Does anyone know if this is possible.
Chrome enumerates serial ports by calling SetupDiGetClassDevs with GUID_DEVINTERFACE_SERENUM_BUS_ENUMERATOR. As I discovered when implementing this enumeration logic there are a surprisingly large number of ways to ask Windows for a list of all available COM ports. The advantage of this approach being that it provides device information which can be used to get the human-readable name of the device and USB product identifiers if it is a USB device. It is likely that a virtual COM port driver may be creating the device in a way which prevents it from being discovered this way.
I've created https://bugs.chromium.org/p/chromium/issues/detail?id=1238369 to track this as a Chrome bug. Please comment on whether you are using a different virtual serial port driver than the one mentioned there.
I managed to get Chrome to see the virtual serial ports using com0com on Windows 10 21H1 (OS Build 19043.1110). Chrome connects to the port successfully and it works as expected:
I have the following: STM32F407G-DISC1. My goal is to communicate (sending strings back and forth) between my pc and the mcu over serial and I currently am able to do so using the micro-usb (otg) port, while powering separately using the mini-usb st-link port (so using two cables).
Is it possible to use the mini-usb port for serial communications? (eliminating one of the cables)
I have read the user manual and my interpretation is that this is not possible without physical modifications. But I am a beginner and would like to verify I am correct in this interpretation. I have researched thoroughly however most sources seem to not refer to this specific board and it is my understanding with the newer version of st-link it uses this should be achievable.
It is possible - just send the messages via the USART2
You need to solder those two wires as they screw up the design.
I am controlling a device over serial connection using LabVIEW (version 7.0). It is connected using USB, and is installed as a virtual serial port on the computer (running Windows XP). Every now and then my device crashes when my program sends a command, and it is unable to accept any more input (the device itself also stops working) until it has timed out.
I've looked at the serial port traffic using Portmon. Whenever the device crashes the serial driver sends the command I send using my program four times instead of just once, with an IOCTL_SERIAL_GET_COMMSTATUS command in between. I cannot see what this last command returns, but I assume something happens in the communication earlier on. I'm thinking my configuration of the port is not entirely right, but I have no idea how or why. I open and close the connection to my device every time I want to write something to it.
For completeness' sake: it has a baud rate of 9600, 8 bits, no parity, 1 stop bit, and no flow control. I'm aware that the correct settings of these parameters depend on the device, but the manufacturer has not supplied any recommended settings.
The driver is a DLL of some sort? If so, this is the most likely source of your problem, and you likely will need to contact the author of the driver. LabVIEW does have crashing bugs, but by far the most common source of crashes in simple communications apps is a buggy third-party DLL.
In other words, I doubt this is a LabVIEW problem at all and that you would have the same difficulty if you wrote a C program to talk to this driver. I only know what you've posted here about your system, but after many years of chasing down such issues, I would start with the device manufacturer/driver author.
If you have evidence to the contrary, please share.
There's a old piece of software we run in our company that manages RFID cards tapping in/out to open doors.
We want to create an app who identifies who just touched in on a specific place (we have the id for that) and grab their 1st name, to say "Hi [NAME]" on a screen.
As I mentioned, the software is quite old and there are no APIs. It communicates with the RFID hardware via a serial port (COM1).
I was wondering if the best way to get the data I need is to somehow intercept the COM1 traffic and extract/look for the data I want.
Does this sound like the best way to go about it? Would it work, or would it be impossible to get names and numbers from the data being transferred?
Cheers,
Andre
Can you configure the software to use a port other than COM1, or configure the hardware so it's physical serial port is assigned to a different COM port?
If so, take a look at com0com. It's a Windows driver that creates two COM ports on your PC with a virtual NULL modem between them. Data going in on one side comes out on the other.
Here's how you'll set things up:
RFID Reader connected to physical COM port (COMx)
your program bridging COMx to COMy and sniffing the traffic
com0com linking COMy (for your program) to virtual COM1 (for the legacy software)
legacy software
You'll need to write a program to pass data between COMx and COMy while monitoring it for the information you're looking for. Make it simple yet robust, since if it goes down you're reader will stop working.
A Simpler Solution
If you only need to monitor one side of the communications, create a cable that connects the GND and RX pin of COM1 to another COM port. Now your program can monitor that side of the conversation, without interfering with the legacy software.
Well, generally, you can look at RS232 signals, if that's the way you want to do it. It's tricky because you need to "sniff" the signals, which means buying or making a rig that allows the original signals to go through, and then gives you a way to attach to them as well. And, you need to send the transmit and the receive signals to TWO serial ports (on the RX lines). Then you'll probably want to get some "sniffing" software that allows you to look at what you're getting in time sequence (ideally, with time-stamps). Some cutesy protocols also will use modem lines, so you may need to monitor those as well.
Or, try searching for "free serial port monitor" or "serial sniffer".
Good luck!
I remember years ago my friend and i were playing command and conquer red alert and there was a mode were we put the others phone number and the game would dial up and connect. What was this called? and where can i find resource to program for this?
Dial-up Networking perhaps. You will have to learn how to control the modem. I remember there were some commands that looked like this: ATH0++ which was how you could make the modem do different things. Perhaps that will give you something to search for.
This resource looks kind of helpful: http://www.activexperts.com/activcomport/tutorials/modem/
One issue you might find is that there are two types of modems generally. One is an actual modem which is connected to your serial port. The other is what is typically known as a "winmodem" which is usually in a PCI slot and didn't have all of the functionality on the hardware but instead used the hardware drivers which typically only worked in Windows. MODEM stands for "MOdulator DEModulator" which means it just converts a digital signal to analog and vice versa.
In essence, it seems that if you can figure out how to program to the serial/com ports on your computer, you should be able to access the modem.
Another interesting link: http://en.wikibooks.org/wiki/Serial_Programming:Modems_and_AT_Commands
Have a look at TAPI (Telephony API). In Windows world there is a set of APIs in the OS for this (http://msdn.microsoft.com/en-us/library/ms737219(VS.85).aspx). The AT command set (Hayes commands) can also be used without TAPI in Windows if you treat your Modem as a COM port and send AT commands to that COM port (that's what actually TAPI does) but it isolates you from their different variants and also running initialization and other commands in a particular order.