[ECOS] printf and diag_printf go to nowhere

Robert Brusa bob.brusa@gmail.com
Sun Apr 12 15:22:00 GMT 2009

On Sat, 11 Apr 2009 18:44:34 +0200, Sergei Gavrikov  
<sergei.gavrikov@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
>>     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
>>     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
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ekdef_23.ecm
Type: application/octet-stream
Size: 6534 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/ecos-discuss/attachments/20090412/d90b5ae8/attachment.obj>
-------------- next part --------------
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