Stelian Pop wrote:
>
> On Tue, May 08, 2001 at 10:05:27PM +0200, Wolfgang Grandegger wrote:
>
> > I assume that you have the following device:
> >
> > http://www.sitecom.com/ShowProduct.asp?PID=242
>
> Right. However, there are two devices, one with a second USB uplink
> port, one without. My device is the one without the second USB port.
>
> > This device comes indeed with almost the same driver
> > (USB2SER2.3a.zip) as "my" MCT U-232 ... which puzzles
> > me even more.
>
> I tried only the Windows ME driver (Philips98ME2000.zip), found
> on the Sitecom's support site at:
> http://www.sitecom.com/Showsupport.asp?SID=112
>
> > I think it's very unlikely, that the converter works
> > at all with an invalid baudrate setting and a few
> > people out there have already used a Sitecom converter
> > successfully with the MCT driver (as far as I know).
>
> Well, as far as I understand this, it could work with an
> invalid baudrate setting, because most serial devices (such
> as external modems etc) auto adapt to the host's baudrate.
> Suppose that the driver is setting the baudrate to 9600 bps,
> which means that the driver will be telling the device to set
> it at 115200/9600 = 12 = 0x0c. The device will be interpreting this
> as being 115200 bps and nobody will notice.
On a Sitecom device this is a possible scenario. I only have an
"original" MCT U-232 and there I have seen the Win98 baudrate settings
with SniffUSB. Furthermore I tested it with a null-modem cable to
my PC running minicom/zmodem transfers and the throughput increased
with the baudrate.
> I'm positive about my patch (at least for my exact device), I've tested
> it at all possible baud rates with a null modem cable.
>
> > Hmm, what's wrong? Could you show me a listing of the
> > device properties (as found in /var/log/messages or
> > produced with lsusb -vv).
>
> Of course, here it is:
...
> Bus 001 Device 003: ID 0711:0230 Magic Control Technology Corp.
...
> Endpoint Descriptor:
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> wMaxPacketSize 2
> Endpoint Descriptor:
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 3
> Transfer Type Interrupt
> wMaxPacketSize 64
> Endpoint Descriptor:
> bEndpointAddress 0x02 EP 2 OUT
> bmAttributes 2
> Transfer Type Bulk
> wMaxPacketSize 32
That's interesting. One my device I have:
Endpoint Descriptor:
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
wMaxPacketSize 64
Endpoint Descriptor:
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
wMaxPacketSize 64
Endpoint Descriptor:
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
wMaxPacketSize 2
That's significantly different !!!! The MaxPacketSize for the
bulk out is 64 bytes instead of 32. Hmm ...
> > PS: BTW: I know a problem with DTR/RTS setting. RTS is
> > not always set for hardware flow control. Here's
> > the patch:
>
> I don't know if it's really relevant in my case, but thanks,
> I will try the patch.
I think it's not relevant for your problem but it could cause
problems in the startup of the device.
> BTW: Did you see my other patch concerning the maximum packet
> size for the output endpoint of this same device ?
Yes I have realized it. I have the impression that your device
is not equivalent to mine.
--Wolfgang.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
