I am developing an embedded solution using C and I am working with two USB sensors. If I connect each sensor alone they take this names:
Device 1 (I do not know why it takes 6 names...)
/dev/ttyACM0
/dev/ttyACM1
/dev/ttyACM2
/dev/ttyACM3
/dev/ttyACM4
/dev/ttyACM5
/dev/ttyACM6
Device 2
/dev/ttyACM0
So when I start as an embedded system and both sensors are connected, the fastest one takes /dev/ACM0 but it not always the same. So, when I try to read device 2 I could be reading device 1...
I think that It would be great to change the default names of the sensors. I guess that it is going to be possible but I do not find anything.
You should try using the names in /dev/serial/by-id instead, since those names include the name of the device and should not depend on the order of connection.
By the way, it is also possible to write udev rules that make symbolic links for the serial ports depending on what device they belong to. I am not sure how that would work for a composite device with 6 serial ports, but there probably is a way to make it work.
Related
I'm trying to identify USB keyboards by the physical port it's connected to, including which USB hub.
From experiments I've identified the following:
/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4.2/1-1.2.4.2:1.0/0003:0461:0010.0024/input/input49/event4
The first part, /devices/platform/soc/3f980000.usb/usb1/ appears to be constant given a system.
I guess it might be different on another system.
The last part, /input/input49/event4 appears to be increasing every insertion.
Each part starting with /1-1 appears to represent one hub in the USB chain, every later one starting with the full path of the previous one.
The last part in the /1-1 chain contains : which identifies sub components inside that USB device.
However only the second number in :1.0 appears to correlate with interface number, the first one is always 1 and I'm not sure how it could change or what that would mean.
My guess would be to identify the last part not containing : and use that as the physical USB path.
0003 looks like it could be USB class: HID
0461:0010 looks like VID:PID
0024 Increases by every insertion
Are my assumption correct?
Is there a reliable way to identify location in the USB Port tree from either UDev path other means?
has linux reserved io port numbers for all manufactured devices.
I have devices like intel built-in network card. or another device I have for wifi (usb) from realtek.
On linux repository on github, device drivers use specific io ports to register. And kernel assign those ports to device driver. device drivers normally request for ports using call to request_region function. so for some ethernet device it requests like following
for (id_port = 0x110 ; id_port < 0x200; id_port += 0x10)
{
if (!request_region(id_port, 1, "3c509-control"))
continue;
outb(0x00, id_port);
outb(0xff, id_port);
if (inb(id_port) & 0x01)
break;
else
release_region(id_port, 1);
}
above starts with 0x110 to 0x200, any port can be assigned in this range by kernel to driver and appear in /proc/ioports file means driver is using that io port by the time of success return from request_region.
Question : So my question is has linux assigned io ports to all manufactured devices usable with kernel 5.7 or latest kernel version?
Question : What if I want to write device driver for any device. How can I find the io ports number range to request to. I dont not expect that I have to look into kernel code and find similer driver port range. so How can I find that io port number range. how to achieve this first step required in writing device driver (any device. be it wifi internet device or ethernet device)
Question : So my question is has linux assigned io ports to all manufactured devices usable with kernel 5.7 or latest kernel version?
No.
Question : What if I want to write device driver for any device. How can I find the io ports number range to request to.
You ask the user for it. After all it's the user who set them using jumpers on the ISA card.
Here's a picture of an old Sound Blaster card (taken from Wikipedia, I'm too lazy to rummage around in my basement now). I've highlighted a specific area in the picture:
That jumper header I highlighted: That's the port configuration jumper. As a user you literally connect two of the pins with a jumper connector and that connects a specific address line that comes from the card connectors to the circuitry on the rest of the card. This address line is part of the AT bus port I/O scheme. The user sets this jumper, writes down the number and then tells the driver, which number it was set to. That's how AT style I/O ports.
Or the driver uses one of the well known port numbers for specific hardware (like network controllers) that dates back to the era, where ISA style ports were still are thing. Also there's old ISA-P'n'P where the BIOS and the add-in cards would negotiate the port assignments at power up, before the OS even started. You can read those port numbers with the ISA-P'n'P API provided by the kernel.
We no longer use this kind of hardware in practice! Except for legacy and retro computing purposes.
Over a quarter of century ago, the old AT / ISA bus was superseeded with PCI. Today we use PCIe which, from the point of view of software still looks like PCI. One of the important things about PCI was, that it completely dropped the whole concept of ports.
With ISA what you had were 8 data lines and 16 address lines, plus two read/write enable lines, one for memory mapped I/O and one for port I/O. You can find the details here https://archive.is/3jjZj. But what happens when you're reading from say, port 0x0104, it would physically set the bit pattern of 0x0104 to the address lines on the ISA bus, pull low the read enable line, and then read the voltage level on the data lines. And all of that is implemented as an actual set of instructions of the x86: https://c9x.me/x86/html/file_module_x86_id_139.html
Now look at the PCI bus: There's no longer separate data and address lines. Instead read/write commands would be sent, and everything happens through memory mappings. PCI devices have something called a BAR: a Base Address Register. This is configured by the PCI root complex and assigns the hardware the region of actual physical bus addresses where it appears. The OS has to get those BAR information from the PCI root complex. The driver uses the PCI IDs to have the hardware discovered and the BAR information told to it. It can then do memory reads/writes to talk to the hardware. No I/O ports involved. And that is just the lowest level. USB and Ethernet happen a lot further up. USB is quite abstract, as is Ethernet.
Your other question Looking for driver developer datasheet of Intel(R) Core(TM) i5-2450M CPU # 2.50GHz suggests, that you have some serious misconceptions of what is actually going on. You were asking about USB devices, and Ethernet ports. Neither of those in any way directly interact with this part of the computer.
Your question per se is interesting. But we're also running into a massive XYZ problem here; it's worse than an XY problem; you're asking about X, although you want to solve Y. But Y isn't even the problem you're dealing with in the first place.
You're obviously smart, and curious, and I applaud that. But I have to tell you, that you've to backtrack quite a bit, to clear up some of the misconceptions you have.
I have two usb to serial cables collected to a null modem and then the two usb connections connected two seperate usb ports on my linux machine
I want to write a program that allows them to communicate back and forth through a terminal, and wanted to test the two ports using screen
I type screen ttyUSB0 115200 but it just comes up with a blank terminal with no text, i realize i am supposed to use commands but I cant find a guide anywhere on how to use this to test to make sure the serial ports are sending/receiving data among other things, could someone point me in the right direction?
I have two usb to serial cables ...
Those are not just "cables", but rather adapters.
Besides the copper wire, there is an IC with a microprocessor, RAM, and ROM inside that dongle. Your PC will recognize each USB-to-serial adapter as a (USB-based) serial port.
IOW you have two serial ports.
Therefore you need two (not just one) instances of a terminal emulator program (e.g. screen), one for each serial port.
Unless you have both terminals perfectly configured, you may have confusing issues such as no echo (what you type shows up in the other terminal, but is not displayed in the terminal where you're typing), and the Enter key only responds as a new line with vertical movement of the cursor and no horizontal movement.
I want to write a program that allows them to communicate back and forth ...
That's possible so long as you open() both serial terminal devices.
So, the question is, is the content of /dev/serial/by-id unique?
Essentially the issue is I want to connect several (two or more) arduinos (potentially of different types, but they may all end up being leonardos) to the Raspberry Pi for the purposes of an automation system.
I'll be using the serial interfaces to communicate between the Raspberry Pi in Python and the Arduinos. I've run this on one of the leonardos (at present I only have one):
udevadm info -a -n /dev/ttyACM0| grep serial
0000:00:1d.0
Is this a unique serial for my serial connection to the Pi? Can I rely on this to create a UDEV rule to assign a particular mount point, or does a unique and reliable mount point get already created in /dev/serial/by-id/, which I can use instead of hacked-udev rules?
It's NOT ALWAYS unique. In my experience, if you bought a cheap arduino clone from China, they mostly didn't bother to generate unique ID for every devices. The same applies for every devices. If the manufacturer didn't bother, then the devices will be identical. I ended up just using the by-path and symlink it.
In my experience using /dev/serial/by-id with USB devices has been unique. That is true as long as the manufacturer follows "the rules" about giving each device a unique serial number.
I just make symlinks to those long names in /dev/serial/by-id and use my symlinks as the handles for my serial devices in scripts. No muss, no fuss, NO UDEV.
The rules for the naming are in
/lib/udev/rules.d/60-persistent-serial.rules
I have a telephony modem which gives voice to my interfaced application via a serial USB ttyUSB0 in 16bit PCM 8000hz. I am able to capture this data and play with audacity. I want this port to be detected as a sound device in linux (I am on ubuntu). Is it possible? Are there any other options?
I'm guessing you are using a huawei 3G modem or something similar which gives ttyUSB1 for audio. Make sure you have the serial driver binded to it. Then simply pass the port itself as a "file" for input for any program of your choice.You need root access for that.You figured out the audio settings so it must be enough.I have voice calling working in UBUNTU 11.10 with Huawei. So let me know if i can help any further.
Ok, I see it's very old question but answers helped me to get a right direction so I decided to help others.
The one way to achieve (in addition to below) what are you are
looking for is to write dynamic kernel module.
Have it register as a sound device, and check that it has a GSM
module present (which module is it exactly can be recognized in
dmesg, lsmod, or output).
Then establish communication between user space representation as a
sound card and serial usb module.
The other way is to get module that you recognized by dmesg, lsmod and extend its functionality as a sound card.
All are tricky tasks because:
in the first case you have to resolve intermodule communication at the kernel level...... which is, lets say, a little hard even if programmer has a right background in subject.
the second case is hard in that you have to deal with:
USB stack (which is little unpleasant for human beings) and
sound subsystem (which is a little burdensome because of historical issues).
Without being an experienced kernel programmer there are small chances to succeed.