[ECOS] cyg_io_write & printf

[ECOS] cyg_io_write & printf

[Wolfram Kattanek]

Hello,

I'm playing a little bit with the serial driver functions and came across some
weird phenomena. Can anyone shed some light on the following questions?

My platform is ARM AEB-1 revision C with one serial port. I'm working with CVS
sources on a linux host. I configured eCos in the following way: default aeb
template; enabled CYGDBG_HAL_DIAG_DISABLE_GDB_PROTOCOL, CYGPKG_IO_SERIAL_DEVICES
and CYGPKG_IO_SERIAL_TTY_TTY1; changed CYGHWR_HAL_ARM_AEB_REVISION to "C".

My test program is:

#include <cyg/io/io.h> 
#include <cyg/io/serialio.h> 
#include <cyg/error/codes.h> 
#include <stdio.h> 

void cyg_user_start(void) 
{ 
  cyg_uint32 length; 
  Cyg_ErrNo error; 
  char test_msg1[]="This is a test message!\n";
  cyg_io_handle_t serial_port_handle;

  error = cyg_io_lookup("/dev/ser1", &serial_port_handle);
  if (error == ENOERR) {
    length = strlen(&test_msg1[0]); 
    cyg_io_write(serial_port_handle, &test_msg1[0], &length);
  }
  printf("Hello eCos world!\n");
} 

I compiled and linked it in the usual (eCos) way and downloaded it to
the AEB board using a terminal program (minicom; comm parameters:
38400 8N1 no Hardware Flow Control and no Software Flow Control).
Then I started the downloaded program using the AEB monitor program
and watched the output inside minicom.

In the above configuration of the example program I got the following
output:

ARM Evaluation Board Boot Monitor 0.01 (19 APR 1998)
Press ENTER within 2 seconds to stop autoboot
Boot: download c000
Ready to download. Use 'transmit' option on terminal emulator to download file.
Loaded file simple_io_sample.ram.bin at address 0000c000, size = 48028
Boot: go

AEB-1 eCos
Hello eCos world!
This is a test message!


The interesting thing about that output is that the cyg_io_write and printf
statements seem to output their messages in the "wrong" order!?

More interestingly, if I change cyg_user_start to main then the output
becomes really weird:

AEB-1 eCos
This isHaetest lessalo! eCos world!


Both outputs seem to be mixed! The output changes a little bit if I use tty1
instead of ser1 or \r\n instead of \n but the mixing won't stop.

So here are my questions:

- Why is the behavior so different when using main or cyg_user_start?
- Is it possible to use both cyg_io_write and printf when only one physical
  serial port is available?
- Why the statement order does not reflect the output order in the given
  example?
- BTW: Is there a config option to turn off the output "AEB-1 eCos"?

Any comments are appreciated!

Thanks,
Wolfram
--
Wolfram 'L.A.' Kattanek     Institut fuer Mikroelektronik- und
Email:       LA@imms.de     Mechatronik-Systeme (IMMS) gGmbH     
Tel: +49 3677 / 6783-55     Langewiesener Str. 22
Fax: +49 3677 / 6783-38     98693 Ilmenau / Germany

-------------------------------------------------
This mail sent through IMP: imp.imms.de

Re: [ECOS] cyg_io_write & printf

[Gary Thomas]

Wolfram Kattanek wrote:

> Hello,
>
> I'm playing a little bit with the serial driver functions and came across some
> weird phenomena. Can anyone shed some light on the following questions?
>
> My platform is ARM AEB-1 revision C with one serial port. I'm working with CVS
> sources on a linux host. I configured eCos in the following way: default aeb
> template; enabled CYGDBG_HAL_DIAG_DISABLE_GDB_PROTOCOL, CYGPKG_IO_SERIAL_DEVICES
> and CYGPKG_IO_SERIAL_TTY_TTY1; changed CYGHWR_HAL_ARM_AEB_REVISION to "C".
>
> My test program is:
>
> #include <cyg/io/io.h>
> #include <cyg/io/serialio.h>
> #include <cyg/error/codes.h>
> #include <stdio.h>
>
> void cyg_user_start(void)
> {
>   cyg_uint32 length;
>   Cyg_ErrNo error;
>   char test_msg1[]="This is a test message!\n";
>   cyg_io_handle_t serial_port_handle;
>
>   error = cyg_io_lookup("/dev/ser1", &serial_port_handle);
>   if (error == ENOERR) {
>     length = strlen(&test_msg1[0]);
>     cyg_io_write(serial_port_handle, &test_msg1[0], &length);
>   }
>   printf("Hello eCos world!\n");
> }
>
> I compiled and linked it in the usual (eCos) way and downloaded it to
> the AEB board using a terminal program (minicom; comm parameters:
> 38400 8N1 no Hardware Flow Control and no Software Flow Control).
> Then I started the downloaded program using the AEB monitor program
> and watched the output inside minicom.
>
> In the above configuration of the example program I got the following
> output:
>
> ARM Evaluation Board Boot Monitor 0.01 (19 APR 1998)
> Press ENTER within 2 seconds to stop autoboot
> Boot: download c000
> Ready to download. Use 'transmit' option on terminal emulator to download file.
> Loaded file simple_io_sample.ram.bin at address 0000c000, size = 48028
> Boot: go
>
> AEB-1 eCos
> Hello eCos world!
> This is a test message!
>
> The interesting thing about that output is that the cyg_io_write and printf
> statements seem to output their messages in the "wrong" order!?
>
> More interestingly, if I change cyg_user_start to main then the output
> becomes really weird:
>
> AEB-1 eCos
> This isHaetest lessalo! eCos world!
>
> Both outputs seem to be mixed! The output changes a little bit if I use tty1
> instead of ser1 or \r\n instead of \n but the mixing won't stop.
>

This is happening because 'printf()' uses the diagnostic routines, which use
polling
The 'cyg_io_write()' uses interrupts to drive the port.  Thus, once the 'printf()'
starts, all characters will be displayed at once.  The 'cyg_io_write()' relies on
interrupts
to drive the process.  Getting mixed output is certainly to be expected.

>
> So here are my questions:
>
> - Why is the behavior so different when using main or cyg_user_start?

It depends on when interrupts get enabled.

>
> - Is it possible to use both cyg_io_write and printf when only one physical
>   serial port is available?

Yes, there is an option to get diagnostic output to basically go through 'cyg_io'

>
> - Why the statement order does not reflect the output order in the given
>   example?

Toss of a coin.

>
> - BTW: Is there a config option to turn off the output "AEB-1 eCos"?
>

I'm pretty sure that this has been removed.  Are you using a "release" version
or anonymous CVS?


>
> Any comments are appreciated!
>
> Thanks,
> Wolfram
> --
> Wolfram 'L.A.' Kattanek     Institut fuer Mikroelektronik- und
> Email:       LA@imms.de     Mechatronik-Systeme (IMMS) gGmbH
> Tel: +49 3677 / 6783-55     Langewiesener Str. 22
> Fax: +49 3677 / 6783-38     98693 Ilmenau / Germany
>
> -------------------------------------------------
> This mail sent through IMP: imp.imms.de

Re: [ECOS] cyg_io_write & printf

[Wolfram Kattanek]

Gary Thomas <gthomas@cambridge.redhat.com>:

> > More interestingly, if I change cyg_user_start to main then the output
> > becomes really weird:
> >
> > AEB-1 eCos
> > This isHaetest lessalo! eCos world!
> >
> > Both outputs seem to be mixed! The output changes a little bit if I use tty1
> > instead of ser1 or \r\n instead of \n but the mixing won't stop.
> >
> 
> This is happening because 'printf()' uses the diagnostic routines, which use
> polling
> The 'cyg_io_write()' uses interrupts to drive the port.  Thus, once the 'printf()'
> starts, all characters will be displayed at once.  The 'cyg_io_write()' relies on
> interrupts
> to drive the process.  Getting mixed output is certainly to be expected.
> 
> >
> > So here are my questions:
> >
> > - Why is the behavior so different when using main or cyg_user_start?
> 
> It depends on when interrupts get enabled.

But when do they get enabled when using main() or cyg_user_start() without
creating some user threads?

When I put the example code inside a user thread (created in cyg_user_start)
everything seems to work fine. Does that mean that (only) the scheduler enables
interrupts? Can the scheduler also be started from inside main() (via creating
a user thread)? When trying to do so I get the following assertion failure:

ASSERT FAIL: <2>intr.cxx   [571] static void Cyg_Interrupt::enable_interrupts()

Am I missing something fundamental about eCos?

> > - Is it possible to use both cyg_io_write and printf when only one physical
> >   serial port is available?
> 
> Yes, there is an option to get diagnostic output to basically go through 'cyg_io'

But this doesn't solve the above problems concerning mix of interrupt driven and
polled output or am I wrong about that?

> > - BTW: Is there a config option to turn off the output "AEB-1 eCos"?
> >
> 
> I'm pretty sure that this has been removed.  Are you using a "release" version
> or anonymous CVS?

I'm using an anonymous CVS snapshot from Jan 22 2001. However the "AEB-1 eCos"
string is coded inside the file packages/hal/arm/aeb/current/src/hal_diag.c
which is dated from Jul 4 2000.

Wolfram
--
Wolfram 'L.A.' Kattanek     Institut fuer Mikroelektronik- und
Email:       LA@imms.de     Mechatronik-Systeme (IMMS) gGmbH     
Tel: +49 3677 / 6783-55     Langewiesener Str. 22
Fax: +49 3677 / 6783-38     98693 Ilmenau / Germany

-------------------------------------------------
This mail sent through IMP: imp.imms.de

Re: [ECOS] cyg_io_write & printf

[Jonathan Larmour]

Wolfram Kattanek wrote:
> 
> Gary Thomas <gthomas@cambridge.redhat.com>:
> 
> > > So here are my questions:
> > >
> > > - Why is the behavior so different when using main or cyg_user_start?
> >
> > It depends on when interrupts get enabled.
> 
> But when do they get enabled when using main() or cyg_user_start() without
> creating some user threads?

main() _is_ a thread. Or rather a thread is created solely to call main().
cyg_user_start() is not a thread, and before the scheduler is started,
interrupts are disabled.
 
> When I put the example code inside a user thread (created in cyg_user_start)
> everything seems to work fine. Does that mean that (only) the scheduler enables
> interrupts?

To all intents and purposes yes. You can arrange otherwise by directly
enabling interrupts, but you may have to deal with handling e.g. clock
interrupts.

> Can the scheduler also be started from inside main() (via creating
> a user thread)? When trying to do so I get the following assertion failure:
> 
> ASSERT FAIL: <2>intr.cxx   [571] static void Cyg_Interrupt::enable_interrupts()
> 
> Am I missing something fundamental about eCos?

Trying to start the scheduler from within main() is pointless as it is
alraedy started.

> > > - Is it possible to use both cyg_io_write and printf when only one physical
> > >   serial port is available?
> >
> > Yes, there is an option to get diagnostic output to basically go through 'cyg_io'
> 
> But this doesn't solve the above problems concerning mix of interrupt driven and
> polled output or am I wrong about that?

The point really is don't use printf or cyg_io_write from cyg_user_start().
Create a thread (or use main() ) and do it from there.

You can make printf() stop using the diagnostic output, and instead use the
interrupt-driven serial driver by setting CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE
to /dev/tty0 from /dev/ttydiag in the configuration tool (or CDL).
 
Another thing that explains the behaviour you were getting before when the
output was done in the wrong order (but not mixed) is that when you drop
off the end of cyg_user_start(), the scheduler is then started. That's why
the polled output works, immediately, but the cyg_io_write() had to wait
until interrupts were enabled, which happens when the scheduler is started.

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

Re: [ECOS] cyg_io_write & printf

[Wolfram Kattanek]

Jonathan Larmour <jlarmour@redhat.com>:

> Wolfram Kattanek wrote:
> > 
> > Gary Thomas <gthomas@cambridge.redhat.com>:
> > 
> > > > - Is it possible to use both cyg_io_write and printf when only one physical
> > > >   serial port is available?
> > >
> > > Yes, there is an option to get diagnostic output to basically go through 'cyg_io'
> > 
> > But this doesn't solve the above problems concerning mix of interrupt driven and
> > polled output or am I wrong about that?
> 
> The point really is don't use printf or cyg_io_write from cyg_user_start().
> Create a thread (or use main() ) and do it from there.
> 
> You can make printf() stop using the diagnostic output, and instead use the
> interrupt-driven serial driver by setting CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE
> to /dev/tty0 from /dev/ttydiag in the configuration tool (or CDL).
>  
> Another thing that explains the behaviour you were getting before when the
> output was done in the wrong order (but not mixed) is that when you drop
> off the end of cyg_user_start(), the scheduler is then started. That's why
> the polled output works, immediately, but the cyg_io_write() had to wait
> until interrupts were enabled, which happens when the scheduler is started.

Thank you for your explanation! I've changed CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE
(in my case to /dev/tty1) and everything works fine now.

Wolfram
--
Wolfram 'L.A.' Kattanek     Institut fuer Mikroelektronik- und
Email:       LA@imms.de     Mechatronik-Systeme (IMMS) gGmbH     
Tel: +49 3677 / 6783-55     Langewiesener Str. 22
Fax: +49 3677 / 6783-38     98693 Ilmenau / Germany

-------------------------------------------------
This mail sent through IMP: imp.imms.de