RE: [ECOS] GDB and console (libc_stdio) on same serial port

["George Sosnowski" <george at stratalight dot com>]

> -----Original Message-----
> From: Jonathan Larmour [mailto:jifl@eCosCentric.com]
> Sent: Thursday, February 06, 2003 2:27 PM
> To: George Sosnowski
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] GDB and console (libc_stdio) on same serial port
> 
> George Sosnowski wrote:
> > I'm running on an 860T where there's one serial port available which
is
> > connected to SMC1.
> >
> > Is it possible, through some configuration, to have an ecos ram
> > application image which has gdb and a console (libc_stdio used as a
> > shell with non-blocking i/o /dev/tty0) on a single serial port?
               ^^^^^^^^^^^^
NOTE: I got my blocking and non-blocking mixed up initially when I wrote
this email. Therefore, I want my shell task to block until input is
gotten from the serial driver asynchronously via interrupt.

> 
> Well you can leave libc to use the default "/dev/ttydiag" device which
> means the output will be passed to GDB. This is the default anyway.
> 
> > I understand that in such a situation when gdb takes over (sees a
ctrl-c
> > or a $) the i/o to the shell would be in a polling (blocking) mode.
It's
> > not terribly important to me if the gdb stubs are from redboot or
within
> > the ecos ram application. Whatever works would be fine. Ideally I
have
> > redboot load an ecos application ram image automatically from flash
and
> > run it, and after the ecos ram application is running sometimes I'd
like
> > to be able to connect to it via gdb serially. However, by default
I'd
> > like to be able to interact with the ecos ram application through
its
> > console shell non-blockingly.
> 
> Generally, the principle is that a channel is used for GDB or an
> application since you can't be connected through GDB and talking to an
> application at the same time.

I don't mind not being able to use the shell while gdb is active. I'm
fine with a redboot type behavior of one or the other, but not both at
the same time.

> 
> > I've tried including the gdb stubs in the ecos ram application, but
it
> > seems when I run the ecos ram application that gdb is already active
in
> > this case because I get some $...... output on the serial port in
> > response to any serial input. Ideally I'd like to get the behavior
of
> > redboot where gdb is initially inactive and the redboot shell is
active.
> > I've also tried to inherit the serial port from redboot (as
ttydiag),
> > but this seems to give blocking i/o to the ecos ram application
console
> > shell when doing a getchar().
> 
> Indeed.
> 
> For what you'd want you'd need to make some tweaks to eCos. I would
> suggest the way to do this is decide how you want to recognise a
switch to
> GDB mode (ctrl-c, $, or possibly even some user command you give your
> application) and when you want to switch do:
> 
> cyg_hal_user_break( (CYG_ADDRWORD *)hal_saved_interrupt_state );
> 
> You'll have to have defined these first:
> 
> #include <cyg/hal/hal_arch.h>
> #include <cyg/hal/hal_misc.h>
> extern struct Hal_SavedRegisters *hal_saved_interrupt_state;

I tried doing this, but initially gdb is spoken (i.e., $.....) on the
serial port. Is there a configuration option to disable gdb from the
serial port until I do the cyg_hal_user_break()? Or do I need to comment
out something from cyg_start? I'm using a configuration where the GDB
stubs are being included in the application.

> 
> Jifl
> --
> eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot
experts
> --[ "You can complain because roses have thorns, or you ]--
> --[  can rejoice because thorns have roses." -Lincoln   ]--
Opinions==mine


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss