I'm having an embedded linux device. I'm using ttyO2 as my console.
However, at the same time my MCU need to perform RS232 communicate with a device through ttyO2.
Now lets say if the MCU and the device are communicating, and I type some characters in the console terminal, or there runs another thread that will invoke function printf() , will that conflicts with the 232 communication? is the printf() outputting to the ttyO2?
Thanks
I'm using ttyO2 as my console.
so you configured serial port as console, printf() output will be redirected to console. i.e serial port.
If your board is communicating over RS232 with an external device, then then board and the device are connected with a serial cable. How can you also connect the the serial terminal?
In any case, using the same serial port as console and as a communication port is a bad idea, because there are a lot of things that can be printed: the console I/O, the kernel debug, other programs output to stdout and so on.... Do you think you can have a stable communication with all that "junk" on the wire?
Related
I'm currently in a situation that my SoC will be connected via its I2C bus through a I2C-to-UART converter MAX3107 to the UART port of a microprocessor.
Although the communication between the two shouldn't be an issue, the part were the Soc should update the firmware of the microprocessor has to be done with the Y-Modem file transfer protocol.
Although a question is pending at the manufacturer, I still wanted to check here:
Would this even be possible
The SoC runs Linux, is this depending on the MAX3107 driver
Does this concern the I2C bus or is only the UART driver and bus interesting.
https://datasheets.maximintegrated.com/en/ds/MAX3107.pdf
I used the SC16IS750 instead with the Linux kernel driver.
Sending a file via Y-Modem doesn't seem to be a problem. I tried both Minicom and TeraTerm to send a file and it works. The receiver responds is just 1 character each time before sending a part of the file. If the responds would have been more than 64-byte at a time (instead of the one character) this would have been a problem, because the FIFO first needs to be read and cleared before another sting can be received.
I need to write a program (C++) that uses a serial port to communicate with another device. The other device isn't even built yet so I need a software emulator For various reasons there is no point going into here, the software emulator needs to run on a different machine. I would like to send the data via UDP from the software emulator to the machine my program is running on and have it received by another serial interface type program that in some way acts as a serial port (serial tty device).
I also want to test my program in an automated fashion in a VM. Ideally my test program would also use UDP and would use the same UDP-serial interface program to forward the data back and forwards between my test program and the program under test.
Time is very tight. I don't really have time to learn to write and install kernel level device drivers.
I would be very grateful for any pointers as to how I can create some sort of "pipe" or "loopback" pseudo-serial device.
I am working on Linux.
Credit to meuh for his tip-off.
socat UDP:127.0.0.1:5001,bind=127.0.0.1:5000 \
PTY,link=/dev/ttyS0,raw,echo=0,waitslave
This listens on UDP port 5000 on the loopback network interface. All data received is sent to the virtual serial device at /dev/ttyS0. All data received on the virtual serial device is sent to UDP address 127.0.0.1:5001.
The IP address can be remote.
The command must be run as root, as must the process connecting to the serial port. To avoid this use a different file path, e.g. /tmp/ttyS99.
Apparently the file path specified must not already exist. However my PC has /dev/ttyS0 all the way to /dev/ttyS31 despite not having any serial ports, and using /dev/ttyS0 works fine. I suppose if I actually had a real serial port this wouldn't work.
I want to know whether Linux kernel device driver of serial port device, e.g. /dev/tty1, /dev/tty2, support poll() operation?
Or tell me where is the kernel source code of serial port device?
In my case, some sensors will send data to ARM CPU via serial port each second. And I think one way is to use a timer for periodically read from the serial port. Another way should use poll(), read it when data is ready.
Unless your serial port is a special case, using poll() or select() would seamlessly work.
If your serial port was controlled via USB, you would have to take care about what happens if the USB to serial is disconnected, but this does not seem to be the case for you.
I am trying to communicate with a device over a RS-485 half duplex serial line. When I send a command to the device, it processes the command and replies immediately after processing. The problem is I have to turn my RS-485 chip into receive mode immediately after sending the command in order to receive the reply of the device. But because my write function of the UART is a non-blocking IO operation I have no way of knowing when to turn my RS-485 chip into receive mode.
How can I do a blocking write operation into the UART that the function will not exit unless all of the bytes are actually sent over the serial line?
What is your hardware platform? I have solved that problem before (atmel AT91SAM9260) by configuring the hardware to automatically set the RTS signal. That is your best bet unless you modify the serial drivers in the kernel (and sometimes not even doing that you can do it)
I'd like to establish a simulated Bluetooth connection between two Java programs running on the same machine. I am writing to program that uses BlueCove's BT library to connect to a hardware device; I pass the bluetooth address (ex. "btspp://1C659DF6B5AC:1;master=false;encrypt=false;authenticate=false", which contains the device's mac address) to my program to connect.
I would like to write another java program that emulates the hardware device so that I can do testing (my hardware is not currently working). Is there a way to simulate a bluetooth device with either a mac address or some other kind of bluetooth address which can send data over to my program?
By emulating the hardware you are possibly doing more work than needed, is it possible to create a mock connection "before" the BT library has been invoked (or for you to remove it temporarily)?
By doing this you can craft some code which behaves like the connection, but doesn't require you writing device drivers.