Re: [ECOS] gets() and task scheduling stopped

[Jonathan Larmour <jlarmour at redhat dot com>]

Sam Sortais wrote:
> 
> >Sam Sortais wrote:
> >[snip]
> >> For what I understand with gdb it seems to
> >> be stuck at the bottom of this
> >> sequence of calls gets() -> refill_?() ->
> >> read() -> readwrite() ->
> >> dev_fo_read() -> cyg_io_read() -> tty_read() ->cyg_io_read() ->
> >> serial_read() -> haldiag_getc() -> HAL_DIAG_READ->?
> >> The scheduler is locked at many levels in
> >> the previous calls. I was also
> >> looking at a loop in tty_read() which is
> >> done after a lock? but I do not
> >> catch all the details of this low level
> >> code.

Looking at these functions I'm afraid I still haven't noticed where the
scheduler gets locked. There are many places where a mutex gets locked, but
not the entire scheduler.


> > You need to use an IO driver to get proper
> > multithreaded behavior. The
> > HAL keyboard driver is operating in polled
> > mode only, causing the behavior you observe.
> 
> > The only IO device keyboard driver I see is > for the iPAQ. You need to
> > write something similar for your platform.
> 
> The problem is that I load my application via
> Redboot, so OK to write an IO driver for PC
> keyboard now, but then how would it work when
> the channel is the serial line or tcp/ip via
> Redboot ?

It wouldn't work as you wouldn't use it! You would open a different stream
associated with an interrupt driven device driver, or a socket.

> This is what I use all the time and it is much
> more convenient than to go type on my target
> keyboard. In the futur my target will have no
> keyboard so how will I do a gets() at this
> time ?

By opening /dev/tty0 or similar which would point at an interrupt driven
serial driver; or by opening a socket.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine