Advanced users • Re: AMA0 RS-485 mode

"1. What evidence do you have that it is still in RS485 mode?"
The issue is that switching to RS-232 doesn't seem to work, as the communication only operates in one direction.

The driver RS485 mode doesn't inhibit reception on the serial port. Normally it would be wiring RTS to both nRE and DE of your RS485 transceiver that will mean you don't receive at the same time as transmitting.

Almost all RS485 interfaces will be a basic UART with suitable RS485 transceiver (eg MAX485 or MAX3485) on the output, same as an RS232 interface will be a basic UART with MAX232 (or MAX3232 for 3.3V) transceiver on the output.
Yes some UARTs have smarter logic built in for controlling RTS that is linked to the MAX(3)485, but it makes relatively little difference.

Do you know why I am able to manage GPIO to work with the AMBA driver in Linux 5.10, but it seems to be a problem in version 6.6? In 5.10, I was able to add code below to function pl011_probe

Code:

ret = devm_gpio_request(&dev->dev, MOO_GPIO_NO, "pl011-serial");if (ret < 0) {pr_err("gpio_req says nay\n");return ret;}ret = gpio_direction_output(MOO_GPIO_NO, 1);if (ret < 0) {pr_err("gpio_dir says nay\n");return ret;}

but now return

Code:

[    5.760375] uart-pl011 fe201000.serial: there is not valid maps for state default[    5.760625] uart-pl011 fe201000.serial: cts_event_workaround enabled

What value are you using for MOO_GPIO_NO?
gpio_ calls and fixed GPIO numbering has been deprecated in the kernel for a fair few releases, and is now actively logging an error if a GPIO controller tries to force the base GPIO number. For this reason from 6.6 onwards pinctrl-bcm2835 hasn't been setting the base GPIO number.
You should be looking at gpiod_, or using DT to assign the GPIO.

Statistics: Posted by 6by9 — Tue Jul 09, 2024 10:52 am

---