Vdue

YES, how stupid can a user be. Thanx it works.

1-wire, WiFI AP and UART are now nicely working. Now I am facing a new problem with I2C, which I do not get to work. I enabled i2c7 via armbianEnv.txt and connected the device SDA cable to I2C7_SDA (Pin #3) and SCL cable to I2C7_SCL (Pin #5) and obviously the power cables to the device. nano /boot/armbianEnv.txt .... overlays=i2c7 uart4 w1-gpio param_w1_pin=GPIO4_D6 param_w1_pin_int_pullup=1 .... dmesg|grep i2c [ 1.719815] i2c_dev: i2c /dev entries driver [ 1.720785] i2c 1-0011: Fixing up cyclic dependency with ff880000.i2s ls /dev/*i2c* /dev/i2c-0 /dev/i2c-1 /dev/i2c-3 /dev/i2c-4 /dev/i2c-7 i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- I think I am close, but which essential config am I missing ? The armbianmonitor file is here: link

Atone, thanx for all your efforts. I solved it. It's embarrassing to admit it was a ground issue. The Raspberry and the Rock Pi are sitting next to each other. The Raspi was powered under a real world scenario via a car battery and all devices were connected to the same ground (minus) terminal. I made a short cut for the Rock Pi, which I powered for this test via 15W wall power supply. Therefore, Rock Pi and devices were connected to different ground and that is bad, very bad indeed. And the Rock Pi even works with the odd 1000 Baud config. Why this is the case I do not understand but I do not care it works. Thanx again for your efforts.

Yes I tried 1500000 and that looks to me the hardcoded baud rate for /dev/ttyS2 in /boot/boot.cmd The device only communicates with baud 1000 (it's a Votronic solar charge controller) If I am doing a config in Node Red 1200-8N1 and an then in terminal $ stty -F /dev/ttyS4 I am getting: speed 1200 baud; line = 0; min = 1; time = 0; -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke with Node Red 1000-8N1 and $ stty -F /dev/ttyS4: speed 0 baud; line = 0; min = 1; time = 0; .... and stty -F /dev/ttyS4 1000 produces tty: invalid argument ‘1000’ Now I can pinpoint 1000 Baud is a problem, can this be overcome without putting a ISP32 data collector in-between

Sorry for the late replay, but your system only allows one message within 24h. Please find enclosed the link to the: Armbianmonitor file

I am in the process to migrate a project from a Raspberry Pi 4B to a Rock Pi 4B+. Among others external devices shall be connected via WiFi AP, I2C, 1-Wire and UART to the Rock Pi. To emphasis, the system is running healthy on a Rasberry. I managed to get WiFi AP and 1-Wire up and running on the Rock Pi. Now I got stuck with UART/UART4. Armbian 22.11.1 Bullseye with Linux 5.15.80-rockchip64 I enabled UART4 via Armbian-Config. Therefore, /boot/armbianEnv.txt shows: ... overlays=i2c7 uart4 w1-gpio param_w1_pin=GPIO4_D6 param_w1_pin_int_pullup=1 ... I can take a jump wire and bridge the TX-pin (GPIO1_B0, Pin#19) and RX-pin (GPIO1_A7, Pin#21). When sending bytes to the TX-pin I am receiving them instantly on the RX-Pin. That indicates to me the UART4 is working. On my system the serial port is /dev/ttyS4, with a baud rate of 1000!!. (I am doing this test via Node Red using a standard serial node) However, if I connect my TTL-signal cable to the RX-pin (TX disconnected), I do not see anything the RX-Pin (however this setup works on the Rasberry). I have done the same test on UART (/dev/ttyS2) with same result, not showing anything. I have no experience in Armbian or Rock Pi and would appreciate any hint into which direction to look. Is the unusual baud rate of 1000 a problem, or do I need some pull-up resistors or do I need to compile another dtbo driver like for the 1-wire?