Using PIN17 as UART RTS / alternative GPIO functions

[martinm]

Hi,

I'm trying to get my PI to talk to some solar inverters via RS485.
At first I was using USB to RS232 cable + RS232 / 485 converter which was basically working but resulted in crashes of the raspberry (I guess because of the well-known FTDI bugs).

Because of that what I want to do is to directly do the communication via the UART pins on the PI.
I bought this Adapter:
http://www.ebay.de/itm/RS485-Board-3-3V ... 5565188%26

It uses a MAX3485, and needs to be controlled via RTS for flow control.
I read here http://elinux.org/RPi_Low-level_peripherals that GPIO17 has UART-RTS functionality, but how can I enable the PI for using this "alternative" function?


Thank you very much!

[joan]

Why not use the regular TXD/RXD pins?

All the C libraries I've seen which muck about with gpios allow you to set the gpio modes.

[martinm]

I am using the TX/RX pins

The picture shows how I connected the PI to the UART / RS485 converter

TX --- DI
RX --- RO

GPIO 17 (ALT 3 funktion RTS) --- RTS

I ran

Code: Select all

bcm2835_gpio_fsel(17, BCM2835_GPIO_FSEL_ALT3);

using the bcm2835 C library and afterwards tried doing the communication with Python and pyserial, but it didn't work.

[Arjan]

I believe you need to disable the serial console first --> http://raspberrypihobbyist.blogspot.nl/ ... t.html?m=1

[atmega168]

Any progress on this? I am trying to do rs-485 as well. Was looking at using hardware flow control pins to make this possible. Tried it in perl by driving the GPIO pins high and low before and after writing.

[ZaccyPi]

Hi,

I'm also currently trying to get this "Request To Send"-signal working on GPIO 17 or GPIO 31, with no luck so far.
I have tried the "C library for Broadcom BCM 2835 as used in Raspberry Pi" where I also used the following line of code to setup GPIO 17 in the Alternate 3 function (UART0_RTS)

Code: Select all

bcm2835_gpio_fsel(17, BCM2835_GPIO_FSEL_ALT3);

Reading out the activity on the TX pin and the GPIO 17 pin, on the scope, gives me serious serial activity on the TX pin, but no change on the GPIO 17 pin (remains at 0V).

I have tried different C examples setting up the GPIO 17 pin for RTS, but nothing happens on that pin.

Any Ideas what to try next...
It is possible that some settings should be done for the TERMIOS options (Termios.h), to enable the RTS signal, when sending data?

[McGregor80]

Hi
I have exactly the same problem.

I enable the CTSEN in CR register of the UART.
I change the function of GPIO17 to ALT3.
I check once more if the values are there and i transmit from uart.
The TX signal is there but no change of the pin17 (checked with oscilloscope).

However if i clear the RTS bit in CR register i see pin 17 is going high (and stays this way).
This would mean that the CTS is taking control of the Pin17 but doesn't change it.

Any advice?
P.S. Also using Uart/RS485 converter chip.

[jojopi]

How would you like RTS to behave? In Linux there are basically two choices:

If you enable hardware flow control (CRTSCTS in "man termios", or "stty crtscts -F /dev/ttyAMA0", or pySerial rtscts=True), then sending will take place only when CTS is asserted. RTS will be asserted except when the kernel input buffer is full. The kernel input buffer is about one page or 4KB, so your application has to get well behind with its reads before RTS actually changes.

Note that this is overflow control in both directions, for use when two DTEs are connected with a null-modem cable, with RTS and CTS exchanged. It is not the same as the historical use of RTS as "DTE wants to send", which was part of half-duplex negotiation used with very old fixed-speed modems.

Alternatively, if you disable kernel driving of hardware flow control, then the signals are available to the application. You can read CTS and RTS, and set RTS, using ioctl TIOCMGET and TIOCMSET ("man tty_ioctl") or pySerial getCTS() and setRTS().

Looking at the MAX348* data sheets, I do not see that producing a "wants to send" signal will fully solve your problems with the half-duplex versions. If both ends want to send at the same time the chips will not resolve the conflict. Both parties need to know in advance who is going to be transmitting when.

[ZaccyPi]

Hi

Well I ended up down a different road - leaving the pi UART alone.
Instead I introduced a microcontroller (pic16F677 w/ i2C) in my hardware Setup. In that way I could create my own "RTS signal", send out serial data, flip the "RTS signal" back and be ready to receive serial data through a RS485 connection (through MAX485)
From the Pi to the Pic I communicated through I2C.

[McGregor80]

In my understanding hardware flow control was automatic (no software/kernel involving) setting and clearing the RTS line which should be connected to DE pin in RS485 converter chip. When data is being sent RTS should be high, otherwise low.

And if you look at the specification of the MAX348x there is also a pin called DE (sometimes ~DE) which decides direction of the A/B lines. Half-duplex.


Even if i ask uncle Google i get the same answer:

http://www.modemhelp.net/faqs/flow.shtml

Especially this link is good for RS485 conversion:
http://www.kksystems.com/english/html_f ... ontrol.htm

But i'll try the tips with TIOCMSET. Thanks

[jojopi]

In my understanding hardware flow control was automatic (no software/kernel involving) setting and clearing the RTS line which should be connected to DE pin in RS485 converter chip. When data is being sent RTS should be high, otherwise low.

There is hardware control of RTS in addition to kernel control. The hardware can de-assert RTS if its receive FIFO is full. In practice this is unlikely to happen because when the FIFO is half full an interrupt is generated and the kernel initiates a PIO or DMA to empty it. Also note that both the hardware and kernel agree that RTS means "you can send to me", not "I want to send".

edit: In fact, it may simply be that once the kernel buffer is full it allows the hardware FIFO to fill too. So actually it is always the hardware that ultimately de-asserts RTS, at least on devices that support it.

Even if i ask uncle Google i get the same answer:
http://www.modemhelp.net/faqs/flow.shtml

That is not an accurate description of RTS/CTS signalling, either as specified by RS232, or as implemented by PCs of the last 30 years. But it does not affect his main point about avoiding winmodems.

Especially this link is good for RS485 conversion:
http://www.kksystems.com/english/html_f ... ontrol.htm

As that page says: "The RTS Control function has to be written into the application program and is not an operating system function which you can configure […] Do not confuse RTS Control with the more common operating mode of the RTS signal which is hardware flow control and which is unsuitable for controlling an RS232-RS485 converter."

This form of RTS control is not the same as the form originally written in RS232, either. There, the DTE would assert RTS and then wait for CTS before transmitting. This allowed time for the two modems to agree on the direction of transmission. These half-duplex RS485 chips do not negotiate with each other and provide a CTS signal. So it is always the responsibility of the high-level protocol to ensure that the two ends do not transmit at the same time. (Or can recover if they do.)

[McGregor80]

You must be rigth jojopi.
I didn't manage to make it run this way. I set the signal manualy as i described in my other post method 3.

http://www.raspberrypi.org/phpBB3/viewt ... 68#p389368

Thanks

[vvn2023]

Hi,

How u able to call the function

Code: Select all

bcm2835_gpio_fsel(17, BCM2835_GPIO_FSEL_ALT3);

I am also want to do that in my machine driver.

How can i call that function?

What i need to change in my code to set the alt function for the gpio that i want to set?

Thanks,
vvn