On Thu, Oct 11, 2012 at 03:51:00PM +0530, Sourav wrote: > True. I missed that point while doing the testing. Sorry for that. > I further looked into it and saw some two options in my minicom > settings(Hardware Flow Control/ Software Flow Control) Which I am > thinking are the ones used to enable the flow control ? and they are > both set to NO. > > I already enable software flow control and did the testing on beagle, > where things are working fine > after off mode. > But if I enable hardware flow control, the teraterm does not allow me to > load my fs and uImage from mmc. > If you have any pointers on how to test hardware flow control, I will > like to do that on my beagle board. Okay, it sounds like I need to do a teach-in on flow control... First, hardware flow control. Hardware flow control is operated by two signals: RTS and CTS. In conventional setups, CTS is an input to the transmitter, and controls whether the transmitter may start the transmission of a new character. If CTS is deasserted, the transmitter will stop after the completion of the previous character. When hardware flow control is disabled, the transmitter ignores this signal. RTS is an output, and is generally used to control the remote transmitter. (There are setups where RTS means something else, but the kernel doesn't support other schemes directly.) RTS is asserted when either hardware flow control is disabled, or there is sufficient space to receive more characters from the remote end. This is a symetrical setup, so that two UARTs connected together using this scheme will have the RTS of one connected to the CTS of the other. This way, each can signal whether characters should be transmitted. So, in minicom, when hardware flow control is disabled, your hosts transmitter will ignore the state of the CTS signal, and will hold its RTS asserted. If hardware flow control in minicom is enabled, then that tells the kernel (and possibly hardware) to take note of the CTS signal, and pause transmission when CTS is deasserted. It will also cause the RTS signal to be manipulated according to available buffer space on the receive side. Obviously minicom will try to ensure that any characters received are displayed as quickly as possible, so it's unlikely that the receive side will fill up. When you're logged into a system via a serial line, the hardware flow control state is controlled by the CRTSCTS termios flag. That can be seen and manipulated by stty. stty -a to see all flags. stty -crtscts to disable, stty crtscts to enable. Now, for software flow control. It operates in the same way as above, but instead of a hardware signal reporting the state, characters are embedded into the stream. In normal situations, these characters are the standard ^Q (noramlly XON) and ^S (XOFF) characters. You'll find that works in gnome-terminals, xterms, and many places because it's part of the standard terminal interface. You can type these characters into minicom with or without software flow control disabled; it just passes them through unmodified. When software flow control is enabled, and the tty receive buffers start to fill up, the kernel will queue a high-priority XOFF character for the UART to transmit to the remote end. Once the tty buffers have emptied sufficiently, it will queue a high-priority XON character. If software flow control is disabled, it will ignore this. When hardware assisted software flow control is enabled, this will be done by the hardware itself in response to the UART FIFO filling up and emptying. For the target, software flow control has more configuration options: ixon: controls whether the transmitter starts/stops on reception of xon/xoff characters ixoff: controls the generation of xon/xoff characters ixany: permits any received character (including xon) to restart transmission stop <char>: sets the xoff character to the specified character start <char>: sets the xon character to the specified character xon and xoff default to ^Q and ^S respectively, there's no need to 'initialize' them prior to use. So, to enable software flow control (which is probably already enabled on the target): stty ixon ixoff and then you can type ^S and ^Q into minicom to stop/start the target's transmit output. Finally, to make the target's input buffer fill up, arrange for the target not to read from the controlling tty at all. sleep 120 will do that for two minutes, after which the input will be gobbled up by the shell (which it'll try to interpret as commands.) So, probably better to do: sleep 120; echo Finished; cat >/dev/null instead, and then send lots of data, and check whether the transmission stops, whether the right xon/xoff characters are transmitted, and whether any overrun errors are reported. Going the other way, you can suspend minicom (^a z) and then arrange for the target to send lots of data, and again check what happens. There's a gotcha there though: with standard 8250-based serial ports, we have /proc/tty/driver/serial which gives easy access to the port statistics. With USB stuff, those statistics are not available, so it becomes much harder to test. You have to arrange for the target to send a known pattern, and find some way to check at the host end that it was correctly received, including over the flow control events. No characters should be lost when flow control is being used; after all, that's the whole point of the facility. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
