[ECOS] printf and diag_printf go to nowhere

Robert Brusa bob.brusa@gmail.com
Wed Apr 15 07:40:00 GMT 2009


On Sun, 12 Apr 2009 17:42:04 +0200, Sergei Gavrikov  
<sergei.gavrikov@gmail.com> wrote:

> ...cut....

> 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

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.
   Robert


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



More information about the Ecos-discuss mailing list