[quote] Re: [ECOS] printf and diag_printf go to nowhere 2

Skip to site navigation (Press enter)

Re: [ECOS] printf and diag_printf go to nowhere

Sergei Gavrikov Sun, 12 Apr 2009 08:42:27 -0700

On Sun, Apr 12, 2009 at 03:14:38PM +0200, Robert Brusa wrote:
> On Sat, 11 Apr 2009 18:44:34 +0200, Sergei Gavrikov  
> <sergei.gavri...@gmail.com> wrote:
>
>> On Sat, Apr 11, 2009 at 06:15:50PM +0300, Sergei Gavrikov wrote:
>>> On Sat, Apr 11, 2009 at 12:42:50PM +0200, Robert Brusa wrote:
>>> > Hi
>>> > When running the example serial.c that comes with ecos-3.0, I get no
>>> > output on the serial i/f of my AT91SAMX512-based board. I am using a
>>> > configuration where I have enabled hardware drivers for ser0 and 
>>> ser1 and
>>> > disabled ser2 (see attachment).
>>> >
>>> > serial performs a lookup for /dev/haldiag - and fails. In fact, this
>>                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Ups, I missed this. Of course it will be, because, you have disabled
>> *SERIAL2 == your HAL's /dev/haldiag (read the below's explanations)
>> there is
>>
>> cdl_component CYGPKG_IO_SERIAL_ARM_AT91_SERIAL2 { user_value 0 };
>>
>> in your ECM.
>>
>> My assumes the below were based on that what SERIAL2 device is alive.
>> But that is not wrong.
>>
>>
>> Sergei
>>
>>
>>> > string is not present in my configurations ecc-file. What I find there
>>> > is: /dev/ttydiag. But when changing haldiag to ttydiag, the result 
>>> is the
>>> > same: No output on ser0 or ser1.
>>>
>>> Hi
>>>
>>> Now I knew your target's name and I can know what is it. So, it has 3
>>> serial channels (I did not know about). According HAL, diagnostic and
>>> debug channels are asigned with channel 2 (as you named it "ser2"). So,
>>> all diagnostic output, by default, will be appear on the diagnostic
>>> channel or at the "ser2", won't it?
>>>
>>> // it should appear at "ser2"
>>> diag_printf("test string\n");
>>>
>>> Unfortunatly, I can only guess what you want to have. Let's assume, that
>>> you want to see the output the above on "ser0". In this case you have to
>>> change
>>>
>>> cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL {
>>>     user_value 0;
>>> }
>>>
>>> for "ser1" it will "user_value 1" (by default it is equal 2 == "ser2").
>>>
>>> Let's look on examples/serial.c again and your ECM options. I noted that
>>> you do not tweak the option the above.
>>>
>>>     serial.c:83:printf("Starting serial example\n");
>>>
>>> According the attached ECM, your printf() will print on the device
>>>
>>> cdl_option CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE {
>>>     user_value "\"/dev/ttydiag\""
>>> };
>>>
>>> So, printf will be to use diagnostic channel ("ser2"), becuase, the
>>> above option points on "/dev/ttydiag". Where did you expect the output?
>>> It seems for me, it will appear on "ser2".
>>>
>>>     serial.c:85:err = cyg_io_lookup( "/dev/haldiag", &handle );
>>>
>>> The "/dev/ttydiag" is a device name (a generic diagnostic device name).
>>> By default, when an eCos cdl_componet CYGPKG_IO_SERIAL_TTY_TTYDIAG is
>>> enabled, it uses itself a layered device with name "/dev/haldiag". Look,
>>> please, for a reference at
>>>
>>> /opt/ecos/ecos-3.0/packages/io/serial/v3_0/src/common/tty.c
>>>
>>> and you will see how the device's names are assigned with the layered
>>> devices (dep_names) acording CDL options.
>>>
>>> The first and non-layered `/dev/haldiag' device exactly is
>>> /opt/ecos/ecos-3.0/packages/io/serial/v3_0/src/common/haldiag.c
>>>
>>> Note: about a DEVTAB_ENTRY internals you can find information by a link
>>> the below (look at the chapter's name as on "how-io-driver-works")
>>> http://ecos.sourceware.org/docs-latest/ref/io-how-to-write-a-driver.html
>>>
>>> Well, I knew that "/dev/haldiag" (with your settings) is "ser2".
>>>
>>> > On the other hand, when changing to /dev/ser0 or /dev/ser1, I get this
>>> > particular line on the ser0 or ser1 interface - as expected. But all
>>> > other output generated by printf-statements still is "unvisible". 
>>> Is this
>>>
>>> Of course, particular, I can assume that that line
>>>
>>>     "serial example is working correctly!\n";
>>>
>>> will appear on "ser2".
>>>
>>> And when you changed CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE (/dev/ser0,
>>> /dev/ser1), your printf's will be there, but not on /dev/haldiag.
>>>
>>> Now you knew what "/dev/ttydiag" is by default, and I not saw that you
>>> assigned default console with another device. So, printf will just use
>>> haldiag_putc (=HAL_DIAG_WRITE_CHAR) to out strings on "ser2". And it's
>>> no deal that you enabled cdl component CYGPKG_IO_SERIAL_DEVICES.
>>>
>>> Well, on the not-a-reduced targets (with GDB support) those printf's, by
>>> default, all will appear just in GDB (on diagnostic | debug channel).
>>>
>>> So, if you know where you want to see the diagnostic output, specify
>>> that with cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL.
>>>
>>> I hope, that was it.
>>>
>>> Sergei
>>>
>>> > a bug or do I get something wrong?
>>> >   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
>
> Hi Sergei
> thank you for your help. Following your script I achieved that I get the  
> following output on uart1:
> ---------------------
> Starting serial example
> Found /dev/haldiag. Writing string....
> serial example is working correctly!
> I think I wrote the string. Did you see it?
> Serial example finished
> ---------------------
> An this is absoutely great. what I want at the end is to use:
> serial_0 for efficient bidirectional (interrupt driven) communication
> serial_1 should act as my console-device (also efficient)
> serial_2 is not wired on my board, but I possibly could use it to access  
> the output to serial_2 through my JTAG debugger. I will have to test 
> this.
>
> What I do not yet understand: Is diag_printf in my current configuration  
> (see attachment) now going to serial_2 using an at91-specific efficient  
> driver or still the polling write routine? Or none of both, because there 
> is a conflict?
>
> I coninue testing. I think much of what I want to achieve is now working. 
> It looks good. Thanks
>    Robert

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