4 Replies Latest reply on May 13, 2015 12:36 PM by FerryT

    UART with HW (RTS/CTS) flow control

    FerryT

      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

        • 1. Re: UART with HW (RTS/CTS) flow control
          FerryT

          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?

          • 2. Re: UART with HW (RTS/CTS) flow control
            Intel_Peter

            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 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 low

            Take a look at the note below table 3 on Intel® Edison Products — Intel® Edison Kit for Arduino* Hardware Guide under section 2.2.

             

            Peter.

            • 3. Re: UART with HW (RTS/CTS) flow control
              FerryT

              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.

              • 4. Re: UART with HW (RTS/CTS) flow control
                FerryT

                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.