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.