This is the mail archive of the 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: printf and diag_printf go to nowhere

On Sun, 12 Apr 2009 17:42:04 +0200, Sergei Gavrikov <> wrote:


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

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

        user_value 1;

Think about any king of flow control if you need to have it.


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

            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

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 #).


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,


Hi Sergei
I now have a configuration that brings diag_printf and printf out. I also have tested file output to /dev/ser1 and /dev/ser0. It works. But something is still strange and I do not understand what's going on, because things are not really reproducible. Example:

This little serial example program. Compiled, linked downloaded with BDI all ok. But I can not start it with BDI/telnet go 0. Hell and death - just before I did just this!
However, when disconnecting BDI and switching power on, the program launches and works correctly. Putting the JTAG connector back into its place, reseting the BDI via telnet, I can now start the program using go 0. But only once. etc. In short, it seemed to be unstable and I gave in switched everything off and went home.
The next morning I found that everything just worked fine. No problem with the go 0 command. Breakpoints worked etc. I tested this, I tested that and gradually, the "instability" krept back into the system. Now my decission is to just continue, using the BDI for download and hope that time will show were the problem stems from.

I tell you all this to share my current frustration with someone. I do not expect further help, because I am fully aware that these kind of problems are extremely ill suited for telehelp - unfortunately. But many thanks anyway for your time.

-- Before posting, please read the FAQ: and search the list archive:

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