[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bluetooth-dev] Problem writing a TTY under the stack.

Thanks all for your replies.

I'll explain my conclusions here so it may help someone else, somedays...

You were right, 0x11 is part of the XON/XOFF control bytes.
This is set by default through the termios structures (c_iflag) and is transparent to
the stack since the io takes care of everything.

It's possible to turn it off by using tcsetattr() (on a client point of view).

Since I didn't want to touch the code of the Axis stack, I had to do it "reverse" from the
device point of view, using:

tty->termios->c_iflag = tty->termios->c_iflag & ~IXON & ~IXOFF

It works now perfect, my "virtual device" is talking to your stack and they understand each others !



Peter Kjellerstedt wrote:

> -----Original Message-----
> From: Gordon McNutt [mailto:gmcnutt@xxxxxxx.com]
> Sent: 07 May 2001 17:06
> To: laurent@xxxxxxx.edu
> Cc: bluetooth-dev@xxxxxxx.net
> Subject: Re: [bluetooth-dev] Problem writing a TTY under the stack.
> Laurent Eschenauer wrote:
> > Hello everyone,
> >
> > I have a really strange problem while working with the stack, I hope
> > that you may help...
> >
> > I'm trying to develop a driver that I have to put UNDER the stack.
> > This is the first step on the
> > long journey to build a virtual bleutooth driver that may
> be used with
> > any tty based stack out
> > there...
> >
> > That means that I'm writing a tty like driver which acts like
> > /dev/ttySx and I connect the Axis stack to this driver.
> >
> > It works almost fine in USER_MODE but I didn't implement yet to
> > support the kernel mode, it is quite tricky
> > to support the IOCTL to register the bt stack discipline.
> If you have
> > any suggestion on how to do that, I would
> > thank you a lot  but it's not my problem for tonight !
> >
> > Here is the problem. When my driver has to send a message
> to the stack
> > I use something like this:
> >
> > tty->ldisc.receive_buf(tty, (u8 *) data, NULL, len)
> >
> > If you don't understand this line, you probably can't help me. I'm
> > calling the receive
> > function of the line discipline above me to send the buffer.
> >
> The line discipline is N_BT, right? Where does your driver
> get the data
> from before passing it up to the ldisc? Does your driver see the 0x11
> byte before passing the buffer up?
> --gmcnutt

0x11 is ^Q, so a guess would be that it is ^S/^Q flow control
somewhere that is stealing the byte. There should be problems
with 0x13 (^S) then too.

To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com