Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I am confused about the these 3 concepts.
My understanding is, Serial Port usually means RS-232 compatible port (RS = Recommended Standard). USB stands for Universal Serial Bus. So its name contains serial port, does it support RS-232? What does the Universal mean?
And what does COM port mean?
ADD 1
Some understanding from Hans' answer:
To reduce effort, device manufacturers usually make their device can behave like a serial port device as well. This relies on the the fact that many OS and language libraries have already included serial port communication support. Though such support is no comparable to a real matching device driver.
ADD 2
A good reference doc about Serial Port HOW-TO.
And btw, the Linux Document Project is really useful.
Serial port is a type of device that uses an UART chip, a Universal Asynchronous Receiver Transmitter. One of the two basic ways to interface a computer in the olden days, parallel ports were the other way. Serial is simple to hook up, it doesn't need a lot of wires. Parallel was useful if you wanted to go fast, typ 8 times faster than serial, but cables and connectors were expensive. Parallel I/O has completely disappeared from computer designs, caught up by tremendous advances in bus transceivers, the kind of chip that can transmit an electrical signal down a wire.
COM comes from MS-Dos, it is a device name. Short for "COMmunication port". Computers in the 1980's usually had two serial ports, labeled COM1 and COM2 on the back of the machine. This name was carried forward into Windows, most any driver that simulates a serial port will create a device with "COM" in its name. LPT was the device name for parallel ports, short for "Line PrinTer".
RS-232 was an electrical signaling standard for serial ports. It is the simplest one with very low demands on the device, supporting just a point-to-point connection. RS-422 and RS-485 were not uncommon, using a twisted pair for each signal, providing much higher noise immunity and allowing multiple devices connected to each other.
USB means Universal Serial Bus. Empowered by the ability to integrate a micro-processor into devices that's a few millimeters in size and costs a few dimes. It replaced legacy devices in the latter 1990s. It is Universal because it can support many different kinds of devices, from coffee-pot warmers to disk drives to wifi adapters to audio playback. It is Serial, it only requires 4 wires. And it is a Bus, you can plug a USB device into an arbitrary port. It competed with FireWire, a very similar approach and championed by Apple, but won by a land-slide.
The only reason that serial ports are still relevant in on Windows these days is because a USB device requires a custom device driver. Device manufacturers do not like writing and supporting drivers, they often take a shortcut in their driver that makes it emulate a legacy serial port device. So programmers can use the legacy support for serial ports built into the operating system and about any language runtime library. Rather imperfect support btw, these emulators never support plug-and-play well. Discovering the specific serial port to open is very difficult. And these drivers often misbehave in impossible to diagnose ways when you jerk a USB device while your program is using it.
USB stand for Universal Serial Bus not Port. The term "serial port" simply means that the data is transferred one bit at a time over a single signal path - in that sense even Ethernet is serial in nature. The word serial in both terms implies no relationship other than the width of the data path.
You are right in that the term serial-port in the context of a PC normally means an RS-232 port, but there are other serial port standards such as RS-422 and RS-485 often used in industrial applications. What these have in common is that they are implemented using a UART (Universal Asynchronous Receiver/Transmitter).
The term Universal in USB merely reflects the fact that it is not a specific device interface such as the dedicated mouse or keyboard ports found on older hardware. Similarly a UART based serial port is not device specific, reflected by the U in UART.
USB differs significantly from RS-232 in a number of ways; it is a master/slave (or host/device in USB terminology), rather than peer-to-peer, the USB device cannot initiate communication, it must be polled by the host. USB includes a low-voltage power supply to allow devices with moderate power requirements to be powered by the bus - that is also why USB ports can be used for charging battery powered devices. USB is significantly more complex that RS-232 which defines only the physical (hardware) layer whereas USB requires a complete software protocol stack.
The term COM is just a device name prefix used in Windows (and previously MS-DOS) for a serial (UART) port. Short for "communications", you can for example open a COM port as a stream I/O device with say FILE* port = fopen( "COM1", "wr" ) ;.
Related
atmega 32 has only one (TX/RX) .In case of connecting many devices working with UART what should I do?....Arduino has something called software serial
Is it available in atmega 32 or how to establish it?
One may also use a multiplexer if the peripheral devices do not need to operate at the same time. This is a bit trickier to use due to baud rate changes and such but I have used this approach in one of my projects where I had a serial printer and some other devices which interfaced with the MCU via UART. The drivers for the said devices included calls to switch to the correct output on the multiplexer before communicating with the device.
I have a data buffer of data on my Serial port. This communication is developed in order to transfer the "maximum" value of possible data. Hence, the value of samples "send" if there is no connection with a computer is around ~11500 data/sec. If I attach the controller (who send the data) on a Windows 10 machine and I try to read (with java) the data, the information frequency drops down to ~ 950/1000 data/sec. Otherwise, if I attach the controller to the same machine, with the same software, but under Ubuntu, it reaches ~6000/7000 data/sec. So, there is a way to improve the Serial port under Windows?
If you are using a cheap USB-serial port, it is possible it only works at USB1 speeds, and/or the driver is basically a rebadged device driver demo from the Windows SDK (which is very poor). More expensive USB ports generally have their own drivers which are much better at higher data rates.
It is also possible that there is some sort of hardware flow control that isn't quite as efficient on Windows as it is on Linux.
Without knowing exactly which USB port you have, it's difficult to make suggestions.
I have an usb device (pole display), which i don't have driver for.
I installed generic usb driver and opened the port for sending(I use bulk transfer) data to device.
With usb monitoring software i see my data gets to device, but nothing much happens on device side.
The device commands(ESC/POS) work when transfered over (virtual) com port, but not over usb port.
Shouldn't device process commands the same way regardless connection type (com vs usb)?
How can i figure out what commands work with the device (for example, if i send some text, i want it to show on display)?
Any help is appreciated!
Look at the USB descriptors the device reports in order to determine its class. If it is a custom device and not a standard class then you'll likely not be able to work with it. There is a big difference between old RS-232 COM protocol and USB. USB devices can have multiple configurations and endpoints, each responding to data in different ways. Many classes exist and are pretty standard (CDC-ACM is typically used for virtual serial ports.) However, it's not uncommon for device manufacturers to include OEM specific configurations and endpoints which can be used for their own custom interfaces, firmware loading, etc.
Is there any initialization data transmitted through the COM port when connecting the device? The device surely can treat COM and USB different, but another possible thing that goes wrong is that the device needs to hear some sort of "I'm going to start sending commands"-signal from you first, and that signal may be different between COM and USB.
So what I would recommend is first (if you have not done that yet) see what data is sent to initialize the COM connection, and if that doesn't have an obvious USB counterpart, connect it to a PC where you do have drivers (assuming that is available somewhere and somehow, which is possible if e.g. you ask this due to OS incompatibility) and see how the connection is initialized there.
If the first doesn't work and the second is unavailable to you, then I'm afraid there's little I can do to help you, since it's usually not visible for you what commands the device wants to hear other than by guesswork, documentation, or comparing to similar devices where you do have that data available.
I have a Arduino app that needs to talk to my PC across the USB (Serial) connection. I have this bit of code that I lifted from the Arduino Playground at
http://arduino.cc/playground/Interfacing/CPPWindows#VisualStudio2008
this->serialPort1->PortName = "COM5"; // Replace with your COM port!
this->serialPort1->Open();
this->serialPort1->Write( "7" ); // In the future, you'll expand on this
// to write your custom data to the board
this->serialPort1->Close();
My question is how does one determine what COM port the Arduino USB cable is attached to?
There are several ways you can approach this.
The most obvious is that you simply make your application configurable and tell it which serial port to use. The port name should never change, unless you have other processes on your machine allocating virtual COM ports such as Bluetooth drivers.
A second option is that you can do what the Arduino app does and scan the serial ports on the system looking for the hardware. Since you are using the CLR, System.IO.Ports.SerialPort.GetPortNames() will give you a list of all the serial ports on the system. (You can also get this from the registry.) Then you can enumerate through them and check the status of the pins to see which serial ports have devices attached. You should probably include in your sketch a way to query the Arduino so that you can send it a command and have it give a fixed response. This would allow you to discern your application from other serial devices such as modems.
There is a third option which would involve figuring out where the FTDI driver stores its configuration information in the system/registry and going from there. This is a bit more involved, so I can't give any information on if this approach is even viable.
I'm looking for a very specific USB device for debugging systems that may use USB but not with a regular computer (proprietary hardware). I want a device that has a USB host controller and two USB device connections. The device to be debugged is connected to the USB host controller and one of the device connections is connected to another device with it's own host controller on it. The the other device connection is connected to a pc. The point being that all USB data travelling through the device (from the device connected to the host controller to the device connected to the first device connection) is reported to the pc.
I'll happily write software to do the logging (in fact I want to) but I can't seem to find a board like this anywhere. Can anyone help?
I have an Ellisys USB analyser, which isn't exactly what you describe internally, but does sit between a peripheral and a host and use a separate PC to collect the data.
(i.e. it has two 'B' and one 'A' connectors on it.)
Excellent product, and very helpful company.
Sniffing the USB shouldn't be too hard if you have the right hardware. And that is the tricky question. I haven't seen anything that describes the USB breakout box that you want. However I can say that this is in the realm of the following two magazines:
Nuts and Volts
Circuit Cellar
If they don't have a USB breakout box project in their archives, then at least they will have advertisements for small cheap single board computers that would have multiple USB ports that you can use for buffering the signals and reporting it back to your PC.
Alternatively is it possible to just wire your PC up to the middle of your two devices and write a custom drive that echos data back and forth while sniffing off a stream for you?
Sorry for the long delay in my reply -- I checked out one of our USB developer's toolchain, and he uses a Beagle USB Sniffer. He seems happy with it.
You're looking for a USB device with two upstream outputs. I think according to the USB spec, this is not possible. You will have two USB hosts trying to send messages and control the USB devices at the same time.
What if you were to look for a device which allowed you to view the data going through a hub via something other than a usb output?
If you're building something custom, take a look at this USB chip site. The chips are programmable via a windows application. Once you define how you want it to operate, it's saved on an EPROM on the dev board ($30-$50).
Sorry if this isn't helpful!