public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
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

  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).