On Wed, Jan 11, 2017 at 10:49:22AM +0300, Maksim Salau wrote: > Hi Johan, > > Thanks for feedback. > > > > * Dropped inversion of DTR and RTS signals > > > > Did you figure out whether this was needed or not, for example by > > comparing to the hardware flow control levels? > > The current version matches the Windows driver. > > I don't have any other adapters at the moment, but > here is what I get from the adaptor with the current version of the driver: > mcr = TIOCM_RTS; > ioctl(fd, TIOCMBIC, &mcr); /* results in low level (0V) */ > ioctl(fd, TIOCMBIS, &mcr); /* results in high level (5V) */ > > As far as I know, this is not the way other adaptors work. > Please, correct me if I'm wrong. Yes, the control lines are typically active low for TTL-level logic, but I don't think it's standardised (e.g. as it is for RS-232). I think it's right to keep them as in the current version of the patch (i.e. active high) which is accordance with the datasheet, but if possible you should verify the levels when using hardware flow control to be certain that the polarity is not inverted when enabling hardware flow control. > > > The device I have have only one output signal that is toggled by > > > tiocmset(fd, TIOCM_DTR, 0) and tiocmset(fd, TIOCM_RTS, 0). > > > > What do you mean by the above? Does your device only have one of DTR and > > RTS wired? I'd still expect you to only use one of the TIOCM defines to > > set and clear it. > > Sorry, I was wrong in the way I interpret behavior of my test program. > The board I have has only RTS wired. I've just verified with a logic analyzer > that everything is fine with signals (RTS is controlled like mentioned above, > DTR is not wired or disabled in firmware). Sorry for the mess. No, worries. Thanks for clarifying. Johan -- 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
