Please let me know if there is any API, system call, function (in Linux) which I can use my C program to detect a COM port dynamically, i.e., whenever a USB modem dongle is inserted in the port I will be able to detect that COM port using the API, or system call, or function in my C program.
Depending on your modem, USB serial port device may show up as /dev/ttyUSBn or /dev/ttyACMn, where n is some number starting from 0.
You can configure udev rule to automatically react on device being inserted or removed.
If you want to do it on your own in C, you need to make use of netlink(7) sockets. If you don't want to fiddle with them, probably easier approach is to simply use utility udevadm provided by udev package (udevadm is using netlink internally), something like that:
udevadm monitor --kernel
If you are going to use it in your C program, simply call it in pipe like this:
stdbuf -o0 udevadm monitor --kernel
and setup select loop, so it can react immediately. Wrapping in stdbuf is necessary to avoid buffering provided by udevadm.
In Linux the serial ports aren't called COMx. They (real serial ports) are generally named /dev/ttySx where x is a number, starting at 0 for COM1, 1 for COM2, etc.
If you want a list, you should look in /dev for ttyS devices.
Here is a very detailed page for serial port programming on Linux:
Serial Programming HOWTO
Serial HOWTO
Finally, note that a quick Google search goes a long way for general questions like this!
Related
I have a Wemos D1 Mini (ESP8266), flashed with WLED and I want to create an application like .exe and have control on turning it on/off and choose colors. Does anyone have any idea how I can do without to connect on wifi and just do everything via USB?
To control the WLED firmware over USB, you would use the firmware's ability to be controlled over a serial connection. It looks like you would open the virtual serial port that appears when you plug in the device, at a speed of 115200, and then you take the same JSON that you would POST to /json/state for controlling it over WiFi, and instead send it over the serial connection, and get your responses back over the serial connection.
You could also implement the TPM2 protocol, or the Adalight protocol (which doesn't really seem to be documented except in code), as those are also supposed to be supported.
If you want to do all this in C++ on Windows, you might start by reading the (very old) Windows tutorials for Win32 API serial port programming. If you only want to target Win10 or newer, you could learn C++/WinRT and then use the new WinRT serial APIs. Or you could consult the answers to this question about serial programming on Windows.
I'm quite new to programming at linux and its file-based communication.
I need to create a virtual modem (or modem emulator) at linux machine. The idea is that the software module that sends commands to hardware modem on an FPGA,
At FPGA:
SoftwareModule <= ttyACM => HardwareModem
What I need to achieve at my computer:
SoftwareModule <=> MyModemEmulator acting like a fake UART
Purpose is that the software module can be tested on a linux machine where I have a fake software modem UART(?) port. So the software module sends the modem commands and my fake modem module catches and responds accordingly. So my module will be actually acting like a hardware modem.
What could be the steps I need to take for that? I'm quite new to working with serial ports and don't have deep knowledge of linux or hardware stuff.
I have come across 'socat' but I'm not sure if that can really serve the purpose.
So far I have only learned how to create a basic file system with FUSE (as it was suggested by someone), but I'm not sure how can I use it for my purpose. I'm not looking for a proprietary solution, and not looking for windows based solution either.
Please guide me to the right directions.
Thank you !
Creating a Fake Serial Port to Emulate Modem
What you refer to as a "serial port" in Linux is actually a serial terminal with many software layers.
Study Linux serial drivers, and the termios man page for salient functions that need to be emulated.
And you have not even considered how to factor in the USB component of the communication path.
At FPGA:
SoftwareModule <= ttyACM => HardwareModem
...
My computer with ubuntu does not have ttyACM
A /dev/ttyACMx device node is only created when a USB serial gadget is connected to the host.
So it's not surprising that you cannot find such a device node.
What I need to achieve at my computer:
SoftwareModule <=> MyModemEmulator acting like a fake UART
You have stated the issue poorly, since you (misguidedly) think that a "fake UART" (integrated with your "MyModemEmulator") is the appropriate solution.
Do not try to emulate both a serial terminal and an external modem on the Ubuntu host, since you are "quite new to programming at linux and serial ports" and the task of accurately emulating a serial terminal is risky and expensive.
What your goal should be is:
SoftwareModule <= ? => MyModemEmulator
and the question is "what is needed in the middle to interface these two units?".
IOW you have posted an XY problem.
There are a plethora of SBCs (single board computer) that have a USB gadget port and can be configured as a USB serial gadget that uses CDC ACM.
Since the actual "hardware modem on an FPGA" will use a USB CDC ACM connection, you should consider using an actual /dev/ttyACMx serial terminal, and emulating just the external device ("hardware modem") with a SBC.
In other words, instead of trying to achieve:
SoftwareModule <=> MyModemEmulator + fake USB serial terminal
it should be much easier to use existing interfaces and implement:
SoftwareModule <= USB => emulated HardwareModem
with a SBC running your Linux application for modem emulation using /dev/ttyGS0 (a USB serial terminal on the gadget end).
By using an actual USB CDC ACM connection and not implementing the "fake USB serial terminal", this approach eliminates an entire layer of SW+HW emulation and its possible false test results.
Addendum
If the use and/or cost of embedded Linux on a SBC concerns you, then there is an alternative scheme to emulate the "hardware modem" on your Ubuntu PC host instead of the SBC using a USB-to-RS232-to-USB connection.
Acquire a pair (i.e. quantity 2) of USB-to-RS232 adapters and a (very short) null-modem cable.
Connect the DB-9 ends of the adapters to the null-modem cable to make a single cable with both ends having a USB male type-A connector.
Plug one adapter into the PC to create the /dev/ttyUSB0 device node. Treat this as the equivalent to /dev/ttyACM0 for your SoftwareModule.
Plug the other adapter into the PC to create the /dev/ttyUSB1 device node. Treat this as the equivalent to /dev/ttyGS0 for your emulated "hardware modem".
Develop, execute, and debug your emulated "hardware modem" on the Ubuntu PC host (without the unnecessary task of "creating a fake serial port").
The situation is as follows: I have a piece of hardware connected to a, windows running, PC via a serial port. This custom hardware is used to interface other hardware through GPIB. Now, the software that is used to operate this setup on the PC side needs to be changed without touching the hardware in the middle. The problem is getting a hold of the proper serial comm. parameters used for communication - setting them (the timeouts in particular - baud rates and bits are fine) to arbitrary values in the new software leads to a lot of comm errors so I'd like to know them precisely. The function GetCommTimeouts() would do the job, however you need the handle to the comm. device aquired via call to CreateFile() - only the original software has access to it. So the question is if one can get a hold of these settings from outside of the running, old app?
Thanks,
drinker
I would suggest using a tool like Process Monitor. This tool can monitor the calls that are used to open and configure a serial port.
My development target is a Linux computer that has two physical serial ports located at /dev/ttyS0 and /dev/ttyS1. I also expect /dev/ttyS2 and /dev/ttyS3 to be defined.
Using stty -f /dev/ttyS0 and S1 reports the configuration of the two serial ports and reports something menaing "doesn't exist" for S2 and S3.
The hardware designers are talking about offering USB to Serial ports built onto the main board. They'll be DB9 connectors on the outside and just circuitry - no USB connectors on the inside. The number of USB-to-serial connections is not guaranteed and I know enough to design for "many" instead of one.
So, in setting up my port server daemon, I need to be able to determine which ttyS's and which ttyUSB's are "real" and which aren't. Will there ever be placeholdeer ttyUSB's? What if one were to be "unplugged" (say it was, indeed, a real USB coupler on the inside of the PC)?
Is there a better approach than popen()ing stty and examining its output to determine the status of the serial ports? Is there a C API for stty?
Thanks!
The "C-API" which stty uses is tcsetattr(3) and tcgetattr(3).
For finding TTYs without opening the device you may look at this question:
How to find all serial devices (ttyS, ttyUSB, ..) on Linux without opening them?
I have a code to send data to serial port. I just want to make sure that it is sending the data properly. I checked the function's return value and the number of bytes written and it is success. Is there any other way to actually see the data whatever i am writing?
if(WriteFile(m_hSerialComm, pszBuf, dwSize, &dwNumberOfBytesWritten, NULL) != 0)
I tried to use "Advanced Terminal Port software"
but the data is not coming in that window.
There are several ways to test your software. If you have two serial ports then connect them with a cable and listen on the other port with a terminal application such as the one you mentioned. Otherwise, you could loop back on the same port by connecting pins 2 and 3 together. A hardware-free option would be to use virtual serial ports as provided by tools like com0com.
Assuming from your piece of code that you are developing on a Microsoft Windows operating system, I would recommend the Portmon for Windows "official" serial port monitoring utility. I have used it in in the past, and found it simple enough, and also quite useful specifically for its multiple filtering/search options (since sometimes the amount of data passed on your serial port is huge).
If all you want is a log of the data you have written to your own port, why not encapsulate your WriteFile (and maybe also your ReadFile) functions in some "utility" function(s) that reads/writes both on your serial port and in some log file? You could even add timestamps, and filter "whatever you are looking for" straight from your own code.
I found this last option really useful when remotely debugging applications with customers. You add a button in your application that toggles the logging on and off, then you simply have to ask your customer to hit the "log" button and to send you the results.