2
\$\begingroup\$

I am integrating the USB controller FT230X into a new product. It interfaces directly with the 32 bit Cortex M4 MCU, the STM32F303x

The receive buffer on the STM32 is only 2 bytes deep, which I assumed would not be a problem since I could use the RTS signal handshake to halt the receive stream. However, when I send the RTS signal Hi automatically at the end of the first received byte, the data transmission from the FT230X continues for another 2 bytes, which causes an overrun. Is this expected behaviour? Is this a typical problem with USB/232 interface chips?

\$\endgroup\$
2
  • \$\begingroup\$ Where did you get the information that STM32 buffer is only 2 byte deep? \$\endgroup\$ Sep 10, 2015 at 10:28
  • \$\begingroup\$ From the user manual \$\endgroup\$ Sep 10, 2015 at 11:26

3 Answers 3

3
\$\begingroup\$

In my experience, RTS/CTS signals on the modern serial converter chips are horribly underspecified. There is no specifications on them in the standard (in fact, the standard describes RTS/CTS as uni-directional flow control to modem only -- the method no one implements today). Thus, manufactures just make sure the flow control works with regular PCs, which all use 16550A-compatible serial ports with 16 byte FIFOs.

You may try different USB<->Serial chips (like PL2103 or CP2103), but success is not guaranteed. So:

  • Use DMA if your chip supports it.
  • Lower transmission speed
  • Try old-scool 16550A UART or use a newer I2C UARTs like MAX3107
  • Use a different FTDI chip -- for example, FT245 has parallel interface; it will only give you the next byte when you toggle RD# pin
\$\endgroup\$
0
\$\begingroup\$

Assuming that the FT230X is properly configured, you need to use the CTS line to turn transmission on and off. This handshake need to be initialized from the Cortex side. When the buffer is full have the Cortex pull the CTS line high which would stop the FT230X from transmitting. Also have the Cortex monitor the RTS line to see if new data is available.

Ultimately though the Cortex should be plenty fast enough to move the data out of the hardware buffer into a software buffer using an interrupt. This would keep you from having to throttle the data.

\$\endgroup\$
7
  • \$\begingroup\$ CTS is an input, and RTS an output. My problem is not that the chip is not fast enough to read the USART, it is that the USART stuff runs in main() which only gets 3mS out of every 10mS to do its stuff \$\endgroup\$ Sep 10, 2015 at 11:29
  • \$\begingroup\$ Correct on the pins on FT230X side. The Cortex tell the FT230X when to start and stop talking. On Cortex side the pins are CTS is an output and RTS is and input. Also service your hardware buffer using an interrupt and the speed of your main becomes irrelevant. Use the interrupt to move data into a software buffer and then the main can service the software buffer any time it feels like. \$\endgroup\$
    – vini_i
    Sep 10, 2015 at 12:42
  • \$\begingroup\$ The problem is that the USART interrupt has to be lower priority than the one that must work in continuous 7mS blocks of processing \$\endgroup\$ Sep 10, 2015 at 13:43
  • 1
    \$\begingroup\$ If the timing you have is that tight then you have selected the wrong processor or speed of processor for the job. Program time management is outside of the scope of your question. You need to use the CTS (clear to send) pin on the FT230X to meter the data coming into the Cortex and not the RTS pin. \$\endgroup\$
    – vini_i
    Sep 10, 2015 at 14:46
  • \$\begingroup\$ The CTS on the STM32F303x is an input, and the RTS is an output. Doesn't work, as stated above \$\endgroup\$ Sep 10, 2015 at 14:51
0
\$\begingroup\$

Using a ch340 interface and Dos, the fastest Hi to Lo DTR change. The scope took 3 mSec + 3 mSec. As a control line trigger signal it was way to slow.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.