I am trying to use COM RS232 serialport-rs example receive_data and it only works on Mac or and Linux. It does not work on Windows 10. The example is blocked waiting for data and not receiving anything.
If I open the COM port with Arduino's serial monitor I see data coming into the PC's port, but Rust's serialport-rs example does not seems to receive anything. Anybody else have the same issue?
Library sources for reference https://gitlab.com/susurrus/serialport-rs
I know you might've found your issue but figures I'll post it anyway. You might need to change your flow control. I encountered this exact issue and I had to change my flow control to hardware control.
let mut final_port = serialport::new(&port_str, 115_200)
.timeout(Duration::from_millis(1000))
.open().expect("Failed to open port");
final_port.set_flow_control(serialport::FlowControl::Hardware).unwrap();
Related
I'm interfacing to a hardware serial device using QT, I've based my application roughly around the Terminal example, but as the communication needs to be very synchronous the serial handler is living in another thread. The connection is via a 2xRS232 to USB adaptor with an FTDI chipset.
The serial comms are fine, I can connect, send commands, etc. However, when I quit and reload the application the serial port seems to be blocked.
Let COM1 be the connected device, COM2 is unconnected.
If I run the program, do a bit of talking to the hardware and quit, I can no longer connect to COM1 the next time I run the program (the data leds don't flash on the adaptor) unless I attempt to connect to COM2 first. Once I've tried this I can then connect back to COM1 as usual. This behaviour is not seen in the reference utility for the hardware and so must be down to some way I'm handling the port.
My close code is:
void mydevice::closeSerialPort()
{
this->stop();
serial->close();
emit serialClosed();
emit log("Serial port closed.");
}
serial is a QTSerialPort. First a stop command is sent to turn off the hardware (not relevant to the problem, it's just a convenience) and then I send a close command to the serial.
I have a subclassed QWidget for my main window, which calls this command on exit:
/* In the constructor */
connect(this, SIGNAL(WindowClosed()), mydevice, SLOT(closeSerialPort()));
void mainwindow::closeEvent(QCloseEvent *event)
{
emit WindowClosed();
event->accept();
}
Is there any reason for this behaviour? I assume I'm blocking the port open somehow, but surely it would complain that it's already open.
Another odd issue is that say the device is on COM1 and I open it in my application, COM1 is unresponsive in the other utility and the device appears on COM2. However, when I switch back to my program and fiddle a bit, the device appears on COM1 again (though always in COM2 in the other application).
So there seems to be a fairly simple solution, though I don't understand exactly what was causing the problem.
I have two threads, each controlling a different serial device. The serial configuration is accessed through a dialog which I stole from a QT example (the terminal). Each thread has an instance of this settings dialog. It seems that something goes wrong when selecting the port - for instance all the selections in the dialog actually point to the same COM port if checked in a debugger.
Anyway, I chalked this up to non-thread-safe code and changed the program to just ask for the serial port name as the data rates, stop bits, parity, etc are fixed by the hardware and aren't going to change. This has fixed the problem.
There are two possible answers, I think:
Your process doesn't terminate in spite of you closing the main window. How have you verified that the process is, in fact, terminated?
Your use of qt's serialport module exposes a bug in FTDI's driver. That's not unthinkable, but I'd call it a remote possibility at the moment.
Personally I don't see any use for the serial port emulation of the FTDI driver, it's adding an extra layer for no good reason. The D2XX interface is the way to do it, if you don't want to use something like libftdi. On Windows, I've found D2XX and libftdi to be the only viable alternatives, with libftdi working much better than D2XX on virtual machines.
Don't know if this could be useful.
I have a similar issue (but not the same) with a prolific pl2303.
In my case when i close the port (or even at startup, before opening it!), data is received anyway somehow and presented immediately when i open the port.
This happens only with an usb-rs232 adapter, if I use the ttyS0 (physical serial port) the problem does not appear.
The solution for me was forcing QSerialPort::clear() to clear buffers just after QSerialPort::open(). This avoids signal readyRead to be emitted and thus unwanted data to be received.
I have an application in windows, that opens a com port. It attempts to call a comport, then fails and prompts me with an error.
The issue is this is very legacy software that we no longer have the source code for. I'm wondering if anyone knows of a way that can trace, or follow a program calling a com port to find out what com port its attempting to allocate.
Appearantly you can use Process Explorer (as called out in this post) to search for processes using serial ports. It sounds like you should be able to use the same searching concept called out the other post to find what you need.
I actually gave up on this solution and re-wrote the entire program in a week, it had to be done due to binary compatibility issues with the PCI cards.
I'm rather unexperienced on the field of microcontrollers, I come from a Java background so the question might seem a bit noob but I didn't find much information on this.
So is it possible to debug an STM32F4 board via bluetooth (using eclipse or some othe IDE)? And if so could you send me some links that might help? We're building a robotic car controlled by a discovery board and debugging using an USB cable is not really an option if we don't want to disassemble the whole stuff every time something goes wrong. Hence this would really come in handy. So any help is appreciated
For doing this you would need to find a "Bluetooth Enabled" Debugger. I have never seen any and not sure whether there exists such thing or not.
I would suggest you one thing:
Assuming you have bluetooth connectivity between your board and your Machine,
Insert Debug strings: Send some strings from your board to your PC via Bluetooth. These strings will give you what's going on in Circuit.
For example, After Initialization, send "Init Completed" and like that. You can see these strings and see what's wrong.
I usually do this for my Wireless Device.
What you're wanting to do is really not practical; you're coming at this from way too high a level and trying to imagine the system as if it were running an operating system from the word go.
When you get the STM32 it as empty shell; you need to program it to do what you need to do and the only [sensible] way to get register-level debugging is to use a JTAG interface.
If, and this is a big if, you get it working reliably, but just want to give some debug information back while it is running, you could write a load of routines within the code to send out debugging messages when it enters certain parts of the program - and send it out over Bluetooth - but this is nothing like what you're used to single stepping through your Java code with Eclipse. If you want to do that kind of thing, you are going to have to put a little connector on that allows you to connect your JTAG or two-wire debugger cable to the processor. Even then, when you do that, you will be completely resetting your program and not simply single stepping through from where it went wrong.
You could insert a monitor program within your program to send out register values, program status etc over Bluetooth, but you still have to write the inital code and the only way to do this with out a ridiculous amount of trail and error is via your JTAG or two-wire interface.
Would this product work? It's a "IOGEAR Bluetooth Serial Adapter, GBC232A" for connecting to a serial port over bluetooth. I'm interested in wireless debugging too because my surface-clone dev computer only has one usb and this seems like it could be convenient over a tangle of usb cords and a usb hub. I have zero experience with any of this, so maybe you could validate or invalidate it as an option. I figure it just needs a proper serial connector wired up on the board and power from on-board?
For the needs of my software I need to create a printer driver which will allow me to save all the images which are sent to it to files and then open my program's window letting the user to do something with the rendered pages.
I have found this article, but the sample uses the FILE: port, while I need to make my own port, dump the images to files and run an executable. However, I think I can accomplish my task by doing that in the driver's code, but I am not really sure that it is a good decision, since it is a driver, even though it is a user-mode driver.
I would be glad to hear any advice on my problem. Thanks in advance.
You need a port monitor, not a driver. See my answer to this question. You can use RedMon, but I recommend using the sample port monitor found in the WDK instead.
If you are OK with using XPS as format you can use the Github project: Microsoft/Windows-driver-samples/print/XPSDrvSmpl
https://github.com/Microsoft/Windows-driver-samples/tree/master/print/XPSDrvSmpl
Installer: http://wixtoolset.org/
Application: Listen to internal port
Flow: Install printer and application from a single installer. User prints something with your driver and while the application listens to the internal port. When data is sent the application picks it up. This is for XPS, can be converted to PDF, but the flow is similar no matter what you are printing. If you need anything else check out Microsoft/Windows-driver-samples/print/ on GitHub or other sources specific to your needs.
I am trying to make U9 telit modem send SMS messages. I think I handle protocol correctly, at least, I manage to send them, but only under these circumstances: the native application was executed beforehand, and killed by task manager (without giving it a chance to initialize things).
It looks like the supplied application is good at doing certain initialization/deinitialization which is critical. I also see the difference between the two states in output of AT+CIND command. When I am trying to do things on my own, it returns zeroes (including signal quality), but when I run the same command after killing the native application, the output looks reasonable.
I am out nearly of ideas. I have tried many things, including attempts to spy at modem's COM ports (didn't work). Haven't tried setting windows hooks to see what the application is trying to get thru.
Perhaps you have encountered a similar situation?
Agg's "Advanced Serial Port Monitor" actually helped a lot. Sometimes it caused blue screen, but it helped uncover secret commands which seem to help. AT+PCFULL is not described anywhere on the net, for example. The real trigger of non-operatio was AT+CFUN, the power disable/standby feature.
Also, it appeared that we have more issues. At first, the modem appears on the bus only as disk drive. It doesn't want to appear as any other devices before the drivers are installed. So, the U9 Telit software sends an IOCTL to disk driver to tell the modem to reappear as more devices (modem, 3 serial ports, another disk drive).