"Tosoni" <[EMAIL PROTECTED]> writes:
> It has always been the standard for all modems.
Look, I've been using various modems for many years, starting with
self-made 300 bps one and there were basically 3 options:
- no flow control at all (no buffering etc), RTS/CTS disabled/missing,
- XON/XOFF
Krzysztof Halasa wrote:
> "Tosoni" <[EMAIL PROTECTED]> writes:
> > As far as I know in the old times this was the *standard*
> way to use a modem
> > (per CCITT V24), and even nowadays many modems can handle
> this method for
> > transmit, to stay compatible with the standard.
>
> I think it
Krzysztof Halasa wrote:
Tosoni [EMAIL PROTECTED] writes:
As far as I know in the old times this was the *standard*
way to use a modem
(per CCITT V24), and even nowadays many modems can handle
this method for
transmit, to stay compatible with the standard.
I think it wasn't standard for
Tosoni [EMAIL PROTECTED] writes:
It has always been the standard for all modems.
Look, I've been using various modems for many years, starting with
self-made 300 bps one and there were basically 3 options:
- no flow control at all (no buffering etc), RTS/CTS disabled/missing,
- XON/XOFF flow
"Tosoni" <[EMAIL PROTECTED]> writes:
>> OTOH I wonder what does the device in question require WRT the
>> serial port and WRT RTS line in particular.
>> I know there are some half-duplex converters which drive RTS only
>> while sending and which require CTS to send.
>
> As far as I know in the
2007/3/8, Russell King <[EMAIL PROTECTED]>:
... which occurs /after/ userspace is up and running, when sysfs is
available. So putting it in sysfs is reasonable.
Is it right place for serial settings?
/sys/class/tty/ttySN/
How far is it reasonable to split termios settings to the attributes?
On Thu, Mar 08, 2007 at 06:32:29PM -0500, Robin Getz wrote:
> On Thu 8 Mar 2007 15:40, Russell King pondered:
> > On Thu, Mar 08, 2007 at 03:23:39PM -0500, Robin Getz wrote:
> > > Right - We both agree - And setting console=/dev/null in the bootargs
> > > still does not help.
> >
> > Ok, good.
> >
On Thu, Mar 08, 2007 at 06:32:29PM -0500, Robin Getz wrote:
On Thu 8 Mar 2007 15:40, Russell King pondered:
On Thu, Mar 08, 2007 at 03:23:39PM -0500, Robin Getz wrote:
Right - We both agree - And setting console=/dev/null in the bootargs
still does not help.
Ok, good.
When the
2007/3/8, Russell King [EMAIL PROTECTED]:
... which occurs /after/ userspace is up and running, when sysfs is
available. So putting it in sysfs is reasonable.
Is it right place for serial settings?
/sys/class/tty/ttySN/
How far is it reasonable to split termios settings to the attributes?
1)
Tosoni [EMAIL PROTECTED] writes:
OTOH I wonder what does the device in question require WRT the
serial port and WRT RTS line in particular.
I know there are some half-duplex converters which drive RTS only
while sending and which require CTS to send.
As far as I know in the old times this
On Thu 8 Mar 2007 15:40, Russell King pondered:
> On Thu, Mar 08, 2007 at 03:23:39PM -0500, Robin Getz wrote:
> > Right - We both agree - And setting console=/dev/null in the bootargs
> > still does not help.
>
> Ok, good.
>
> > When the kernel initializes the UART Port, it asserts RTS - which
> >
On Thu, Mar 08, 2007 at 03:23:39PM -0500, Robin Getz wrote:
> On Thu 8 Mar 2007 08:48, Russell King pondered:
> > On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
> > > That would let you change things are run time, but the problem is at
> > > boot time. A default setting needs to be
On Thu 8 Mar 2007 08:48, Russell King pondered:
> On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
> > That would let you change things are run time, but the problem is at
> > boot time. A default setting needs to be set, so when things initialize,
> > and proc does not exist yet, it is
Krzysztof Halasa wrote:
> OTOH I wonder what does the device in question require WRT the
> serial port and WRT RTS line in particular.
> I know there are some half-duplex converters which drive RTS only
> while sending and which require CTS to send.
As far as I know in the old times this was the
Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes:
> Unless you want two machines to monitor each other via serial console and
> each of them has only one serial port. It's not perfect, but it works well
> enough despite all claims to the contrary.
Sure, if you don't need "input" (only "console
2007/3/8, Russell King <[EMAIL PROTECTED]>:
On Thu, Mar 08, 2007 at 03:23:49PM +0100, Oleksiy Kebkal wrote:
> Ok. I understand now one of the sources of misunderstanding. I don't
> want to mix console and application serial port.
It's not a misunderstanding if you realise that email is threaded
On Thu, Mar 08, 2007 at 03:23:49PM +0100, Oleksiy Kebkal wrote:
> 2007/3/8, Russell King <[EMAIL PROTECTED]>:
> >On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
> >> On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
> >> > 2007/3/7, Robin Getz <[EMAIL PROTECTED]>:
> >> > > Right - so
2007/3/8, Russell King <[EMAIL PROTECTED]>:
On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
> On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
> > 2007/3/7, Robin Getz <[EMAIL PROTECTED]>:
> > > Right - so the question is where to manage the default state? I was
> > > thinking in
2007/3/8, Russell King <[EMAIL PROTECTED]>:
On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
> On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
> > 2007/3/7, Robin Getz <[EMAIL PROTECTED]>:
> > > Right - so the question is where to manage the default state? I was
> > > thinking in
On Thu, Mar 08, 2007 at 03:16:08PM +0100, Carl-Daniel Hailfinger wrote:
> Hi,
>
> On 08.03.2007 14:48, Russell King wrote:
> > As I've said already, having a console on the same port as your application
> > program is just asking for trouble. All bets are off - the kernel _will_
> > corrupt your
Hi,
On 08.03.2007 14:48, Russell King wrote:
> As I've said already, having a console on the same port as your application
> program is just asking for trouble. All bets are off - the kernel _will_
> corrupt your data stream in random places.
>
> Don't do it - it will _NEVER_ be reliable.
>
>
On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
> On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
> > 2007/3/7, Robin Getz <[EMAIL PROTECTED]>:
> > > Right - so the question is where to manage the default state? I was
> > > thinking in the resource might be a good idea, but there
On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
> 2007/3/7, Robin Getz <[EMAIL PROTECTED]>:
> > Right - so the question is where to manage the default state? I was
> > thinking in the resource might be a good idea, but there isn't really a
> > good place for it. (You could re-use some bits if
On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
2007/3/7, Robin Getz [EMAIL PROTECTED]:
Right - so the question is where to manage the default state? I was
thinking in the resource might be a good idea, but there isn't really a
good place for it. (You could re-use some bits if flags, but
On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
2007/3/7, Robin Getz [EMAIL PROTECTED]:
Right - so the question is where to manage the default state? I was
thinking in the resource might be a good idea, but there isn't really a
Hi,
On 08.03.2007 14:48, Russell King wrote:
As I've said already, having a console on the same port as your application
program is just asking for trouble. All bets are off - the kernel _will_
corrupt your data stream in random places.
Don't do it - it will _NEVER_ be reliable.
Never,
On Thu, Mar 08, 2007 at 03:16:08PM +0100, Carl-Daniel Hailfinger wrote:
Hi,
On 08.03.2007 14:48, Russell King wrote:
As I've said already, having a console on the same port as your application
program is just asking for trouble. All bets are off - the kernel _will_
corrupt your data
2007/3/8, Russell King [EMAIL PROTECTED]:
On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
2007/3/7, Robin Getz [EMAIL PROTECTED]:
Right - so the question is where to manage the default state? I was
thinking in the resource
2007/3/8, Russell King [EMAIL PROTECTED]:
On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
2007/3/7, Robin Getz [EMAIL PROTECTED]:
Right - so the question is where to manage the default state? I was
thinking in the resource
On Thu, Mar 08, 2007 at 03:23:49PM +0100, Oleksiy Kebkal wrote:
2007/3/8, Russell King [EMAIL PROTECTED]:
On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
2007/3/7, Robin Getz [EMAIL PROTECTED]:
Right - so the question is
2007/3/8, Russell King [EMAIL PROTECTED]:
On Thu, Mar 08, 2007 at 03:23:49PM +0100, Oleksiy Kebkal wrote:
Ok. I understand now one of the sources of misunderstanding. I don't
want to mix console and application serial port.
It's not a misunderstanding if you realise that email is threaded and
Carl-Daniel Hailfinger [EMAIL PROTECTED] writes:
Unless you want two machines to monitor each other via serial console and
each of them has only one serial port. It's not perfect, but it works well
enough despite all claims to the contrary.
Sure, if you don't need input (only console logger
Krzysztof Halasa wrote:
OTOH I wonder what does the device in question require WRT the
serial port and WRT RTS line in particular.
I know there are some half-duplex converters which drive RTS only
while sending and which require CTS to send.
As far as I know in the old times this was the
On Thu 8 Mar 2007 08:48, Russell King pondered:
On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
That would let you change things are run time, but the problem is at
boot time. A default setting needs to be set, so when things initialize,
and proc does not exist yet, it is still
On Thu, Mar 08, 2007 at 03:23:39PM -0500, Robin Getz wrote:
On Thu 8 Mar 2007 08:48, Russell King pondered:
On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
That would let you change things are run time, but the problem is at
boot time. A default setting needs to be set, so
On Thu 8 Mar 2007 15:40, Russell King pondered:
On Thu, Mar 08, 2007 at 03:23:39PM -0500, Robin Getz wrote:
Right - We both agree - And setting console=/dev/null in the bootargs
still does not help.
Ok, good.
When the kernel initializes the UART Port, it asserts RTS - which
confuses
2007/3/7, Robin Getz <[EMAIL PROTECTED]>:
Right - so the question is where to manage the default state? I was thinking
in the resource might be a good idea, but there isn't really a good place for
it. (You could re-use some bits if flags, but I think that would not be a
good idea).
On 3/7/07, Krzysztof Halasa <[EMAIL PROTECTED]> wrote:
"Oleksiy Kebkal" <[EMAIL PROTECTED]> writes:
> May be it would be good idea to develop some tty control driver which
> provides a
> possibility to change default setting of the drivers?
If there is a real need for it (such as a real
On Wed 7 Mar 2007 07:46, Krzysztof Halasa pondered:
> Robin Getz <[EMAIL PROTECTED]> writes:
> > It is useful on (broken) legacy serial equipment, where RTS should be
> > completely under the applications control.
> >
> > Glitches on RTS aren't acceptable, and confuse some devices.
>
> Does that
2007/3/7, Krzysztof Halasa <[EMAIL PROTECTED]>:
Robin Getz <[EMAIL PROTECTED]> writes:
> It is useful on (broken) legacy serial equipment, where RTS should be
> completely under the applications control.
>
> Glitches on RTS aren't acceptable, and confuse some devices.
Does that mean you can't
"Oleksiy Kebkal" <[EMAIL PROTECTED]> writes:
> May be it would be good idea to develop some tty control driver which
> provides a
> possibility to change default setting of the drivers?
If there is a real need for it (such as a real existing device)...
then sure (it wouldn't be a "default
> it's used for
> various purposes such as providing +12V to the device (and two pins
> can supply more power than one - sure, it isn't the best idea).
I understand - the request wasn't to change the default operation - just add a
method of controlling things, so those minority of people who
"Oleksiy Kebkal" <[EMAIL PROTECTED]> writes:
> The name of the option is not CCTS, but CRTSCTS, isn't it? So, you may
> not only want to pause own transmission when CTS is inactive, but to
> control the transmission flow from the remote side. Why should RTS be
> active when the port is open even
Robin Getz <[EMAIL PROTECTED]> writes:
> It is useful on (broken) legacy serial equipment, where RTS should be
> completely under the applications control.
>
> Glitches on RTS aren't acceptable, and confuse some devices.
Does that mean you can't use TIOCMSET, TIOCM_RTS etc?
> I understand -
Robin Getz [EMAIL PROTECTED] writes:
It is useful on (broken) legacy serial equipment, where RTS should be
completely under the applications control.
Glitches on RTS aren't acceptable, and confuse some devices.
Does that mean you can't use TIOCMSET, TIOCM_RTS etc?
I understand - the
Oleksiy Kebkal [EMAIL PROTECTED] writes:
The name of the option is not CCTS, but CRTSCTS, isn't it? So, you may
not only want to pause own transmission when CTS is inactive, but to
control the transmission flow from the remote side. Why should RTS be
active when the port is open even without
it's used for
various purposes such as providing +12V to the device (and two pins
can supply more power than one - sure, it isn't the best idea).
I understand - the request wasn't to change the default operation - just add a
method of controlling things, so those minority of people who
Oleksiy Kebkal [EMAIL PROTECTED] writes:
May be it would be good idea to develop some tty control driver which
provides a
possibility to change default setting of the drivers?
If there is a real need for it (such as a real existing device)...
then sure (it wouldn't be a default setting
2007/3/7, Krzysztof Halasa [EMAIL PROTECTED]:
Robin Getz [EMAIL PROTECTED] writes:
It is useful on (broken) legacy serial equipment, where RTS should be
completely under the applications control.
Glitches on RTS aren't acceptable, and confuse some devices.
Does that mean you can't use
On Wed 7 Mar 2007 07:46, Krzysztof Halasa pondered:
Robin Getz [EMAIL PROTECTED] writes:
It is useful on (broken) legacy serial equipment, where RTS should be
completely under the applications control.
Glitches on RTS aren't acceptable, and confuse some devices.
Does that mean you can't
On 3/7/07, Krzysztof Halasa [EMAIL PROTECTED] wrote:
Oleksiy Kebkal [EMAIL PROTECTED] writes:
May be it would be good idea to develop some tty control driver which
provides a
possibility to change default setting of the drivers?
If there is a real need for it (such as a real existing
2007/3/7, Robin Getz [EMAIL PROTECTED]:
Right - so the question is where to manage the default state? I was thinking
in the resource might be a good idea, but there isn't really a good place for
it. (You could re-use some bits if flags, but I think that would not be a
good idea).
> shouldnt TIOCM_RTS be passed down only when the 'r' is appended to the
> boot cmdline ?
How would it be useful?
CRTSCTS is for CTS only (i.e., the transmission is paused when CTS is
inactive), not for RTS. DTR and RTS should be active when the port is
open even without CRTSCTS (= without
On Tue 6 Mar 2007 15:40, Krzysztof Halasa pondered:
> "Mike Frysinger" <[EMAIL PROTECTED]> writes:
> > /*
> > * Setup the RTS and DTR signals once the
> > * port is open and ready to respond.
> > */
> > if (info->tty->termios->c_cflag
"Mike Frysinger" <[EMAIL PROTECTED]> writes:
>/*
> * Setup the RTS and DTR signals once the
> * port is open and ready to respond.
> */
>if (info->tty->termios->c_cflag & CBAUD)
>uart_set_mctrl(port, TIOCM_RTS |
Mike Frysinger [EMAIL PROTECTED] writes:
/*
* Setup the RTS and DTR signals once the
* port is open and ready to respond.
*/
if (info-tty-termios-c_cflag CBAUD)
uart_set_mctrl(port, TIOCM_RTS | TIOCM_DTR);
...
On Tue 6 Mar 2007 15:40, Krzysztof Halasa pondered:
Mike Frysinger [EMAIL PROTECTED] writes:
/*
* Setup the RTS and DTR signals once the
* port is open and ready to respond.
*/
if (info-tty-termios-c_cflag CBAUD)
shouldnt TIOCM_RTS be passed down only when the 'r' is appended to the
boot cmdline ?
How would it be useful?
CRTSCTS is for CTS only (i.e., the transmission is paused when CTS is
inactive), not for RTS. DTR and RTS should be active when the port is
open even without CRTSCTS (= without
On 3/5/07, Russell King <[EMAIL PROTECTED]> wrote:
On Mon, Mar 05, 2007 at 12:09:20PM -0500, Mike Frysinger wrote:
> On 3/4/07, Russell King <[EMAIL PROTECTED]> wrote:
> >On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
> >> the console= bootcmd allows for controlling of the
On Mon, Mar 05, 2007 at 12:09:20PM -0500, Mike Frysinger wrote:
> On 3/4/07, Russell King <[EMAIL PROTECTED]> wrote:
> >On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
> >> the console= bootcmd allows for controlling of the initial state of
> >> flow control by adding/omitting the
On 3/4/07, Russell King <[EMAIL PROTECTED]> wrote:
On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
> the console= bootcmd allows for controlling of the initial state of
> flow control by adding/omitting the 'r' suffix ...
The console command *only* sets the state for the
On Sun, Mar 04, 2007 at 03:42:25PM -0500, Robin Getz wrote:
> On Sun 4 Mar 2007 14:46, Russell King pondered:
> > On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
> > > the console= bootcmd allows for controlling of the initial state of
> > > flow control by adding/omitting the
On 4 Mar, 21:50, Robin Getz <[EMAIL PROTECTED]> wrote:
On Sun 4 Mar 2007 14:46, Russell King pondered:
> The console command *only* sets the state for the kernel's use of one
> serial port. It does not affect any other serial port, so tying
> random RTS behaviours into that command line
On 4 Mar, 21:50, Robin Getz [EMAIL PROTECTED] wrote:
On Sun 4 Mar 2007 14:46, Russell King pondered:
The console command *only* sets the state for the kernel's use of one
serial port. It does not affect any other serial port, so tying
random RTS behaviours into that command line option is
On Sun, Mar 04, 2007 at 03:42:25PM -0500, Robin Getz wrote:
On Sun 4 Mar 2007 14:46, Russell King pondered:
On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
the console= bootcmd allows for controlling of the initial state of
flow control by adding/omitting the 'r' suffix
On 3/4/07, Russell King [EMAIL PROTECTED] wrote:
On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
the console= bootcmd allows for controlling of the initial state of
flow control by adding/omitting the 'r' suffix ...
The console command *only* sets the state for the kernel's
On Mon, Mar 05, 2007 at 12:09:20PM -0500, Mike Frysinger wrote:
On 3/4/07, Russell King [EMAIL PROTECTED] wrote:
On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
the console= bootcmd allows for controlling of the initial state of
flow control by adding/omitting the 'r' suffix
On 3/5/07, Russell King [EMAIL PROTECTED] wrote:
On Mon, Mar 05, 2007 at 12:09:20PM -0500, Mike Frysinger wrote:
On 3/4/07, Russell King [EMAIL PROTECTED] wrote:
On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
the console= bootcmd allows for controlling of the initial state
On Sun 4 Mar 2007 14:46, Russell King pondered:
> On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
> > the console= bootcmd allows for controlling of the initial state of
> > flow control by adding/omitting the 'r' suffix ...
>
> The console command *only* sets the state for the
On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
> the console= bootcmd allows for controlling of the initial state of
> flow control by adding/omitting the 'r' suffix ...
The console command *only* sets the state for the kernel's use of one
serial port. It does not affect any
On Thu 1 Mar 2007 19:03, Mike Frysinger pondered:
> the console= bootcmd allows for controlling of the initial state of
> flow control by adding/omitting the 'r' suffix ... however, the
> uart_startup() function in serial_core.c always calls down into the
> serial driver with TIOCM_RTS:
> static
On Thu 1 Mar 2007 19:03, Mike Frysinger pondered:
the console= bootcmd allows for controlling of the initial state of
flow control by adding/omitting the 'r' suffix ... however, the
uart_startup() function in serial_core.c always calls down into the
serial driver with TIOCM_RTS:
static int
On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
the console= bootcmd allows for controlling of the initial state of
flow control by adding/omitting the 'r' suffix ...
The console command *only* sets the state for the kernel's use of one
serial port. It does not affect any other
On Sun 4 Mar 2007 14:46, Russell King pondered:
On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
the console= bootcmd allows for controlling of the initial state of
flow control by adding/omitting the 'r' suffix ...
The console command *only* sets the state for the
the console= bootcmd allows for controlling of the initial state of
flow control by adding/omitting the 'r' suffix ... however, the
uart_startup() function in serial_core.c always calls down into the
serial driver with TIOCM_RTS:
static int uart_startup(...) {
...
/*
*
the console= bootcmd allows for controlling of the initial state of
flow control by adding/omitting the 'r' suffix ... however, the
uart_startup() function in serial_core.c always calls down into the
serial driver with TIOCM_RTS:
static int uart_startup(...) {
...
/*
*
76 matches
Mail list logo
