Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor I
1,391 Views

UART with HW (RTS/CTS) flow control

This issue is driving me nuts:

We have been playing a bit with UART1 on the Edison for Arduino board. This seems to be working fine.

Now we are trying to get RTS/CTS flow control working. It seems that CTS is working as we need to pull that low to get TX to start. And even though we can see TX actually working (on the oscilloscope), RTS remains low all the time.

Even when trying to control RTS from linux it remains low.

Note that when we control GPIO 129 (multiplexed with RTS on IO5) it works fine (as input, or as output high or output low).

We believe to have accurately followed the HW guide (rev. 7 feb 2015) for configuring the GPIOs, code below.. RTS is on 129, output enable is on 252 and pullup on 220.Of course after running this script we run a small exe that configures the serial port and starts transmitting.

Has anybody here actually tried the serial port with RTSCTS control?

# RTS

 

echo 129 > /sys/class/gpio/export

 

echo 252 > /sys/class/gpio/export

 

echo 220 > /sys/class/gpio/export # pullup enable

 

 

# TRI_STATE_ALL signal is controlled by GPIO 214

 

echo 214 > /sys/class/gpio/export

 

echo low > /sys/class/gpio/gpio214/direction

 

 

# RTS

 

echo high > /sys/class/gpio/gpio252/direction

 

echo in > /sys/class/gpio/gpio220/direction

 

echo mode1 > /sys/kernel/debug/gpio_debug/gpio129/current_pinmux

 

echo out > /sys/class/gpio/gpio129/direction

 

 

# TRI_STATE_ALL signal is controlled by GPIO 214

 

echo high > /sys/class/gpio/gpio214/direction

 

 

Fixed typo - FT

4 Replies
Highlighted
Valued Contributor I
14 Views

Re: UART with HW (RTS/CTS) flow control

Further, I've tried to find the GPIO definitions in the kernel sources, but can't seem to find that. Are these defined in some firmware file or am I just missing something?

Highlighted
Employee
14 Views

Re: UART with HW (RTS/CTS) flow control

Hello FerryT,

I believe there's a couple of lines that are swiped:

# RTS

echo 129 > /sys/class/gpio/export

echo 252 > /sys/class/gpio/export

echo 220 > /sys/class/gpio/export # pullup enable

# TRI_STATE_ALL signal is controlled by GPIO 214

echo 214 > /sys/class/gpio/export

echo low > /sys/class/gpio/gpio214/direction <----------I believe this should say <strong>high

# RTS

echo high > /sys/class/gpio/gpio252/direction o <----------Is this a a typo?

echo in > /sys/class/gpio/gpio220/direction

echo mode1 > /sys/kernel/debug/gpio_debug/gpio129/current_pinmux

echo out > /sys/class/gpio/gpio129/direction

# TRI_STATE_ALL signal is controlled by GPIO 214

echo high > /sys/class/gpio/gpio214/direction <----------I believe this should say <strong>low

Take a look at the note below table 3 on http://www.intel.com/support/edison/sb/CS-035275.htm Intel® Edison Products — Intel® Edison Kit for Arduino* Hardware Guide under section 2.2.

Peter.

Highlighted
Valued Contributor I
14 Views

Re: UART with HW (RTS/CTS) flow control

The second one is indeed a type, or actually a copy paste error.

The first and third may be true, but I don't think of any influence. AFAIK this resets the ardiuno shield - but we don't have any connected. We have the oscilloscope connected directly to verify the communication.

We took the low / high values from the example 11.1 in the same document. Looks like the document is inconsistant.

My point really is: the RTS line is not working. That is 252 in mode 1.

0 Kudos
Highlighted
Valued Contributor I
14 Views

Re: UART with HW (RTS/CTS) flow control

Looks like I need to answer this myself, feeling a bit dumb now.

Apparently linux and modern PC's in general use a modified standard TIA-232-E. Here RTS doesn't mean Request To Send (which would need to be acknowledged by the other party), but means Ready To Receive. I.e. it indicates the receive buffer has space to hold one more byte.

As the Edison appears to be very fast, the receive buffer doesn't fill up in our case and hence RTS is low all the time.

BTW we tied TX to RX and RTS to CTS and are reading and writing 64 successive bytes at 1Mb in bursts with 1 second in between. From the oscilloscope we see the bytes are transmitted back-to-back with 0us interchar delay. This was what we are hoping for as the UART allegedly has a 64 byte FIFO.

Now we will start decreasing the 1 second delay between messages to see the effect of context switches and ultimately get and idea of how well the Edison will behave as a hispeed bus master.

0 Kudos