I just received three USB TTL adapters each with a different chipset, and was testing them.
The CP2102 (I already own one, and it works normally) shows a weird defect: either by connecting it to another adapter (either of the two) or working in loopback, it will not TX data. No led activity, no bytes received on the other side (when it's connected with another adapter).
By chance though I noticed that when I close minicom (Ctrl-A, X, Yes), all that wasn't sent before, gets send at the same time after minicom closed (at least certain amount of data, I tried sending a file in ASCII mode and only a handful of rows of it was transmitted to the other adapter when I closed minicom).
OS is Ubuntu 19.04 64bit, and I'm running minicom as root from a terminal window. Either leaving out the baudrate (defaults to 115200) or setting it explicitly to 9600, the same thing happens.
Is this adapter toasted, and it's good just for RX-only appliations, or is there a way to get it back together?
You should try to disable Hardware Flow Control in minicom settings:
$ minicom -s
Then go to
Serial port setup
and set
Hardware Flow Control
to No
In the end, the adapter was not "defective", it just doesn't play nice with the minicom application in particular.
I fetched the other "working" CP2102 adapter that I had bought few years ago, to be used for another project from where I switched out a CH340G, and I could use it as expected both in TX and RX with a PHP script that I wrote for a SIM800L.
Then I connected to it with minicom because I needed to issue some commands manually, and the same thing that I describe in the question above also happened with this other CP2102.
I made a few modifications to my PHP script to make it act as a normal, user operated serial console, and I could both send commands and receive responses succesfully, where minicom couldn't.
I then fetched the "supposedly broken" CP2102 adapter, and I also could use it correctly with my homemade PHP serial console, whereas minicom simply didn't accept any user input.
Related
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.
I have a Microsoft Surface Book that I've dual booted Linux Mint on. I'm writing a program that needs to read in data from a serial port, but my serial ports don't seem to be working. The behavior is consistent across Mint and Windows (Testing done through Cygwin). It gets a bit of data the first 2-5 seconds that the device is plugged in (viewing the data through screen, same thing happens if I just use pyserial to print data incoming from serial port), then nothing.
What could be happening? I think I've isolated the problem to the serial ports - the Surface Book has 2 USB ports and the same thing happens on both of them, and I've tested the hardware that I'm plugging into it on 2 other computers (One Linux and one Mac OS), and it works fine on both of those.
Your MS Surface, seemingly, has a yellow triangle exclamation mark icon (over the adapter icon) without any driver to install/download. And properties in the device status box window say This device cannot start. (Code 10) or A device which does not exist was specified. Right?
If it's so you should wait for an update from MS. It's notorious problem.
I ended up getting the computer replaced on warranty for an unrelated issue months later, and what do you know, on the new computer the serial ports work fine. That indicates to me some sort of hardware problem, given that the issue persisted across OS's.
maybe this will help:
see Arduino examples for serial port communication - search google:
arduino serial c++
arduino serial c#
arduino serial c++ linux
the point is to open port properly you need to open a file, not a port. not with usual c - assembly write to port code.
another option you are using an unintentionally bought fake USB to serial cable with a Fake PL2303 chip
then you need to install the old version of the driver.
search in google:
Fake PL2303 + your os name:
install driver Fake PL2303 windows 10
another option is maybe it conserves energy and closes the port because it feels it is unused.
in windows> device manager,> properties of a device - usually USB root hub > power management - allow the computer to turn off this device to save power - uncheck it.
https://superuser.com/questions/408683/why-my-usb-mouse-gets-suspended-after-3-seconds-of-inactivity
https://blogs.msdn.microsoft.com/usbcoreblog/2013/11/08/help-after-installing-windows-8-1-my-usb-device-doesnt-charge-or-it-disconnects-and-reconnects-frequently/
also, you could look in windows events - to see what happens. usually, failures like this are registered in the events log.
an unlikely option is it consumes too much current, like a short circuit. and the device protection circuit shuts the chip off. also probably it does not have such circuit. one possibility is to try with an external powered hub.
the most probable of these is the power saving mechanism
I was experiencing the same problem - came across the solution on another site. The USB 3 ports on Surface Book aren't compatible with something or other to do with Com Port but running the device through a cheap USB hub solved my problem straight away and it was instantly recognised by the Arduino IDE
So has anyone done this?
I'd like to store a hex file on an SD card and just blast it to any boards I have with the catarina bootloader on them when I connect to my uploader device.
This seems to be the correct protocol to talk to the catarina bootloader (the command definitions are at the end.) http://www.atmel.com/images/doc1644.pdf
If I manually force it into programming mode from COM4 by setting it to 1200 baud and closing the port, then opening COM5 and sending it one of the commands I do get a response as I would expect but even if I put it in programming mode by sending "P" it dropps back out after a second or two and doesn't stay in programming mode as I would expect.
It seems that the timeout gets reset/extended if certain commands are sent so I guess that makes sense.
I'm new to serial communication. For a project I have to develop software for a vending machine. The vending machine basically consists of a host computer (a windows xp machine) and various peripherals. One of those peripherals is a coin acceptor. According to the documentation of the vending machine, the host computer communicates with the coin acceptor using the serial port. The only documentation I have is this document called "Multi-Drop Bus / Internal Communication Protocol" (the version I have can be found here: http://www.coin-acceptor.com.cn/Upload/EditorFiles/technicalfile/Mdb_version_4-2.pdf).
According to the docs it seems I have to create a serial port connection using a baud rate of 9600, 1 start bit, 1 stop bit, 1 mode bit and 8 data bits (page 29 in the linked document). The vending machine docs state that the coin acceptor is on COM port 6. I tried to create a connection like this using HyperTerminal and Putty. My first question is:
How do I properly create a connection to a device that supports this MDB 'protocol'? Putty and HyperTerminal don't allow me to set a "mode bit". I didn't find anything about the flow control and parity bit in the document. Can this be done using Putty or HyperTerminal? Or do I need some other tool to communicate over MDB?
My second question is about how to send a command to the device. I looked through the commands and saw a RESET command. According to the document, upon receiving the RESET command the device should reset itself and respond with an ACK. According to pages 33 and 63 of the document, if I want to send the RESET command to the coin acceptor, I can send the HEX value 08H over the serial line. Page 33 states that the coin changer listens to commands sent to addresses 08H until 10H (if I'm interpreting the document correctly, that is). Page 63 states that the RESET command is 08H with no data bytes. So can I just type "08H" into Putty and hit "enter" to send this command to the device? Or how can I send this command to the device over the serial line? Is this even the right approach or am I looking in the completely wrong place? The vending machine docs only contain this document for the coin acceptor. Thank you for the help!
Kind regards
Chris
I have an Arduino sending and receiving instructions with a Python script via a serial port.
The Arduino takes a button state and when it is pushed, it will send a message via the serial port to a Python script and await a response. (via Serial.available()). It works well enough.
However, if the Python script has crashed for whatever reason (ideally it will run in the background, so it can't be easily checked), the Arduino will wait forever and will be unavailable even on a script restart.
Is there a way for my Arduino to check if there is something listening on the serial port? (and alert me with flashing lights, etc. if not) or is this not how serial works? Worst case I guess I could use a timeout, although that is not ideal.
You have a limited ability to detect if there is something listening on the other side by using the DSR/DTR pins.
When you open the serial port on the machine your scripts runs on, it should raise its DTR pin (or you should be able to convince it to do so: the documentation of the library you use to drive the COM port should tell you how).
Then, on your Arduino, you can check its DSR pin (assuming null-modem wiring with handshaking, where the PC DTR pin is wired to DSR+CD on the Arduino) at regular intervals, and handle the 'nobody connected' scenario in any way you see fit.
One problem with this approach is that your PC script may not close the serial port when it crashes/stops responding, leaving the DTR pin enabled as if everything is still OK. Also, your script may simply miss the message from the Arduino due to errors on the serial line.
For that reason, you should always implement a timeout in your receive routines: even if there is a party listening at the other end, there is no guarantee it has received your message (or that its response will reach you intact).
Re-sending the message at least once (assuming DSR is raised) if a timeout occurs makes your protocol more reliable.
The Arduino doesn't use the DSR line or any other handshaking line, so you can't do what you suggest.
I agree with mdb that timeouts are necessary, but would also add that you might want to implement simple challenge/response system that periodically checks if anyone is listening. (I like ircd's Ping-Pong analogy).