serial via USB.

[FRANK333]

To control from terminal a remote orangepizeroplus in case of lockup, I connected the otg to the USB port of a second Opi0+ modifying a usb cable to which I disconnected the power cables (+red and -black).
I gave these commands on the orange to monitor:

# 	
echo "g_serial" >> /etc/modules
mkdir -p /etc/systemd/system/serial-getty@ttyGS0.service.d

nano /etc/systemd/system/serial-getty@ttyGS0.service.d/10-switch-role.conf
#add 2 lines save and exit
[Service]
ExecStartPre=-/bin/sh -c "echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role"
	
systemctl --no-reload enable serial-getty@ttyGS0.service
echo "ttyGS0" >> /etc/securetty
reboot

on the second orange connected to the network, I made a simple script of serial activation:

simple script chmod +x,it disconnects with ctrl+a and then d

#!/bin/bash
dmesg | grep tty
sudo chmod 666 /dev/ttyACM0
echo "defscrollback 5000" > .screenrc  is 5,000 lines enough?
screen /dev/ttyACM0 115200

Everything works but in dmesg I have this warning:

cdc_acm 3-1:2.0: ttyACM0: USB ACM device
musb-hdrc musb-hdrc.2.auto: request 0000000019a4bba3 not queued to ep1in.

 

Sometimes after exiting the console I can't login again and I have to restart the service.

Someone, can explain me the problem or how to solve it?

 

 

[Werner]

Moved to Common issues / peer to peer technical support

[ExploWare]

Modifying a USB cable like that will break communication.
You could try reading up the USB documentation, but most USB clients will need the 5v to detect a host, and nearly all communication need the shared ground.

If it was just a pure UART you could leave the 5v (most commonly the red wire but not always)  disconnected and still have normal communication,but for USB like here it is not the case.

There are only few implementations of bi-directional communication using two wires, most have time-based-transmission to avoid collisions. If interested, search RS485 for example.

Modifying a USB cable like that will break communication.
You could try reading up the USB documentation, but most USB clients will need the 5v to detect a host, and nearly all communication need the shared ground.

If it was just a pure UART you could leave the 5v (most commonly the red wire but not always)  disconnected and still have normal communication,but for USB like here it is not the case.

There are only few implementations of bi-directional communication using two wires, most have time-based-transmission to avoid collisions. If interested, search RS485 for example.

[FRANK333]

the two orange pi are powered separately, the microusb (otg) port is connected to the other's usb type A port with the modified cable and it works perfectly. I cannot tell you why, but I have only experimented.