[ECOS] printf and diag_printf go to nowhere

[ECOS] printf and diag_printf go to nowhere

[Robert Brusa]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

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

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 a bug  
or do I get something wrong?
   Robert

[-- Attachment #2: ekdef_21.ecm --]
[-- Type: application/octet-stream, Size: 6122 bytes --]

cdl_savefile_version 1;
cdl_savefile_command cdl_savefile_version {};
cdl_savefile_command cdl_savefile_command {};
cdl_savefile_command cdl_configuration { description hardware template package };
cdl_savefile_command cdl_package { value_source user_value wizard_value inferred_value };
cdl_savefile_command cdl_component { value_source user_value wizard_value inferred_value };
cdl_savefile_command cdl_option { value_source user_value wizard_value inferred_value };
cdl_savefile_command cdl_interface { value_source user_value wizard_value inferred_value };

cdl_configuration eCos {
    description "" ;
    hardware    at91sam7xek ;
    template    default ;
    package -template CYGPKG_HAL v3_0 ;
    package -template CYGPKG_IO v3_0 ;
    package -template CYGPKG_IO_SERIAL v3_0 ;
    package -template CYGPKG_INFRA v3_0 ;
    package -template CYGPKG_KERNEL v3_0 ;
    package -template CYGPKG_MEMALLOC v3_0 ;
    package -template CYGPKG_ISOINFRA v3_0 ;
    package -template CYGPKG_LIBC v3_0 ;
    package -template CYGPKG_LIBC_I18N v3_0 ;
    package -template CYGPKG_LIBC_SETJMP v3_0 ;
    package -template CYGPKG_LIBC_SIGNALS v3_0 ;
    package -template CYGPKG_LIBC_STARTUP v3_0 ;
    package -template CYGPKG_LIBC_STDIO v3_0 ;
    package -template CYGPKG_LIBC_STDLIB v3_0 ;
    package -template CYGPKG_LIBC_STRING v3_0 ;
    package -template CYGPKG_LIBC_TIME v3_0 ;
    package -template CYGPKG_LIBM v3_0 ;
    package -template CYGPKG_IO_WALLCLOCK v3_0 ;
    package -template CYGPKG_ERROR v3_0 ;
    package -hardware CYGPKG_HAL_ARM v3_0 ;
    package -hardware CYGPKG_HAL_ARM_AT91 v3_0 ;
    package -hardware CYGPKG_HAL_ARM_AT91SAM7 v3_0 ;
    package -hardware CYGPKG_HAL_ARM_AT91SAM7XEK v3_0 ;
    package -hardware CYGPKG_IO_SERIAL_ARM_AT91 v3_0 ;
    package -hardware CYGPKG_DEVS_FLASH_AT91 v3_0 ;
    package -hardware CYGPKG_IO_SPI v3_0 ;
    package -hardware CYGPKG_DEVS_SPI_ARM_AT91 v3_0 ;
    package -hardware CYGPKG_DEVICES_WATCHDOG_ARM_AT91WDTC v3_0 ;
    package -hardware CYGPKG_DEVS_USB_AT91 v3_0 ;
    package -hardware CYGPKG_DEVS_ETH_PHY v3_0 ;
    package -hardware CYGPKG_DEVS_ETH_ARM_AT91 v3_0 ;
};

cdl_option CYGBLD_GLOBAL_CFLAGS {
    user_value "-Wall -Wpointer-arith -Wstrict-prototypes -Wundef -Woverloaded-virtual -Wno-write-strings  -mno-thumb-interwork -mcpu=arm7tdmi -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions "
};

cdl_option CYGBLD_GLOBAL_LDFLAGS {
    user_value " -mno-thumb-interwork -mcpu=arm7tdmi -Wl,--gc-sections -Wl,-static -g -nostdlib -Xlinker -Map -Xlinker \${project-name}"
};

cdl_option CYGHWR_HAL_ARM_AT91 {
    user_value AT91SAM7S
};

cdl_option CYGHWR_HAL_ARM_AT91_FIQ {
    user_value 1
};

cdl_option CYGBLD_HAL_ARM_AT91_TIMER_TC {
    user_value 0
};

cdl_option CYGHWR_HAL_ARM_AT91SAM7 {
    user_value at91sam7x512
};

cdl_option CYGBLD_HAL_ARM_AT91SAM7_USB {
    user_value 0
};

cdl_option CYGBLD_HAL_ARM_AT91SAM7_SPI1 {
    user_value 0
};

cdl_option CYGBLD_HAL_ARM_AT91SAM7_CAN0 {
    user_value 0
};

cdl_option CYGNUM_HAL_ARM_AT91_CLOCK_OSC_MAIN {
    user_value 25000000
};

cdl_option CYGNUM_HAL_ARM_AT91_CLOCK_TYPE {
    user_value EXTCLOCK
};

cdl_option CYGNUM_HAL_ARM_AT91_PLL_DIVIDER {
    user_value 25
};

cdl_option CYGNUM_HAL_ARM_AT91_PLL_MULTIPLIER {
    user_value 96
};

cdl_option CYGOPT_IO_SERIAL_SUPPORT_NONBLOCKING {
    user_value 1
};

cdl_component CYGPKG_IO_SERIAL_DEVICES {
    user_value 1
};

cdl_component CYGPKG_IO_SERIAL_ARM_AT91_SERIAL0 {
    user_value 1
};

cdl_component CYGPKG_IO_SERIAL_ARM_AT91_SERIAL2 {
    user_value 0
};

cdl_option CYGBLD_ISO_CTYPE_HEADER {
    inferred_value 1 <cyg/libc/i18n/ctype.inl>
};

cdl_option CYGBLD_ISO_ERRNO_CODES_HEADER {
    inferred_value 1 <cyg/error/codes.h>
};

cdl_option CYGBLD_ISO_ERRNO_HEADER {
    inferred_value 1 <cyg/error/errno.h>
};

cdl_option CYGBLD_ISO_STDIO_FILETYPES_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_STREAMS_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_FILEOPS_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_FILEACCESS_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_FORMATTED_IO_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_CHAR_IO_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_DIRECT_IO_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_FILEPOS_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_ERROR_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDLIB_STRCONV_HEADER {
    inferred_value 1 <cyg/libc/stdlib/atox.inl>
};

cdl_option CYGBLD_ISO_STDLIB_ABS_HEADER {
    inferred_value 1 <cyg/libc/stdlib/abs.inl>
};

cdl_option CYGBLD_ISO_STDLIB_DIV_HEADER {
    inferred_value 1 <cyg/libc/stdlib/div.inl>
};

cdl_option CYGBLD_ISO_STRERROR_HEADER {
    inferred_value 1 <cyg/error/strerror.h>
};

cdl_option CYGBLD_ISO_STRTOK_R_HEADER {
    inferred_value 1 <cyg/libc/string/string.h>
};

cdl_option CYGBLD_ISO_STRING_LOCALE_FUNCS_HEADER {
    inferred_value 1 <cyg/libc/string/string.h>
};

cdl_option CYGBLD_ISO_STRING_BSD_FUNCS_HEADER {
    inferred_value 1 <cyg/libc/string/bsdstring.h>
};

cdl_option CYGBLD_ISO_STRING_MEMFUNCS_HEADER {
    inferred_value 1 <cyg/libc/string/string.h>
};

cdl_option CYGBLD_ISO_STRING_STRFUNCS_HEADER {
    inferred_value 1 <cyg/libc/string/string.h>
};

cdl_option CYGBLD_ISO_C_TIME_TYPES_HEADER {
    inferred_value 1 <cyg/libc/time/time.h>
};

cdl_option CYGBLD_ISO_C_CLOCK_FUNCS_HEADER {
    inferred_value 1 <cyg/libc/time/time.h>
};

cdl_option CYGBLD_ISO_SIGNAL_NUMBERS_HEADER {
    inferred_value 1 <cyg/libc/signals/signal.h>
};

cdl_option CYGBLD_ISO_SIGNAL_IMPL_HEADER {
    inferred_value 1 <cyg/libc/signals/signal.h>
};

cdl_option CYGBLD_ISO_SETJMP_HEADER {
    inferred_value 1 <cyg/libc/setjmp/setjmp.h>
};

cdl_option CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE {
    user_value "\"/dev/ttydiag\""
};



[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

Re: [ECOS] printf and diag_printf go to nowhere

[Sergei Gavrikov]

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

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

Re: [ECOS] printf and diag_printf go to nowhere

[Sergei Gavrikov]

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

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

Re: [ECOS] printf and diag_printf go to nowhere

[Robert Brusa]

[-- Attachment #1: Type: text/plain, Size: 5814 bytes --]

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

[-- Attachment #2: ekdef_23.ecm --]
[-- Type: application/octet-stream, Size: 6534 bytes --]

cdl_savefile_version 1;
cdl_savefile_command cdl_savefile_version {};
cdl_savefile_command cdl_savefile_command {};
cdl_savefile_command cdl_configuration { description hardware template package };
cdl_savefile_command cdl_package { value_source user_value wizard_value inferred_value };
cdl_savefile_command cdl_component { value_source user_value wizard_value inferred_value };
cdl_savefile_command cdl_option { value_source user_value wizard_value inferred_value };
cdl_savefile_command cdl_interface { value_source user_value wizard_value inferred_value };

cdl_configuration eCos {
    description "" ;
    hardware    at91sam7xek ;
    template    default ;
    package -template CYGPKG_HAL v3_0 ;
    package -template CYGPKG_IO v3_0 ;
    package -template CYGPKG_IO_SERIAL v3_0 ;
    package -template CYGPKG_INFRA v3_0 ;
    package -template CYGPKG_KERNEL v3_0 ;
    package -template CYGPKG_MEMALLOC v3_0 ;
    package -template CYGPKG_ISOINFRA v3_0 ;
    package -template CYGPKG_LIBC v3_0 ;
    package -template CYGPKG_LIBC_I18N v3_0 ;
    package -template CYGPKG_LIBC_SETJMP v3_0 ;
    package -template CYGPKG_LIBC_SIGNALS v3_0 ;
    package -template CYGPKG_LIBC_STARTUP v3_0 ;
    package -template CYGPKG_LIBC_STDIO v3_0 ;
    package -template CYGPKG_LIBC_STDLIB v3_0 ;
    package -template CYGPKG_LIBC_STRING v3_0 ;
    package -template CYGPKG_LIBC_TIME v3_0 ;
    package -template CYGPKG_LIBM v3_0 ;
    package -template CYGPKG_IO_WALLCLOCK v3_0 ;
    package -template CYGPKG_ERROR v3_0 ;
    package -hardware CYGPKG_HAL_ARM v3_0 ;
    package -hardware CYGPKG_HAL_ARM_AT91 v3_0 ;
    package -hardware CYGPKG_HAL_ARM_AT91SAM7 v3_0 ;
    package -hardware CYGPKG_HAL_ARM_AT91SAM7XEK v3_0 ;
    package -hardware CYGPKG_IO_SERIAL_ARM_AT91 v3_0 ;
    package -hardware CYGPKG_DEVS_FLASH_AT91 v3_0 ;
    package -hardware CYGPKG_IO_SPI v3_0 ;
    package -hardware CYGPKG_DEVS_SPI_ARM_AT91 v3_0 ;
    package -hardware CYGPKG_DEVICES_WATCHDOG_ARM_AT91WDTC v3_0 ;
    package -hardware CYGPKG_DEVS_USB_AT91 v3_0 ;
    package -hardware CYGPKG_DEVS_ETH_PHY v3_0 ;
    package -hardware CYGPKG_DEVS_ETH_ARM_AT91 v3_0 ;
};

cdl_option CYGBLD_GLOBAL_CFLAGS {
    user_value "-Wall -Wpointer-arith -Wstrict-prototypes -Wundef -Woverloaded-virtual -Wno-write-strings  -mno-thumb-interwork -mcpu=arm7tdmi -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions "
};

cdl_option CYGBLD_GLOBAL_LDFLAGS {
    user_value " -mno-thumb-interwork -mcpu=arm7tdmi -Wl,--gc-sections -Wl,-static -g -nostdlib -Xlinker -Map -Xlinker \${project-name}"
};

cdl_option CYGHWR_HAL_ARM_AT91 {
    user_value AT91SAM7S
};

cdl_option CYGHWR_HAL_ARM_AT91_FIQ {
    user_value 1
};

cdl_option CYGBLD_HAL_ARM_AT91_TIMER_TC {
    user_value 0
};

cdl_component CYGBLD_HAL_ARM_AT91_DCC {
    user_value 1
};

cdl_option CYGHWR_HAL_ARM_AT91SAM7 {
    user_value at91sam7x512
};

cdl_option CYGBLD_HAL_ARM_AT91SAM7_USB {
    user_value 0
};

cdl_option CYGBLD_HAL_ARM_AT91SAM7_SPI1 {
    user_value 0
};

cdl_option CYGBLD_HAL_ARM_AT91SAM7_CAN0 {
    user_value 0
};

cdl_option CYGNUM_HAL_ARM_AT91_CLOCK_OSC_MAIN {
    user_value 25000000
};

cdl_option CYGNUM_HAL_ARM_AT91_CLOCK_TYPE {
    user_value EXTCLOCK
};

cdl_option CYGNUM_HAL_ARM_AT91_PLL_DIVIDER {
    user_value 25
};

cdl_option CYGNUM_HAL_ARM_AT91_PLL_MULTIPLIER {
    user_value 96
};

cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_COMM_CHANNELS {
    user_value 3
};

cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL {
    user_value 1
};

cdl_option CYGOPT_IO_SERIAL_SUPPORT_NONBLOCKING {
    user_value 1
};

cdl_component CYGPKG_IO_SERIAL_TTY {
    user_value 1
};

cdl_option CYGDAT_IO_SERIAL_TTY_CONSOLE {
    user_value "\"/dev/ttydiag\""
};

cdl_component CYGPKG_IO_SERIAL_TTY_TTYDIAG {
    user_value 1
};

cdl_component CYGPKG_IO_SERIAL_DEVICES {
    user_value 1
};

cdl_component CYGPKG_IO_SERIAL_ARM_AT91_SERIAL0 {
    user_value 1
};

cdl_component CYGPKG_IO_SERIAL_ARM_AT91_SERIAL2 {
    user_value 1
};

cdl_option CYGBLD_ISO_CTYPE_HEADER {
    inferred_value 1 <cyg/libc/i18n/ctype.inl>
};

cdl_option CYGBLD_ISO_ERRNO_CODES_HEADER {
    inferred_value 1 <cyg/error/codes.h>
};

cdl_option CYGBLD_ISO_ERRNO_HEADER {
    inferred_value 1 <cyg/error/errno.h>
};

cdl_option CYGBLD_ISO_STDIO_FILETYPES_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_STREAMS_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_FILEOPS_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_FILEACCESS_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_FORMATTED_IO_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_CHAR_IO_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_DIRECT_IO_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_FILEPOS_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDIO_ERROR_HEADER {
    inferred_value 1 <cyg/libc/stdio/stdio.h>
};

cdl_option CYGBLD_ISO_STDLIB_STRCONV_HEADER {
    inferred_value 1 <cyg/libc/stdlib/atox.inl>
};

cdl_option CYGBLD_ISO_STDLIB_ABS_HEADER {
    inferred_value 1 <cyg/libc/stdlib/abs.inl>
};

cdl_option CYGBLD_ISO_STDLIB_DIV_HEADER {
    inferred_value 1 <cyg/libc/stdlib/div.inl>
};

cdl_option CYGBLD_ISO_STRERROR_HEADER {
    inferred_value 1 <cyg/error/strerror.h>
};

cdl_option CYGBLD_ISO_STRTOK_R_HEADER {
    inferred_value 1 <cyg/libc/string/string.h>
};

cdl_option CYGBLD_ISO_STRING_LOCALE_FUNCS_HEADER {
    inferred_value 1 <cyg/libc/string/string.h>
};

cdl_option CYGBLD_ISO_STRING_BSD_FUNCS_HEADER {
    inferred_value 1 <cyg/libc/string/bsdstring.h>
};

cdl_option CYGBLD_ISO_STRING_MEMFUNCS_HEADER {
    inferred_value 1 <cyg/libc/string/string.h>
};

cdl_option CYGBLD_ISO_STRING_STRFUNCS_HEADER {
    inferred_value 1 <cyg/libc/string/string.h>
};

cdl_option CYGBLD_ISO_C_TIME_TYPES_HEADER {
    inferred_value 1 <cyg/libc/time/time.h>
};

cdl_option CYGBLD_ISO_C_CLOCK_FUNCS_HEADER {
    inferred_value 1 <cyg/libc/time/time.h>
};

cdl_option CYGBLD_ISO_SIGNAL_NUMBERS_HEADER {
    inferred_value 1 <cyg/libc/signals/signal.h>
};

cdl_option CYGBLD_ISO_SIGNAL_IMPL_HEADER {
    inferred_value 1 <cyg/libc/signals/signal.h>
};

cdl_option CYGBLD_ISO_SETJMP_HEADER {
    inferred_value 1 <cyg/libc/setjmp/setjmp.h>
};

cdl_option CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE {
    user_value "\"/dev/ser1\""
};



[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

Re: [ECOS] printf and diag_printf go to nowhere

[Sergei Gavrikov]

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

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

Re: [ECOS] printf and diag_printf go to nowhere

[Robert Brusa]

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

Re: [ECOS] printf and diag_printf go to nowhere

[Edgar Grimberg]

Robert Brusa wrote:
>
> 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!
Are you sure that execution is supposed to start at address 0x0 ? If 
it's a ROM application, try go 0x00100000 (I believe that's the starting 
point for your target).
Also, another thing that might confuse you is the configuration script 
for BDI. It will set up the target CPU to a state that is different than 
the one you get without the BDI. When I write applications that are 
supposed to start up the board (ROM startup type), I use a stripped down 
version of the config file, that will not touch the configuration 
registers in the CPU.
> 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.
This looks like the configuration script kicking in :)

Regards,
Edgar

-- 
Edgar Grimberg
System Developer
Zylin AS
Phone: (+47) 51 63 25 00


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

Re: [ECOS] printf and diag_printf go to nowhere

[Andrew Lunn]

On Wed, Apr 15, 2009 at 09:38:39AM +0200, Edgar Grimberg wrote:
> Robert Brusa wrote:
>>
>> 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!
> Are you sure that execution is supposed to start at address 0x0 ? If  
> it's a ROM application, try go 0x00100000 (I believe that's the starting  
> point for your target).
> Also, another thing that might confuse you is the configuration script  
> for BDI. It will set up the target CPU to a state that is different than  
> the one you get without the BDI. When I write applications that are  
> supposed to start up the board (ROM startup type), I use a stripped down  
> version of the config file, that will not touch the configuration  
> registers in the CPU.

Yes, it sounds like the BDI is remapped the memory. On a clean power
on, without any JTAG debugger fiddling with things, ROM is mapped both
at 0x0 and 0x00100000. The JTAG programmer i use, jumps in on reset
and maps RAM to 0x0.

    Andrew

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

Re: [ECOS] printf and diag_printf go to nowhere

[Sergei Gavrikov]

On Wed, Apr 15, 2009 at 09:49:54AM +0200, Andrew Lunn wrote:
> On Wed, Apr 15, 2009 at 09:38:39AM +0200, Edgar Grimberg wrote:
> > Robert Brusa wrote:
> >>
> >> 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!
> > Are you sure that execution is supposed to start at address 0x0 ? If  
> > it's a ROM application, try go 0x00100000 (I believe that's the starting  
> > point for your target).
> > Also, another thing that might confuse you is the configuration script  
> > for BDI. It will set up the target CPU to a state that is different than  
> > the one you get without the BDI. When I write applications that are  
> > supposed to start up the board (ROM startup type), I use a stripped down  
> > version of the config file, that will not touch the configuration  
> > registers in the CPU.
> 
> Yes, it sounds like the BDI is remapped the memory. On a clean power
> on, without any JTAG debugger fiddling with things, ROM is mapped both
> at 0x0 and 0x00100000. The JTAG programmer i use, jumps in on reset
> and maps RAM to 0x0.

Robert, and then when you will manage your JTAG BDI config file and the
gears will become to spin I would suggest you to prepare an Expect
script for the BDI telnet prompt to automate things, add a rule in your
makefile and all things will become so simple as to type "make prog".
The link the below is just for a reference, what's possible to get using
Expect (it is just a demo)

http://sourceware.org/ml/ecos-discuss/2004-11/msg00262.html

if you again and again enter commands on any prompt, such a job is the
job for Expect. I use Expect too, but, with another programmer.


Sergei

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