I am running a DOS program in DB (only emulator that works)
This program makes us of com1 RS232 but I get no data activity on the port.
This setup works with other software and trying to localize weather this is DB or the program.
Specifics are the DOS program is a programming utility for radio. This talks to the radio over com1
and requires an interface. Monitoring com1, there is no data, TX or RX.
Noted, this setup works with a different software, but fails. The radio needs this DOS program to work properly.
Thanks people.
Related
I am making a driver for windows kernel and I am using COM1 for getting log of kernel, the host machine is Ubuntu and guest is qemu. Windows 10 is installed inside it. The problem is there is a bulk of data to be write on COM1. So if it has to write a line ABCDEFGHI and in the next line, it has to write JKLMNOPQ.. it is doing something like ABCDEF in one line and GHIJKLMNOPQ in the second line, means one line data is incomplete and 2nd line data is also corrupting due to this.. is there any lock we can apply? that if one connection is using COM1 then no any other should write on COM1?
QEMU does not control who can write to serial port address at certain time. It's the guest OS's job. QEMU just receives whatever data it sees in the virtual registers.
If you really need to write bulk data to the serial port in the guest OS, you would expect very long time of process. I ever had the same problem and had to test the speed on a very fast Intel CPU. The best speed I can get is 220KBps.
If processing time is not a problem for you, from guest Windows perspective, if you directly write to COM1's port address, it's your driver's responsibility to make locking mechanism, assuming there is no other drivers/processes writing to COM1 either. If you write data via a handle to the COM1 device, there is no locking provided directly by Windows built-in serial port driver. But you still can do it in other ways: open a handle to the serial port device exclusively, so only one process can write to it, or make a device filter driver sitting above Windows serial port driver to add this additional access control, or even directly modify Windows serial port driver's source code to add what you want. Its source code is available now on github.
If none of above applies to your case, you might want to double check how you capture the output of COM1 on host, usually redirected to files, shell and etc. They also could cause some mystery of troubles.
I have a small robot which runs on a raspberry pi.
I need to be able to control it with an RF remote to trigger a few different terminal commands which run short python scrips.
Previously I did this with a GUI on my macbook, triggering these commands over ssh, but I now need to be able to trigger them in the absence of an internet connection.
The remote I bought is:
https://www.adafruit.com/products/3092?gclid=CNPj7LjTgNECFdOPswodsiULYA
I realize that this is designed for OSMC.
This remote shows up as a USB keyboard on the Pi, which makes the challenge more general:
* - How could one rig a 'USB keyboard device' to trigger entire terminal commands with the click of one key?*
My low-level knowledge of hardware is limited, and my programming experience extends little beyond python.
Any direct solution or suggested reading is much appreciated.
I am also open to alternatives, however I do not have time to order new hardware online.
You could write a python script which uses the 'os' library to interact with the terminal, have it looking for certain keystrokes and then writing the relevant commands to the terminal via os.
e.g
if (KEY == "F"):
os.system("cd Dropbox")
I have no idea how to do formatting here, but you get the idea.
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'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?
Got a customer request but no idea can it be done. So need your opinions on this. This might be a utterly stupid thing to ask but yet need some facts so can work out best solution.
Scenario,
My Customer is an OEM Manufacturer. They make an automated system with a embedded touch screen (Windows XPe) this system got a button panel with some LED indicators (apart from keyboard) and 7 USB Ports. These button panels and USB ports are checked before sending to QC process. Currently a USB thumb drive with standalone executable with all indicators and controls flags is inserted to one of the USBs and then will run the exe. This exe capture user inputs from button panel and indicate which button is pressed so that it can be verify as working. And from program user can set LED indicators to different states (flashing, steady and off) so they can be verified as well. Once this is done then USB thumb drive will be inserted to each port and will verify it recognise. But after each verify step it needs to safely remove the drive from task bar. Once each test is finish user required to fill up the sheet with all pass and fail states for the entire button panel, indicators and USB ports. This is a quite length process when its come to mass production.
Apart from this embedded system all other components which suppose to connect to one of above embedded systems are tested via a program which I make and records all test outputs as they are tested. This program installed and components are connected to a testing embedded system.
Requirement,
What customer asks, can my program test completed embedded system with our host system (testing embedded system, may be via USB to USB) Its more like Testing a PC from another PC. Any ideas ?
Additional Info.
Apart from USBs there is one Network Port.
Thanks for looking, Feel Free to ask any questions. Any opinion is appreciated.
I'm not an expert on this topic, but it seems like this would be problematic because USB is an assymetrical protocol. There are hosts and there are devices. Hosts make the requests, and devices fulfill the requests. The problem is that PCs are USB hosts, not USB devices, so you would have two hosts trying to get the guy on the other side to do what he wants. Testing with a USB thumb drive worked because the thumb drive is a device.
It sounds like the unit to be tested doesn't have an ethernet port, which is a shame, because that would be the easiest way to go. If it has a serial port you could do it that way, but that is both slow and a hassle.