I am using the bgapi library to manage bluetooth communication using a USB dongle. The library will take a command from my program and will handle all serial communications through the COM port in its own thread. I want to echo back all data coming out of the COM port, but the library only gives me access to what it chooses to parse out itself.
I could go into the bgapi library and change the functionality of the code, setting up a variable or function to return what data is currently being read, but other people are also working on this project and changing the library could cause larger problems or invalidate updates.
Is there any way for me to access the data coming into the COM port without interfering with the library, like sniffing the data going through the COM port without taking it out of the buffer for the library? The library holds the port open for itself and discards the extra data that I want to see.
I'm not sure I understood completely how your library works so I'm not sure this will work for you but you can give it a try anyway.
What you can do (on Windows) is use Termite as a man-in-the-middle with port forwarding.
Since you probably want to keep everything inside one computer you can use com0com to create a couple of virtual ports.
To activate port forwarding on Termite you have to go to settings and then forward on the bottom-left side of the screen. You'll see a menu where you can choose the port you want to forward to. On the following screenshot I can forward from COM1 to COM2:
After selecting the right settings for COM1 you accept and connect by clicking on the big button marked COM1 57000 bps... and you'll see everything incoming on COM1 forwarded to COM2 and displayed on the console.
Related
first sorry if this is a simple question but I can't figure this out. I have this development board and on page 19 on the kits user guide the block diagram shows a RS232 line and on page 20 and 22 the schematic show the pins I need to connect to use RS232. My problem is that, despite being able to configure the fpga/cpld, I cannot find the com port on my computer (using pyserial and the following code(I tried changing COM%s in line 15 to FTUSB-%s)). So my questions are:
What interface does the FTDI, ft2232h USB to UART/FIFO, chip use (Serial, parallel... ) on the computer's end (like arduino's virtual COM port)?
On lattice's software there are 3 options to program the device. the program shows the following: HW-USBN-2b (FTDI) (with port as FTUSB-0), HW-USBN-2b (with port as ezUSB-0) and HW-DLN-3C. How can I use either of them to communicate with the device outside of Lattice's software?
thanks for you time.
1) RS232 is a combination of UART with certain voltage levels for the high and low (i.e. +3 to +15V and -3 to -15V afaik. Never ever connect a RS232 adapter to standard 3.3V or 5V devices e.g. UART, TTL-UART etc. The Lattice Semiconductor document just plainly missuses the term RS232 - try not to fall for it (IMHO the performance of their products strongly anticorrelates with the quality of their documentation and support).
2) page 19 of the linked doc shows the sections: Ordering Information, Technical Support Assistance, Revision History. Shifted by one page?
3) The FT2232H can be used in multiple modes. This depends on the way how it is addressed and of the settings flashed to the EEPROM connected to it (on the dev board is one placed but the FT2232H can be used without as well). The dev board is in the standard configuration designed to be programmed via the JTAG pins and the FT2232H is opened via the D2XX driver by lattice diamond. For that reason they flashed the EEPROM with settings which prohibits the use as virtual com port. The FTDI flash software can be used to change that behavior - for each bank seperately.
4) The solder bridges can be used to rearrange the connections (e.g. if one wants to change from the JTAG interface to the SPI or I2C programming interface). In your case you most likely want to place bridges on R14 and R15 to make the proper connection for an UART link to the port B of the FT2232H. EDIT: This way Port A can be used in JTAG mode to program the FT2232H and port B to communicate via e.g. UART or even other modes like the fast opto or the parallel bus/FIFO - if the correct bridges are soldered. Changing the EEPROM settings might be still required to make Port B visible as VCP if one want to avoid the usage of the D2XXX driver.
Most things were said in the previous reply, but here again in a slightly different way. This is what you need to prepare the use of an UART connection to the FPGA, but still needs any generic UART module configured into the FPGA after that:
This was tested on the Lattice MachXO3D development board, but I crosschecked that at least this part with the pins is the same with the MachXO3L board that you linked:
First, you need to bridge (solder) resistors R14 and R15 to connect UART RX and TX pins from the FTDI to the FPGA. You can use 0 Ohm resistors or just do it with solder tin, they are close enough for that. After that, FPGA pins/sites C11(=Tx) and A11(=Rx) can be used for your UART inside the FPGA, that you probably have as a Verilog/VHDL design. You find this information by looking at the "Appendix A. Schematics" of the user guide.
Additionally, something that was at least needed for the MachXO3D is to reconfigure the FTDI chip with FTDI's "ftprog" software. Not sure if it is needed for the MachXO3L, but it is easy to check and causes no harm:
Run "ftprog". Search/Parse for your FTDI chip and find the configuration for "Port B", and change "Hardware" from "245 FIFO" to "RS232 UART", and "Driver" from "D2XX" to "Virtual COM port". Then the second of the two ports you get from the FTDI chip (COM# in Windows, /dev/ttyUSB# in Linux; # being a number) should be usable through some virtual terminal software, use with python-serial, etc.
In Linux, the ftdi_sio kernel module has to be unloaded (sudo modprobe -r ftdi_sio) for Lattice Diamond to be able to program the FPGA, and after that loaded again (sudo modprobe ftdi_sio), to be able to use the respective /dev/ttyUSB# device. In Windows it doesn't need that and just works with python using COM#. Any suggestion to make this easier in Linux is also welcome!
In any case, as already said, you still need the respective UART module programmed in the FPGA and connected to the respective sites to be able to use it.
Update: I found that at a very obscure location, Lattice also documented a part of this, which is the User Guide to their Propel SDK. You can find the information starting Page 39 there: Lattice Propel SDK 2.0 User Guide
So I am working on a project that has a Raspberry Pi connected to a Serial Device via a USB to Serial Connector. I am trying to use PySerial to track the data being sent over the connected Serial device, however there is a problem.
Currently, I have my project set up so that every 5 seconds it calls a custom port.open() method I have created, which returns True if the port is actually open. This is so that I don't have to have the Serial Device plugged in when I initially go to start the program.
However I'd also like to set it up so that the program can also detect when my serial device is disconnected, and then reconnected. But I am not sure how to accomplish this.
If I attempt to use the PySerial method isOpen() to check if the device is there, I am always having it return true as long as the USB to Serial connector is plugged in, even if I have no Serial device hooked up to the connector itself.
You might be able to tell whether the device is physically plugged in by checking the status of one of the RS232 control lines - CTS, DSR, RI, or CD (all of which are exposed as properties in PySerial). Not all USB-serial adapters support any of these.
If the only connection to the device is the TX/RX lines, your choices are extremely limited:
Send a command to the device and see if it responds. Hopefully its protocol includes a do-nothing command for this purpose.
If the device sends data periodically without needing an explicit command, save a timestamp whenever data is received, and return False if it's been significantly longer than the period since the last reception.
I am relatively new to Python. I wrote a script and need to add triggers that need to be send via an usb serial port to another pc. The problem is that the triggers (in this code example the 2) never show up on the software on the other pc. When I check it with the print() command, it does print a value, but the printed value is the same number for two different triggers. I have read other posts, I searched the internet, and I tried various things, but I didn't manage to resolve this iusse. This is the code I use for interfacing with the serial port (COM3).
#this part of code is defined at the beginning:
import serial
ser = serial.Serial(port=2, baudrate=9600)
ser.close()
#this part of the code later on to interface with the serial port:
ser.open()
ser.write(chr(2))
ser.close()
Maybe anyone here has any suggestions on where the problem could be? Thanks!
If you haven't already, check that the port settings are correct, 9600,8,N,1 for example. These must match the settings of the remote serial port.
It might be useful to check that the serial connection does work with a terminal emulation program such as minicom (linux), or PuTTY (Windows). Once you have verified that a connection can be made and data transferred, you can be certain that you are connecting to the correct local port, that the port settings are correct, and that your serial cable is working properly.
If this is a stupid question, please don't mind me. But I spent some time trying to find the answer but I couldn't get anything solid. Maybe this is a hardware question, but I figured I'd try here first.
Does Serial Communication only work one to one? The reason this came up is because I had an arduino board listening for communication on its serial port. I had a python script feed bytes to the port as well. However, whenever I opened up the arduino's serial monitor, the connection with the python script failed. The serial monitor also connects to the serial port for communication for its little text input field.
So what's the deal? Does serial communication only work between a single client and a single server? Is there a way to get multiple clients writing to the server? I appreciate your suggestions.
Multiple clients (e.g. Arduinos) communicating with one server (e.g. a desktop computer) is commonly done with the serial variant:
RS-485
This is a simple method widely used in industrial settings where you want to have many devices connected to one computer via one serial port. This type of arrangement is also called multi-drop, because one cable strings around a building with Tees that tap in and drop lines to each device.
The hardware for this is widely available. You can buy USB serial adapters that provide the hardware interface for a computer. Programmatically the port looks just like an RS232 port. For the Arduino you would just add a transceiver chip. A sea of serial transceivers exists, e.g.
Example computer USB adapter with 485 interface
Sample RS485 transceiver chip from Element14
All the devices hang on the same bus listening at the same time. A simple communication protocol used is just add a device address before every command. For example:
001SETLIGHT1 <- tells Arduino "001" to turn on the light
013SETLIGHT0 <- tells "013" to turn off the light
Any device hanging on the cable ignores commands that do not start with their address. When a device responds, it prepends its address.
001SETLIGHT1DONE <- response from device "001" that the command has been received and executed
The address in the response lets the receiving party know which device was talking.
Well, your question can be quite wide, so I'm going to layer my answer:
On the hardware side, the same pair of wires can work be shared with many devices. It is mostly a question of electronics (maintaining the signal in the good voltage range), and not having all devices writing to the serial port at the same time (or you'll get wreckage).
On the software side, on the host, yes you can share the same serial connection to a device with multiple processes. But that's not straight forward. I'll assume you're using an unix (macos or linux):
in unix, everything is a file, your serial connection is one too: /dev/ttyACM0 on linux, for example.
When you have a process opening that file, it will block it (using ioctl, iirc) so no other process can mess with that file too.
Then, you can input and output to that file using the process that opened it, that's all.
But hopefully, it is still possible to share the connection between processes. One of them would simply be to use the tee command, that will be able to get input from one process, and give it back output, and copy the output to another process. You can also do it from within python, by duplicating the file descriptor.
To easily output stuff that can be redirected the unix way (using pipes), you can use socat: http://www.dest-unreach.org/socat/
here's an usage example:
socat -,raw,echo=0,escape=0x0f /dev/ttyACM0,raw,echo=0,crnl
you may want to tweak it for your needs.
Edit:
I forgot about RS-485, which 'jdr5ca' was smart enough to recommend. My explanation below is restricted to RS-232, the more "garden variety" serial port. As 'jdr5ca' points out, RS-485 is a much better alternative for the described problem.
Original:
To expand on zmo's answer a bit, it is possible to share serial at the hardware level, and it has been done before, but it is rarely done in practice.
Likewise, at the software driver level, it is again theoretically possible to share, but you run into similar problems as the hardware level, i.e. how to "share" the link to prevent collisions, etc.
A "typical" setup would be two serial (hardware) devices attached to each other 1:1. Each would run a single software process that would manage sending/receiving data on the link.
If it is desired to share the serial link amongst multiple processes (on either side), the software process that manages the link would also need to manage passing the received data to each reading process (keeping track of which data each process had read) and also arbitrate which sending process gets access to the link during "writes".
If there are multiple read/write processes on each end of the link, the handshaking/coordination of all this gets deep as some sort of meta-signaling arrangement may be needed to coordinate the comms between the process on each end.
Either a real mess or a fun challenge, depending on your needs and how you view such things.
I'm trying to communicate with a device that uses the same protocol whether you're talking to it over a TCP socket or a serial port. Either way, it's an ASCII command-based interface, in which you type your command at a prompt, followed by a newline, you get a response with a newline, and then a new prompt.
> IDENTIFY
DEVICE_TYPE_RESPONSE
> TEST POWER
OK
>
The program can and should block until it gets the new prompt, but there needs to be a timeout so you don't wait forever in case of sudden device death. That timeout should be seconds so as not to falsely flag on a network glitch, but shouldn't force me to wait seconds once I've gotten my prompt character.
I'd love some way to abstract the interface so as to not care about what the underlying communications layer is. Just pass it either an open socket or an open serial port and let everything happen. Is there some good way to do this? Preferably capable of running under Python 2.6.
You could implement the protocol in Twisted which allows you to use TCP or the serial port as a transport without changing your protocol implementation. Twisted also allows you to set timeouts/delayed callbacks.
Python's serial package provides a lot of useful stuff including some serial over TCP/IP bridges. If you want to talk to it using ASCII/Telnet then you probably want the to use the '--convert' option with the Simple Serial to Network (TCP/IP) redirector.
Also you might want to take a look at this other related question on Converting serial port data to TCP/IP in a linux environment