This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 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?
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'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;

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]