Hot answers tagged

10

I'm quite confident the problem is that the Pi does not have an RS232 interface, while the display has. The Pi has an (LV-)UART interface, its TX-pin outputs 0V for a logical 0 and 3.3V for a logical 1. This is quite easy to implement, since 3.3V is already available on the Pi. But this only works for communications on a single PCB or within a single ...


7

It looks like you might be a bit confused about how this all works. First, /dev/ttyACM0 does not represent the USB link, or even the USB endpoint for whatever serial adapter you have connected, it represents the UART inside the adapter that handles the serial communications. Data you read from it will not include any USB headers or framing, just like ...


5

The built-in Raspberry Pi serial port uses voltage levels of 0 to 3.3 Volt, as described here. The USB to serial converter and your display will use RS232 voltage levels of nominally -15V to +15V, with a minimum of -3V/+3V. You need to convert between these two levels. The port will work when looped back as the output and input voltages are compatible.


3

Finally found out that I was issuing the wrong command on receiver's side. Receive command shall be : cat < /dev/ttyUSB0 > file_b64 Summary To receive from remote : Host side | Remote side | | #Encode to base64 ...


3

You can certainly put an intervening socat in the way, and use its logging facilities. For example, socat -v /dev/ttyUSB0,b19200,raw PTY,link=$HOME/myserial,raw,echo=0 2>logfile & minicom -p $(readlink $HOME/myserial) This will log the data read in each direction, shown by ">" or "<": < 2017/07/14 14:33:58.210584 length=3 from=0 to=2 hi >...


3

A UART (Universal Asynchronous Receiver Transmitter) is not a protocol, it's a piece of hardware capable of receiving and transmitting data over a serial interface. I presume you are selecting some design block for your FPGA design implementing an UART.


2

You would first disable getty running on your serial port device /dev/ttyS0 (or whatever it is named for your hardware) to free it (for example, by editing /etc/inittab and running telinit q - if you managed to steer away from systemd) and then you would run pppd(8) on it (either manually with appropriate parameters or via additional tools like wvdial)


2

I'm sure someone is still doing this, but back in the days before stuff like ILO/DRAC/etc. became cheap and ubiquitios the best way to get "out of band" access to the console in case of emergencies or an oops was over the serial port. You would mount a Terminal Server in the rack, then run cables to the serial port of your servers. Some BIOSs supported ...


2

My config on Orange Pi Zero for UART on mainline kernel: overlay_prefix=sun8i-h3 overlays=usbhost2 usbhost3 uart1 uart2 Both UARTs work fine. $ uname -a Linux orangepizero 4.13.16-sunxi #20 SMP Fri Nov 24 19:50:07 CET 2017 armv7l armv7l armv7l GNU/Linux


2

strace is not likely to give you the necessary level of detail; you will probably need SystemTap, sysdig, or similar kernel-level debugging to better show when what is happening. For example with SystemTap installed and all the necessary debuginfo and setup details taken care of one could start with: probe begin { printf("%-16s %s\n", "TIME", "WHAT")...


2

Finally, I got it really working. This is not the perfect setup, but at least it works so maybe it can help someone in the future. I used a Python script on top of PySerial to start tcpdump over the UART and use hexdump so that the binary data can traverse the link without being modified by the tty transcription rules. Then the Python script converts back ...


2

Summarizing above posts i found something like this: Sending. Start receiving on target: cat | base64 -d > filetotarget.bin Exit minicom with Ctrl-A + Q and then run on host machine: cat filetotarget.bin | base64 > /dev/ttyUSB0 Return to minicom and press Ctrl-D to finish receive process. Receiving. Start delayed send on target: sleep 10 ; cat ...


1

Ok, I don't know why, but after I changed to use bash shell, the script works. The default shell is dash.


1

The problem was that the device tree did not correctly configure the RTS and CTS pins for use with the relevant UART. The device tree should contain something like: &uart1 { pinctrl-names = "default"; pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>; status = "okay"; }; Where the pins have been appropriately defined earlier.


1

After trying everything listed in the "Long and Detailed Question", I still had no luck initializing my UART ports. My problem ended up being that my BeagleBone Black (BBB) came preflashed with Debian 8 while I was running a Debian 9 image on an external SD card. I am no expert on boot processes or BeagleBones but from what I found, the BeagleBone ...


1

I had this problem, and resolved it by simply dropping Debian 9 and using this Debian 8.6 image instead, under the "Older Debian images" category on this page. Upon booting into it you'll see the /dev/ttyO1,O2,O4 files, but they won't work until you set the pins to the right pinmux (I was thrown for a loop by this, as it all used to be handled by device ...


1

Well, had to make a lil' script to do this, eh, good enough: cat > slowpipe << 'EOF' #!/usr/bin/env bash set -eu data=$(< /dev/stdin) hz=$(bc -l <<< "1.0 / $1") while [ -n "$data" ]; do printf '%s' "${data:0:1}" data=${data:1} sleep $hz done # XXX It seems to be imposible to save leading newlines in variables, # you ...


1

Upgrade your kernel to a newer kernel. There were issues with this driver in the earlier kernels.


1

You might get some clues from lsmod: $ lsmod Module Size Used by bnep 12310 2 hci_uart 22713 1 btbcm 8478 1 hci_uart bluetooth 425568 22 bnep,btbcm,hci_uart ... In this example, on a raspberry pi 3, perhaps you want btbcm?


Only top voted, non community-wiki answers of a minimum length are eligible