Re: cyg_io_read blocking

[Gary Thomas <gary at mlbassoc dot com>]

On Fri, 2005-04-08 at 13:33 +0100, Bart Veer wrote:
> >>>>> "Raghu" == Raghu  <raghu_dk@yahoo.com> writes:
> 
>     Raghu> Sample code of "cyg_io_read", "cyg_io_write" that blocks
>     Raghu> when a thread is spawned, but if called from a functions
>     Raghu> dosent.
> 
>     Raghu> void cyg_user_start( void )
>     Raghu> {
>     Raghu>     cyg_thread_create( 4, serial_thread_handler, ...
>     Raghu>                      );
>     Raghu>     cyg_thread_resume( handle );
>     Raghu> }
> 
>     Raghu> void serial_thread_handler( cyg_addrword_t data )
>     Raghu> {
>     Raghu>      cyg_io_lookup( &hdl );
>     Raghu>      for( ; ; ){
>     Raghu>           cyg_io_read( hdl, &ch, &len );
>     Raghu>           cyg_io_write( hdl, &ch, &len );
>     Raghu>      }
>     Raghu> }
> 
>     Raghu> But if "serial_thread_handler" is directly called from
>     Raghu> "cyg_user_start" as a function call, there is no
>     Raghu> issues.
> 
> cyg_user_start() is run during system startup, before the scheduler is
> started or interrupts are enabled. There is no way for the system to
> block at this time. Blocking involves transferring control to another
> thread, possibly the idle thread, and that cannot happen if the
> scheduler has not yet started.
> 
> A typical cyg_user_start() performs little if any I/O. Instead it just
> performs operations that affect the cpu and memory, e.g. starting one
> or more threads. Sometimes I/O at this stage cannot be avoided, but it
> will have to be non-blocking I/O in a polling loop.

Two more things to mention:

* RedBoot uses cyg_user_start, as do most of our test programs, to
have finer grain control over the actual execution environment.  RedBoot
runs without a kernel, thus no threads, scheduler, etc.  Using 
cyg_user_start simply minimizes the setup and makes the independence
from the scheduler clear.

* If you want to do threaded operations, you'll need to use a serial
device driver that supports this - not /dev/ttydiag which does not.
It's not clear what driver/device your I/O channel is connected to,
but it needs to be a "standard serial" driver, e.g. /dev/ser0

Finally, this thread really should be on ecos-discuss since it's
an operational issue, not a development (of eCos) one.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------