Robert, as _I_ understand/understood
eCos offers 1) a non-interrupt driven diagnostic output on UART, it's a
wellknow diag_printf() and diag_*() routings. I look on it as on atomic
hal_diag_led() :-), it can be placed even in ISRs. It uses a polled
mode. It is a very useful thing on a debug stage. By defualt, it is
serial_2 for your HAL. Every diag_printf() in your program used it.
Once again, by default it is polled raw output and blocking input.
2) the interrup-driven serial drivers: 1st kind of them is a raw serial
driver, 2nd kind is a tty-like serial driver (a bit overhead let us to
have an ability to edit the entered lines), and 3rd -- the termios-like
serial drivers (there is more overhead there, but it is a portable way
to manage the terminals);
I can assume that your needs are to get the raw serial driver on the
serial_0 ("/dev/ser0"). I assume it will be used, for example, either
for PPP or SLIP interface and the tty-like serial driver on serial_1
("/dev/tty1").
First, you need to enable CDL component
cdl_componet CYGPKG_IO_SERIAL_DEVICES {
user_value 1;
}
to get working the interrupt driven serial drivers. I also assume that
you want to get non-blocking I/O for those serial ports. That's it
cdl_option CYGOPT_IO_SERIAL_SUPPORT_NONBLOCKING {
user_value 1;
};
Think about any king of flow control if you need to have it.
cdl_component CYGPKG_IO_SERIAL_FLOW_CONTROL {
...
The above is your decision. At the least you can have XON/XOFF, a HW
frow control is hardware depended (I do not know what is your UARTs).
But, my question is, Do you need it? Be careful with flow control.
For serial_1 enable the below component (it will be your /dev/ser0):
cyg_io_lookup("/dev/ser0", ...);
cdl_component CYGPKG_IO_SERIAL_ARM_AT91_SERIAL0 {
user_value 1;
};
Look then on other options CYGNUM_IO_SERIAL_ARM_AT91_SERIAL0_* and
change that what you need (e.g., you will want to increase default
buffer size).
Now the serial_1.
cdl_component CYGPKG_IO_SERIAL_ARM_AT91_SERIAL1 {
user_value 1;
};
Look then on other options CYGNUM_IO_SERIAL_ARM_AT91_SERIAL1_* and
change that what you need.
As I could understand, you tnink about serail_1 as TTY-like console, so,
enable the option the below: cyg_io_lookup("/dev/tty1", ...);
cdl_component CYGPKG_IO_SERIAL_TTY_TTY1 {
user_value 1
};
And I assume that you do want to see ptintfs on this console, doesn't
you?
cdl_option CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE {
user_value \"/dev/tty1\"
};
I guess that printf ("hello, world!\n") will appear on your serial_1.
And I assume that fgets(buf, MAXLINE, stdin) will works too for the
serial_1.
If you plan to make some pice of a termios code to spin on serial_1, you
will need to enable the component
cdl_component CYGPKG_IO_SERIAL_TERMIOS {
user_value 1
};
and then you can try to "open" it as cyg_io_lookup("/dev/termios1",
...);
And at the end about diagnostic port (serial_2). To get a polled mode
only you can disable
cdl_component CYGPKG_IO_SERIAL_ARM_AT91_SERIAL2 {
user_value 0
};
And then you won't be able "open" (cyg_io_lookup("/dev/haldiag", ...);
You saw it already. That device wraps a non-layered TTY-like
"/dev/ttydiag". BUT, you will be able to call diagnostic "atomic"
routings (e.g. diag_printf) and it's output will be appear on serial_2,
If you want to have TTY-like ability (line buffered output) on HAL
diagnostic, enable the component the above; and then examples/serial.c
will be able to manage "/dev/haldiag", you saw that too.
If you have not the connector on serial_2, it won't be useful for you.
And it is bad, because eCos sources use a lot the diagnostic routings
(assertions fails, debug messages, etc.). It seems for me that you have
to up a few configurations on a debug stage. To get work diagnostic
either on serial_0 or serial_1 (remember about console channel #).
cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL {
...
Note: Your friend at configure stages
cdl_option CYGDBG_IO_INIT
But, all outputs will appear on diagnostic channel! By the way, I
remember someone on the list told about "a redirection" diagnostic
output into an area of RAM. Look what HAL_DIAG_WRITE_CHAR is. And surf
throught out the list.
IMHO, it is useful to enable cdl_option CYGBLD_IO_SERIAL_EXTRA_TESTS and
look at those sources and play with the tests.
Well, everyone (I'm not exception! :-) dreams about:
$ yes | make config
to get a working linux kernel for own needs, but, in the most cases it
is not possible. IMHO, eCos is the same: ecosconfig new <target> is
just a start...
Good luck,
Sergei