From: Gary Thomas <gary@mlbassoc.com>
To: Andre-John Mas <ajmas@sympatico.ca>
Cc: Jonathan Larmour <jifl@eCosCentric.com>,
ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Termios and waiting for character input
Date: Fri, 25 Aug 2006 16:16:00 -0000 [thread overview]
Message-ID: <44EF2242.8030201@mlbassoc.com> (raw)
In-Reply-To: <20060825161300.KZQO24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca>
Andre-John Mas wrote:
> Where do I change the VMIN value? I'll change the value to see
> if this helps.
>
> BTW I had worked around the issue by simply doing a loop until
> the input value was not 0x0. Not very elegant when CPU cycles
> matter. I also made the same observation as Gary that the code
> worked on other systems. I had tested the same code on MacOS X.
It's just another parameter to the termios structure. Simply
add this line:
term = termsave; /* termsave contains old termios */
term.c_lflag &= ~ECHO; /* turn off echo if it's set */
term.c_lflag &= ~ECHOE; /* turn off echoe if it's set */
term.c_lflag &= ~ICANON; /* turn off echoe if it's set */
term.c_cc[VMIN] = 1;
> Andre
>
> Jonathan Larmour wrote:
>> Gary Thomas wrote:
>>> Jonathan Larmour wrote:
>>>> Gary Thomas wrote:
>>>>> Jonathan Larmour wrote:
>>>>>> Non-canonical mode processing was only implemented to support
>>>>>> VMIN=0,TIME=0. Support for VMIN>0 is rudimentary and I wouldn't
>>>>>> trust it. But VMIN defaults to 0, and that sample code posted
>>>>>> doesn't attempt to set it to anything else.
>>>>>>
>>>>>> I imagine it defaults to something else on Linux, hence the
>>>>>> difference in behaviour. <fx: goes and checks> Aha, in fact it
>>>>>> defaults to 6. The POSIX standard does not set any requirements for
>>>>>> the default value, so eCos is fine on this count.
>>>>> Thanks for looking into this.
>>>>>
>>>>> Perhaps we should make the default values for VMIN/VMAX configurable,
>>>>> possibly with settings that match other systems?
>>>> Maybe so if I had more confidence it worked! If Andre-John (or
>>>> yourself) can play around with VMIN>0 and don't find any problems,
>>>> then we could change the default for VMIN. NB there is no VMAX, but if
>>>> you meant TIME, then TIME>0 is definitely unsupported in the current
>>>> code.
>>> It does work correctly (or at least the same as Linux) when VMIN=1.
>>> If I set VMIN=6, then I have to type 6 characters before the first one
>>> is seen.
>>> Perhaps that's where a setting of TIME>0 would matter...
>> Yes indeed, that's the correct behaviour for TIME=0. So maybe it does work,
>> and we could set default VMIN to 1.
>>
>>> At least we could have a way to default the value of VMIN and document
>>> the fact that TIME>0 is not implemented (if not already in the docs)
>> Since VMIN can be set in a well-known and standard way at run-time, I'm not
>> sure there's much value in a configuration option for the default.
>>
>> Termios is unfortunately undocumented. This was in the days when making doc
>> edits happen was like pulling teeth. And it became one of those things that
>> just never happened.
>>
>> Jifl
>>
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
next prev parent reply other threads:[~2006-08-25 16:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-25 16:13 Andre-John Mas
2006-08-25 16:16 ` Gary Thomas [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-08-23 23:14 Andre-John Mas
2006-08-24 23:24 ` Gary Thomas
2006-08-25 0:01 ` Jonathan Larmour
2006-08-25 11:58 ` Gary Thomas
2006-08-25 12:05 ` Jonathan Larmour
2006-08-25 12:23 ` Gary Thomas
2006-08-25 12:59 ` Jonathan Larmour
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44EF2242.8030201@mlbassoc.com \
--to=gary@mlbassoc.com \
--cc=ajmas@sympatico.ca \
--cc=ecos-discuss@ecos.sourceware.org \
--cc=jifl@eCosCentric.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).