I have firmware installed on an Arduino DUE from a different mac, it is designed to interface with a Matlab-based application. It has been tested and known to work. I am attempting to modify the firmware from the mac in my office, but I ran into a snag after installing the Arduino IDE.
First, I cannot get the Arduino Serial Monitor to interact with the DUE. I have tried multiple times, it worked once but I have not managed to make it work since. No errors are reported.
Second, I cannot get the screen terminal command to interact with the DUE either. No errors are reported.
Third, if I simply use text pipes in the terminal (e.g., echo 'status' > /dev/cu.usbmodem1421 or head -20 /dev/cu.usbmodem1421 &) I get appropriate responses from the DUE.
Fourth, the Matlab application can interact with the DUE just as designed.
Note that this is the native USB port in the DUE, no serial adapters (with their driver weirdnesses) are involved. I have not tried to download new code to the DUE as the firmware works as it is as long as we use macs (it is just that I need to modify it so that it can work with the much-slower ports in a Windows PC).
I need to be able to debug the code I am modifying, and for that I need to be able to interact via a terminal, any terminal. Any ideas of where to look?
UPDATE: I noticed that the code was not waiting for USB to be ready. So I added
while(!WiredSerial){
digitalWrite(PIN_LED, HIGH);
delay(125);
digitalWrite(PIN_LED, LOW);
delay(125);
}
After this change the DUE waits for the terminal to be opened and the terminals display the initialization text without a hitch. After that the behavior is the same as reported before.
Never mind.
I was certain that I had already checked this before posting. As a matter of fact, I am sure that it is the first thing I checked, something else must have changed in the interim.
The code was expecting a newline character before it sent anything back while the terminals were just sending a carriage return.
Related
I've put together a Powershell script to allow me to connect my Bluetooth headphones to my PC without having to open the Bluetooth settings page each time (based on the ones in https://github.com/stanleyguevara/win10-bluetooth-headphones, but using Get-PnPDevice and Get-PnPDeviceProperty to check whether the device is connected rather than using an environment variable to save the state).
The script works, but there's one big QoL issue. The script uses the Bluetooth command line tools here to connect/disconnect the device (in particular, it uses the btcom command). However, these commands are very slow to run, with the whole process taking around a minute total. This is true even though I am using the device's MAC address to connect, and not its friendly name (which would be even slower). This makes using the script much slower than just opening the settings panel each time (though opening the settings panel is less convenient since it requires opening and going through multiple windows).
I've seen many questions about this sort of thing (how to connect/disconnect a Bluetooth device from cmd/powershell, but everything I've seen regarding Windows tends to suggest using the Bluetooth command line tools at the link above, so they don't solve the speed issue. Other things I've found suggest disabling the Bluetooth adapter entirely, which isn't what I want to do. Others suggest using the Win+K shortcut to open up the connections sidepanel, but this doesn't really address the question of whether there's a way to do this from cmd/powershell, and is slightly less automated since you have to wait a second for the list to populate and manually navigate to the device to connect/disconnect (though at least it solves the problem of opening a bunch of windows).
Is there a way to connect/disconnect from a Bluetooth device in cmd/powershell that is faster than btcom?
I need to be able to close COM ports through the command prompt (Windows 7 OS). The reason for this is that I work with a lot of experimental equipment, controlled with a language called LabVIEW, and communication to these devices is sometimes lost. Right now the only fix is to either rename the COM in device manager, or reboot. Ideally I'd like to close the port in command prompt, which I can implement programatically in my control software.
Does anyone know either; how to close a COM port in command prompt, or a quick and easy way of closing a COM port, so then I can reestablish a connection with my device?
Cheers!
I don't think you can simply close a resource that is in use by another program, this will undoubtedly lead to errors. Programmed correctly LabVIEW should not leave ports open, even if port are left open simply closing labview should be enough.
In LabVIEW programatically open and close the COM port, don't rely on the auto-closing of the VISA system. Also add timeouts to the serial connections, than you should get a connection error time out and be able to clean up the resource.
Basically you need to solve your problem at the origin, if help needed post your LabVIEW code.
Presuming you read from the serial port in a while loop, simply stop the while loop when an error is found, see the code snippet. This stops the loop and the resource will be closed outside the loop regardless of the error.
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 asked this question over on the Apple Communities and got a grand total of ZERO responses. You guys seem a whole lot smarter, so thought I would ask here to see what you think.
An error has started occuring when I attempt to trigger an Applescript via an external process. The console error is as follows:
12/09/2012 11:01:39.205 osascript[269]: Scripting addition loading restricted to system domains because this process has mixed credentials (issetugid=0 r/e uid=501/0 gid=20/20)
When I run the script locally on the Mac(Mini - Mountain Lion 10.8.1) it works perfectly.
What is happening is as follows.
I have a MacMini as a music server in a home automation environment powered by a Crestron processor. The MacMini is connected to two zones, one via the Optical output and another to a DAC from one of the USB ports. When I selected "Listen to iTunes" in one of the two zones the controller sends a command via UDP to a program running on the MacMini which triggers the scripts to change to the appropriate audio out.
All was working well until yesterday when all of a sudden the program triggering the script, whilst reporting that it has executed the correct script correctly, isn't switching the output and the above message is appearing on the console.
I have read what I can on here and as such have reset the PRAM and SMC (all three dongs...) and deleted the script triggering program, run Clean My Mac and rebooted, all to no avail.
Can anyone help me with this, it has to be something simple given that it was working...surely? I haven't run an update or changed anything else that I can think of.....
Any and all thoughts and input would be greatly appreciated.
Thanks
Marc
From the error it seems that you have an add-on to applescript called a "Scripting addition" installed, and that's causing the error. Most likely you do not need this add-on to perform your applescript code. So I would remove all scripting additions from my system and see if the applescript still works.
Search your system for scripting additions... ~/Library/ScriptingAdditions and /Library/ScriptingAdditions.
If you do need to do something that the scripting addition is doing for you, then there's probably other ways to perform the same task without the add-on.
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).