How do I enable InterNiche uart flow control (RTS & CTS)?

[seagate]

I want to enable hardware handshaking so uncommented the two lines in iuart.c :-

/* configure for 8,N,1 with flow control */
   MCF_UART_UMR(dev) = ( // MCF_UART_UMR_RXRTS |
                             MCF_UART_UMR_PM_NONE |
                             MCF_UART_UMR_BC_8 );
                            
   MCF_UART_UMR(dev) = ( MCF_UART_UMR_CM_NORMAL |
//                             MCF_UART_UMR_TXCTS |
                             MCF_UART_UMR_SB_STOP_BITS_1 );

This seems to have no effect.  Is there anything else needs to be done to achieve this?

[TomE]

InterNiche" isn't the name of the CPU, so what CPU are you running? I'm guessing a MCF5208. What board are you using? Is it a development board (what model?) or your own hardware?

>    MCF_UART_UMR(dev) = ( MCF_UART_UMR_CM_NORMAL |
> //                             MCF_UART_UMR_TXCTS |
>                              MCF_UART_UMR_SB_STOP_BITS_1 );

That's tricky. There are three mode registers, all written to through the same register. That makes the code harder to understand than it should be!

If you want to use the UnRTS and UnCTS pins for flow control, they have to be reprogrammed from being GPIO pins to being connected to the UART. Have you done this and does the board you're using connect them through to the pins on your serial port? Your hardware may not have been built to support this.

Anyway, I don't think that setting those bits is going to do what you want anyway. Flow control is usually done in software as most UARTS don't support it in hardware. The Receive flow control that the UART supports is documented as "When a valid start bit is received, UnRTS is negated if the UART's FIFO is full." That means the other end (usually a PC) has to STOP RIGHT NOW and not send another single character. PCs don't work like that. They usually have a transmit FIFO and will keep sending up to 16 more bytes after being told to stop, so the receiver has to be able to receive that many bytes after asserting flow control. This one can't so you have to do the flow control in software and receive into a buffer.

Only if the sender is another device with equivalent flow control (another MCF5208 with the same UART) will this work as expected.

On the other hand, the transmit flow control will probably work OK.

Tom

[seagate]

Thanks Tom.

The cpu is mcf52231 and board is Elektor 'Digibutler'.  I was wrong to state that enabling  RTS/CTS had no effect.  It results in no output from the uart.  Uart0 RTS/CTS pins are connected to a MAX3232 and were not assigned specifically to the primary function in mcf5332_sysint.c.  I added this and ensured that my pc terminal program was set up appropriately but still no result. 

The device I ultimately want to connect to is a Bluetooth module which requires hardware handshaking.  From what you are saying this may be impossible, in which case why are RTS/CTS pins listed for this cpu?

[seagate]

The cpu is mcf52231 and board is Elektor 'Digibutler'.  I was wrong to state that enabling  RTS/CTS had no effect.  It results in no output from the uart.  Uart0 RTS/CTS pins are connected to a MAX3232 and were not assigned specifically to the primary function in mcf5332_sysint.c.  I added this and ensured that my pc terminal program was set up appropriately but still no result. 

The device I ultimately want to connect to is a Bluetooth module which requires hardware handshaking.  From what you are saying this may be impossible, in which case why are RTS/CTS pins listed for this cpu?

[mjbcswitzerland]

Hi

The UART driver will implement RTS/CTS flow control. See http://www.utasker.com/docs/uTasker/uTaskerUART.PDF page 11.

The CTS acts more or less as an interrupt input on state changes and the RTS can be controlled much like a normal output. In addition the RTS/CTS mode also allows protecting the FIFO.

Regards

Mark

[TomE]

> From what you are saying this may be impossible, in which case why are RTS/CTS pins listed for this cpu?

The flow control will work if you connect two of these UARTs together. They can flow-control each other in both directions without any problems.

They just can't flow-control a PC or any other PC-like device with common UARTs that don't have hardware flow control. These devices have to use software flow control. Their UARTs have a hardware FIFO that is between 2 and 16 (or up to 64) bytes deep that has to "run out" when they are are asked to stop. Sort of like trying to stop a train.

> The device I ultimately want to connect to is a Bluetooth module which requires hardware handshaking. 

It requires hardware flow control on the path from your device to it. It needs to stop you. The MCF UART can do that perfectly.

The MCF UART hardware flow control isn't able to stop PC-like devices sending data to it in time. As long as your software is fast enough to not get overrun (and isn't the bottleneck) you may not need inbound flow control. If you do, then you can do what everybody else has had to do and implement software flow control. Or buy an OS and some drivers that are already written to do that for you.

Read Mark's "TaskerUART.PDF" document. It is an excellent introduction to UARTs in general and flow control in particular. It has a graph showing software "water-mark" based flow control.

Tom

[seagate]

Thanks. I now understand this a bit better.   The problems went away when I found the BT device is quite happy to have RTS connected to CTS and I set up for flow control = 'none'.

[TomE]

> the BT device is quite happy

Without flow control you may overrun the device and lose data. You're now depending on lots of other things to not overrun it, mainly the data buffers inside the BT device. The size of these is rarely documented anywhere, and can be different between different models, and even possibly between different software versions of the same device.

if you're just streaming 8000 bytes/second telephone audio through it then the data flow is naturally rate-limited and you may not overrun anything. If you're using it to connect a mouse or a keyboard, likewise the low data rates shouldn't cause a problem. If you're trying to transfer data over it and can push data in over the serial port faster than the BT device can deliver it, then you might overrun. If it is sending data to you, and your software gets busy (writing to FLASH or to USB or whatever it is doing with the data) then you'll get overrun.

If you get flow control working you don't have to worry about this. If you go with "no flow control", just be very careful what you're doing with it.

Tom

[seagate]

At the moment all I'm doing is sending AT commands to the phone to get it to call a number for voice call so the BT only has to handle quite short messages - which it manages OK.  If I hit trouble  later I'll know why!