On Fri, Feb 10, 2012 at 09:12:24AM +0100, pierigno wrote:
> I'm on a recent 3.2 kernel.
> These are my settings reported by the 'stty -a -F /dev/ttyUSB0' command:
>
>
> # before launching minicom, power unplugged from the router:
> n53-sabayon ~/dev/hacking/alice-stb # stty -a -F /dev/ttyUSB0
> speed 9600 baud; rows 0; columns 0; line = 0;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
> eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S;
> susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
> -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
> -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl
> ixon -ixoff -iuclc -ixany -imaxbel -iutf8
> opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
> isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
> -echoprt echoctl echoke
>
>
>
>
> #after minicom has been launched, power unplugged from the router:
> n53-sabayon ~/dev/hacking/alice-stb # stty -a -F /dev/ttyUSB0
> speed 115200 baud; rows 0; columns 0; line = 0;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
> eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S;
> susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
> -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
> ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
> -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
> -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
> bs0 vt0 ff0
> -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase
> -tostop -echoprt -echoctl -echoke
>
>
> I'm using these settings for minicom:
>
> serial port
> A - Serial Device : /dev/ttyUSB0
> E - Bps/Par/Bits : 115200 8N1
> F - Hardware Flow Control : No
> G - Software Flow Control : No
>
> modem and dialing parameters setup
> DTR drop time: 0
> Auto bps detect: No
> Modem has DCD line: No
>
> Terminal settings
> Terminal emulation: VT102
> Backspace key sends: DEL
> Status line is: enabled
> Newline delay (ms): 0
>
>
> With these settings, I'm able to receive the initalization strings
> sent by the router:
>
> The procedure I follow to connect to the tty is:
>
> 1. modprobe -r pl2303
> 2. modprobe -r usbserial
> 3. <plug in the ca-42 cable and wait 3 seconds>
> 4. minicom
> 5. <plug the power chord into the router>
> 6. <text from router flows into minicom. the router stands by for 10 seconds
> listening for a BREAK>
> 7. I send the break command through minicom (CTRL+A, F)
> 8. Yamon prompts appear waiting for commands
>
>
> After the first BREAK, no other textual commands get received by the
> router (seems that additional break commands get sent actuallly, but I
> cannot verify this because yamon does not respond to break command
> when in prompt mode).
>
>
> I'm absolutely not an expert with UART an RS232 communication, but
> looking at the code I've seen that break commands are sent using
> this function:
>
> static void pl2303_break_ctl(struct tty_struct *tty, int break_state)
> {
> struct usb_serial_port *port = tty->driver_data;
> struct usb_serial *serial = port->serial;
> u16 state;
> int result;
>
> dbg("%s - port %d", __func__, port->number);
>
> if (break_state == 0)
> state = BREAK_OFF;
> else
> state = BREAK_ON;
> dbg("%s - turning break %s", __func__,
> state == BREAK_OFF ? "off" : "on");
>
> result = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
> BREAK_REQUEST, BREAK_REQUEST_TYPE, state,
> 0, NULL, 0, 100);
> if (result)
> dbg("%s - error sending break = %d", __func__, result);
> }
>
>
>
> Since I don't read any "error sending break" in my logs, is it correct to assume
> that the transmission channel (from PC to the router) actually works?
Yes, I would assume that.
But, to verify this, try the following:
rmmod pl2303
modprobe pl3202 debug=1
and then plug the device in and do your test. You should see a message
in the kernel log about the break being set. Does that really happen?
> Can I use usb_control_msg() to send data other than BREAK command?
Yes, this device handles lots of different messages on its control pipe,
but that's not really the issue here.
Odds are, our pl2303 device doesn't like sending break commands. These
are cheap chips, and don't always work the best for a "real" replacement
of a serial UART device. I'd strongly recommend just buying a different
type of device, one that is known to work better on Linux, like a
ftdi_sio based device, if you can find one. They should be the same
price as your pl2303 device, it's probably cheaper for everyone in the
long run here :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
