I have a device that's connected to a PC via COM-port in WinForms.
Do I get Signal always when device switches on?
Does device send information to COM port, or must I send a command to device for it to begin transmission of data?
What are the common principles?
What are the common principles?
This is extremely broad. You'd have to read the RS232 spec, or whichever serial spec the device adheres to (which could even be RS485). For the remainder of your questions, let's assume it's RS232, which is the most common by far. Wikipedia has some good information once you get to the part that you actually care about; see the "Data and control signals" section. The article refers to the PC/host/Data Terminal as the DTE, and the device as the DCE.
Do I get Signal always when device switches on?
Some devices will inform you that they are ready by holding DSR high. The host may be expected to set DTR high before the device will do anything.
From http://www.tldp.org/HOWTO/Serial-HOWTO-19.html#ss19.2:
Only 3 of the 9 pins have a fixed assignment: transmit, receive and
signal ground. This is fixed by the hardware and you can't change it.
But the other signal lines are controlled by software and may do (and
mean) almost anything at all. However they can only be in one of two
states: asserted (+12 volts) or negated (-12 volts). Asserted is "on"
and negated is "off". For example, Linux software may command that DTR
be negated and the hardware only carries out this command and puts -12
volts on the DTR pin. A modem (or other device) that receives this DTR
signal may do various things. If a modem has been configured a certain
way it will hang up the telephone line when DTR is negated. In other
cases it may ignore this signal or do something else when DTR is
negated (turned off).
Does device send information to COM port, or must I send a command
Depends on the device. Some devices are silent until data is requested. Some send data to the host as soon as power is applied. Devices should include documentation about what pins they use, and what expected follows should be. I've seen device documentation that provides flowcharts with regard to pins going high.
Related
I am currently working on a project involving a Serial COM from PC ( USB TO SERIAL application coded in C# ) to an embedded platform (STM32F4).
I saw that in some cases it's mandatory to have a checksum in a communication frame.
The Communication configuration:
Baud-rate = 115200,
No Parity bit,
One StopBit,
No Handshake,
Frame Length : 16 bytes
Is it worth adding a checksum in my application? What are the reasons why i should (not) have this checksum?
Thank you for your answer.
Yes you must have a checksum. The only acceptable non-hobbyist solution is a proper checksum based on CRC. Most common industry standard is "CRC-16-CCITT" (polynomal 0x1021). This will catch any single-bit error, most double-bit errors and some burst errors.
Even though you'll only use RS-232 in an office environment(?), any EMI caused by crappy consumer electronics could cause glitches and incorrect data. There is a lot of such crappy electronics around: for example it is not all that uncommon for the electronics in your PC to have poor EMC performance. In particular, there are countless of USB-to-serial adapters with downright awful quality.
The UART hardware in itself has no error detection worth mentioning: it is ancient 1960s technology. On the hardware level, it only checks data integrity based on start and stop bits, and will miss out any errors in between. (Parity checking is equally poor).
Alternatively, you could perhaps get an USB to RS-485 adapter instead and use RS-485, which is far more rugged as it has differential signals. But that requires that you have RS-485 transceivers on the target side too.
It is customary to have a checksum in order to verify the correctness of the data although serial communication is relatively reliable. You will definitely need a sync made up of at least two bytes that will always be assigned a specific value which you don't expect to appear in your data. The sync is used in the receiving side to find the start of each message sent because it is a stream communication and not a packet based communication.
I'm looking for a way to detect when COM device is plugged into PC. I'm not limited to .NET but final application is written in .NET.
Best option would be to connect to some event, if exists.
But in reality I can even list all devices in a loop.
Checking for new devices in a loop is acceptable as a delay of few seconds is not a real problem and application does it only one in a whole lifetime.
I can read this question 2 different ways:
1. How to I detect when a USB->Serial adapter has been inserted.
In this case you could do SerialPort.GetPortNames in a loop and see when that changes
2. How do I detect when I'm connected to a device through my serial port.
There is no surefire way to be able to determine when something is connected to the com port without sending data. There are some additional pins that are meant to be used in this way, but it really depends on the cabling involved. See this post for more details on the types of cables, benefits, and drawbacks.
If you can guarantee the pinout of the cable and that the device you're connecting sets DTR high, then this may be a viable approach.
If not, then you may have to poll each com port and send some data and see if you get any response.
I haven't found any very good resources in my search for answers to this question. At present I am using a TI CC2540 HCI over COM Port. I would like to move away from this solution for cost reasons. Commercial bluetooth low energy USB dongles can be had for very cheap. Let's use a CSR8510-based device for example.
I would like to implement the host and application with the CSR8510 dongle acting as the 'controller'. It does not use a serial port for HCI transport. How can I send/receive commands from this controller? CSR Support is not interested in discussing this because my quantities are too low (~10k)
I would like to specify certain low level options such as connection parameters, scan modes (limited discovery, general, etc.) so I need a relatively high level of control over the 'controller' dongle. Writing a kernel mode driver is not a route I can take.
Example dongle
The linux kernel will handle a lot of stuff for you if you open up an HCI socket. You can also open up L2CAP sockets to make connections to devices. Unfortunately the documentation is lacking (I've actually never found any), but the source code is fairly readable. Take a look at the Bluez gatttool to see how they access bluetooth dongles via sockets.
Note: there's a nasty bug in kernels <= 3.4 where multiple L2CAP connections get mixed together when using an L2CAP socket.
Here's a previous answer I gave to another question with some sample code: bluez with simultaneous classic and low energy devices
I have a device connected to my computer that sends serial data to the computer every 5 mins. I want to write a basic program to capture this serial data every 5 mins and put it into a database. I was hoping to use C# because I have used C# with databases before and found it quite easy.
Can anybody offer me any advice on how I might do this, I really have no idea where to start and I know in theory it sounds easy but when I started it I actually found it really hard.
Using C#, you can use the System.IO.Ports namespace to communicate over the serial ports - there's a nice article here.
Alternatively, you can use Python and the pySerial module. I've written an app to communicate over the serial port using pySerial - it's quite easy to use, and can run on many different operating systems including OSX and Windows (I'm assuming you're using Windows). Python also has built-in support for SQLite.
The problem with capturing data on a serial port is that serial ports aren't thread-safe, so if there is more than one listener, data will be corrupted.
If you are absolutely sure that you're the only one listening for data on this port, .NET has a built-in wrapper, System.IO.Ports.SerialPort, which you can use to connect to COM1, COM2, etc. You'll need to know the rate in bits/sec at which this device sends data (its baud rate), its error-checking (parity) protocol, and the format of the data it is sending (you'll get it as a byte array, which you must convert byte-by-byte into data you can work with). Then, your program should be able to open the port and listen for DataReceived events with a handler that will read and digest the data. Again, it's VERY important that you never have two threads trying to read at once; the easiest way is to set a volatile boolean indicating that a handler is reading data; if another handler is ever spawned while a previous one is still running, the first thing the new one should do is read that value, and since it's set, exit the new handler immediately.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I am looking for a book and or a code sample of how to do serial port redirection or port splitting. I write a lot of com port applications and want to write a monitor application that will allow me to watch the serial port between the application and the device.
So I want to be able to redirect the serial port to another port so I can monitor the data flowing between ports.
I understand in some cases this must be accomplished at the kernel level. (in USB cases)
I have written the monitor application using system.IO.Ports in C#. If I have to call a C++/C assembly that is fine.
Thanks
Joe
You might find that PortMon by Mark Russinovich is helpful in your work, although it isn't provided with source code. It will log all system calls related to a port, and has extensive filtering capabilities to keep that log to a manageable size.
Edit: PortMon works by injecting a kernel mode device driver into the system when it runs. That driver hooks the ports that it wants to monitor by inserting a filter driver into the stack. That filter driver reports all IRPs that pass through it to the application. This is not an easy beast to implement by any stretch, and it really can't be done in user mode.
The Windows DDK does have sample code for a port filter driver, but it is a lot of work to go from the sample to something useful.
A pure user mode solution that might work out is to use two additional serial ports to eavesdrop on the wire. A pair of USB to serial adapters and a bit of wiring will do what you need. Then it is only a "small matter of programming" to monitor and correlate the send and receive lines. A single chip solution could be based on the FT2232H device from FTDI, which has an available evaluation module. Add a couple of RS232 level translators and some D connectors and you've got a serial eavesdropper on USB that looks like two COM ports to Windows.
Another outside the box approach is that many logic analyzers and mixed signal oscilloscopes can do serial protocol decoding, often as an optional component. One source of inexpensive USB+software solutions is Saelig. I've bought chips and modules from them myself, but don't have any direct experience with any of the USB-based logic analyzers they sell despite thinking that I should have one in my bag along with the Netbook...
I wrote one, many years ago. The DDK (device driver kit) included sample source code for a filter driver for (i.e. immediately above) the parallel port driver: I adapted this sample to work with the serial port driver, and then added functionality such as monitoring and splitting.
This was serial ports, not USBs.
I also implemented another driver, which was a 'virtual' serial port, i.e. it implemented a serial port API but then redirected the data I/O elsewhere.
It was a lot of work (many months) to implement.
As always it depends on what you're going to do. If you need to mess around with how the lines between two serial devices are connected or need some 'good' timing informations, the best you can get is an external break-out box like Anthony already told.
If you just need some kind of monitoring you can go with PortMon or Serial Port Monitor.
Maybe you write two applications which are going to communicate over a serial connection. To get this done on a single PC without a local loopback cable you can try Com0Com.
Purchase a RS232 DB9 Serial Data Tap. This is a hardware device that is connected between the two serial ports and listens passively to the "chatter" between the devices. I used the following device for two-and-a-half years and it saved me significant amounts of troubleshooting time and effort. (I use to take it home every night to keep support technicians from "borrowing" it.) It is easy to make this device, but the following data tap is flexible.
"Tap in on a serial data stream and transparently monitor data activity. The output can be feed into a monitor printer or other device. Dipswitches allow programming to monitor the main transmit and receive lines, individually or together. No external power required, easy install, transparent connection Ideal RS232/Serial software development aid."
Alternatively, make or purchase a Serial Tap Monitor Cable. See the NST documentation for one possible configuration.
I strongly recommend you do not use a software solution because the monitoring software may be affected by physical situations.