[ECOS] printf problem

[ECOS] printf problem

[Tathagata Das]

Hi all,
       I am trying to write serial driver.
My problem is printf is working in cyg_user_start function, but does not 
work from any thread.
I have debugged. From thread context, serial_write function is not invoked.

diag_printf is working in thread.

Here is my program ----

void entry_point1(cyg_addrword_t data)
{
        for(;;) {
                cyg_thread_delay(100);
                diag_printf("\n5");
                printf("0");
        }
}

void entry_point2(cyg_addrword_t data)
{
        for(;;) {
                cyg_thread_delay(200);
                diag_printf("\n6");
                printf("1");
        }
}

void cyg_user_start(void)
{
        printf("tatha");
        cyg_thread_create(4, entry_point1, (cyg_addrword_t) "A", "Thread 
1", (void *) stack[0], 4096,  &thread1, &thread_s[0]);
        cyg_thread_create(4, entry_point2, (cyg_addrword_t) "B", "Thread 
2", (void *) stack[1], 4096,  &thread2, &thread_s[1]);
        cyg_thread_resume(thread1);
        cyg_thread_resume(thread2);

}

I am geting "tatha", "5" and "6" ... but not getting "0" or "1"

Probably I am missing something.
I will be very pleased if somebody help me.

Regards,
Tatha

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

[Gary Thomas]

Tathagata Das wrote:
> Hi all,
>       I am trying to write serial driver.
> My problem is printf is working in cyg_user_start function, but does not 
> work from any thread.
> I have debugged. From thread context, serial_write function is not invoked.
> 
> diag_printf is working in thread.
> 
> Here is my program ----
> 
> void entry_point1(cyg_addrword_t data)
> {
>        for(;;) {
>                cyg_thread_delay(100);
>                diag_printf("\n5");
>                printf("0");
>        }
> }
> 
> void entry_point2(cyg_addrword_t data)
> {
>        for(;;) {
>                cyg_thread_delay(200);
>                diag_printf("\n6");
>                printf("1");
>        }
> }
> 
> void cyg_user_start(void)
> {
>        printf("tatha");
>        cyg_thread_create(4, entry_point1, (cyg_addrword_t) "A", "Thread 
> 1", (void *) stack[0], 4096,  &thread1, &thread_s[0]);
>        cyg_thread_create(4, entry_point2, (cyg_addrword_t) "B", "Thread 
> 2", (void *) stack[1], 4096,  &thread2, &thread_s[1]);
>        cyg_thread_resume(thread1);
>        cyg_thread_resume(thread2);
> 
> }
> 
> I am geting "tatha", "5" and "6" ... but not getting "0" or "1"
> 
> Probably I am missing something.
> I will be very pleased if somebody help me.

How did you configure 'printf' to use your serial driver?
Does your serial driver (any functions) ever get called?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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

[Tathagata Das]

Thanks for you quick response.
Yes,  my serial driver gets invoke when printf is called. I have 
debugged that.
But when I use printf from thread, my serial driver does not get called.

Gary Thomas wrote:

> Tathagata Das wrote:
>
>> Hi all,
>>       I am trying to write serial driver.
>> My problem is printf is working in cyg_user_start function, but does 
>> not work from any thread.
>> I have debugged. From thread context, serial_write function is not 
>> invoked.
>>
>> diag_printf is working in thread.
>>
>> Here is my program ----
>>
>> void entry_point1(cyg_addrword_t data)
>> {
>>        for(;;) {
>>                cyg_thread_delay(100);
>>                diag_printf("\n5");
>>                printf("0");
>>        }
>> }
>>
>> void entry_point2(cyg_addrword_t data)
>> {
>>        for(;;) {
>>                cyg_thread_delay(200);
>>                diag_printf("\n6");
>>                printf("1");
>>        }
>> }
>>
>> void cyg_user_start(void)
>> {
>>        printf("tatha");
>>        cyg_thread_create(4, entry_point1, (cyg_addrword_t) "A", 
>> "Thread 1", (void *) stack[0], 4096,  &thread1, &thread_s[0]);
>>        cyg_thread_create(4, entry_point2, (cyg_addrword_t) "B", 
>> "Thread 2", (void *) stack[1], 4096,  &thread2, &thread_s[1]);
>>        cyg_thread_resume(thread1);
>>        cyg_thread_resume(thread2);
>>
>> }
>>
>> I am geting "tatha", "5" and "6" ... but not getting "0" or "1"
>>
>> Probably I am missing something.
>> I will be very pleased if somebody help me.
>
>
> How did you configure 'printf' to use your serial driver?
> Does your serial driver (any functions) ever get called?
>

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

[Manuel Borchers]

Am Dienstag, den 01.06.2010, 12:52 +0200 schrieb Manuel Borchers: 
> Am Dienstag, den 01.06.2010, 10:49 +0200 schrieb Manuel Borchers: 
> > They are in the resulting application. At least lookup and write are
> > working, because that's what I used to test my serial drivers in the
> > first place.
> > 
> > I need to write some simple tests to see if set/get and read are
> > working. Will do that later.
> 
> I did just that. get_conf works, using set_conf I am able to change the
> baudrate on the fly and read also is able to read chars from the
> terminal.
> 
> The driver seems to be okay. So I guess it's something related to the
> stdio streams. Any pointers for me to look at?
> 

Thanks to Sergei, again, and a lot of single-stepping through the 
StreamBuffer initialization, I found the problem. malloc couldn't
allocate space for the io_bufs of stdin and stdout.

That was caused by a wrong calculation for the heap-size in the
memory-layout definition. I fixed that and printf is working fine now.

Cheers and thanks to Sergei!
Manuel


-- 
Manuel Borchers

Web: http://www.matronix.de
eMail: manuel@matronix.de

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

[Manuel Borchers]

Am Dienstag, den 01.06.2010, 10:49 +0200 schrieb Manuel Borchers: 
> They are in the resulting application. At least lookup and write are
> working, because that's what I used to test my serial drivers in the
> first place.
> 
> I need to write some simple tests to see if set/get and read are
> working. Will do that later.

I did just that. get_conf works, using set_conf I am able to change the
baudrate on the fly and read also is able to read chars from the
terminal.

The driver seems to be okay. So I guess it's something related to the
stdio streams. Any pointers for me to look at?

Cheers,
Manuel

-- 
Manuel Borchers

Web: http://www.matronix.de
eMail: manuel@matronix.de

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

[Manuel Borchers]

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

Hi Sergei, hi list,

Am Montag, den 31.05.2010, 21:26 +0300 schrieb Sergei Gavrikov: 
> Those snippets are the very minimal configs :-)

Indeed. Find the output of your inspect script attached. Note: your
inspect script misses the netx serial driver, because it's included with
-hardware.

The config looks like that:
cdl_configuration eCos {
    description "" ;

    # These fields should not be modified.
    hardware    nxhx50re_ser_only ;
    template    default ;
    package -hardware CYGPKG_HAL_ARM current ;
    package -hardware CYGPKG_HAL_ARM_ARM9 current ;
    package -hardware CYGPKG_HAL_ARM_ARM9_NETX50 current ;
    package -hardware CYGPKG_IO_SERIAL_ARM_NETX current ;
    package -template CYGPKG_HAL current ;
    package -template CYGPKG_IO current ;
    package -template CYGPKG_IO_SERIAL current ;
    package -template CYGPKG_INFRA current ;   
    package -template CYGPKG_KERNEL current ;  
    package -template CYGPKG_MEMALLOC current ;
    package -template CYGPKG_ISOINFRA current ;
    package -template CYGPKG_LIBC current ;
    package -template CYGPKG_LIBC_I18N current ;   
    package -template CYGPKG_LIBC_SETJMP current ; 
    package -template CYGPKG_LIBC_SIGNALS current ;
    package -template CYGPKG_LIBC_STARTUP current ;
    package -template CYGPKG_LIBC_STDIO current ;  
    package -template CYGPKG_LIBC_STDLIB current ; 
    package -template CYGPKG_LIBC_STRING current ;
    package -template CYGPKG_LIBC_TIME current ;
    package -template CYGPKG_LIBM current ;
    package -template CYGPKG_IO_WALLCLOCK current ;
    package -template CYGPKG_ERROR current ;
    package CYGPKG_PDCURSES current ;
};


> As your HAL is freshmeat... And what your HAL global CFLAGS, LDFLAGS
> are?  Do you use the same flags as another ARM9 targets use? May be
> there are some odd things? Where your compiler (toolchain) came from?

I'm using the ecoscentric-supplied arm-eabi toolchain from ecos v3.0
release (but I'm on cvs for ecos itself right now)

CFLAGS and LDFLAGS should be somewhat standard for the arm ports. I
started using an integrator or innovator (can't remember anymore) arm9
hal. I could try using specific -mcpu options for the arm966 (currently
using just arm9), but that shouldn't be the problem.

from my Make.params:

ECOS_GLOBAL_CFLAGS = -Wall -Wpointer-arith -Wstrict-prototypes -Wundef
-Woverloaded-virtual -Wno-write-strings -mno-thumb-interwork -mcpu=arm9
-g -O0 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions
ECOS_GLOBAL_LDFLAGS = -mno-thumb-interwork -mcpu=arm9
--no-target-default-spec -Wl,--gc-sections -Wl,-static -g -O0 -nostdlib


> About serial tests (though you said: 'the netX serial driver working
> quite fine'), if you looking for more tests, look at
> 
>    io/serial/<version>/tests/README

Okay, I did not think about the serial tests just before. But I compiled
them and after adding stuff to the ser_test_protocol.inl I got serial1,
serial2, tty1 and tty2 running fine. (I stopped here, because I don't
want to setup the serial_filter stuff, because I'm not using RedBoot /
gdb stubs; I'm building stand-alone apps)

> Can you confirm that at the least that `serial1' test finished without
> any failures on your target? Can you confirm also that all cyg_io* calls
> (lookup, read, write, set/get config) work as you could expect on your
> eCos serial device '/dev/serX'?

They are in the resulting application. At least lookup and write are
working, because that's what I used to test my serial drivers in the
first place.

I need to write some simple tests to see if set/get and read are
working. Will do that later.


Btw.: Testing printf is done with the PDCurses example and with my
minimalistic example, that uses printf after testing cyg_io_lookup and
_write.

Find my minimalistic exmaple attached.


Cheers,
Manuel

-- 
Manuel Borchers

Web: http://www.matronix.de
eMail: manuel@matronix.de

[-- Attachment #2: diff.ecm --]
[-- Type: text/plain, Size: 1263 bytes --]

cdl_configuration eCos {
    template    default ;
    package CYGPKG_PDCURSES current ;
};
cdl_option CYGBLD_BUILD_GDB_STUBS {
    user_value 0
};
cdl_component CYGDBG_HAL_DIAG_TO_DEBUG_CHAN {
    user_value 0
};
cdl_option CYGSEM_HAL_DIAG_MANGLER {
    user_value None
};
cdl_option CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE {
    user_value 4096
};
cdl_option CYGDBG_HAL_COMMON_INTERRUPTS_SAVE_MINIMUM_CONTEXT {
    user_value 0
};
cdl_option CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM {
    user_value 0
};
cdl_option CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS {
    user_value 0
};
cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_COMMS {
    user_value 1
};
cdl_option CYGSEM_HAL_USE_ROM_MONITOR {
    user_value 0 0
};
cdl_component CYG_HAL_STARTUP {
    user_value RAM
};
cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNEL {
    user_value 1
};
cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL {
    user_value 1
};
cdl_option CYGDBG_IO_INIT {
    user_value 1
};
cdl_component CYGPKG_IO_SERIAL_DEVICES {
    user_value 1
};
cdl_component CYGPKG_INFRA_DEBUG {
    user_value 1
};
cdl_component CYGDBG_USE_ASSERTS {
    user_value 1
};
cdl_component CYGDBG_USE_TRACING {
    user_value 1
};
cdl_option CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE {
    user_value "\"/dev/ser0\""
};

[-- Attachment #3: serial.c --]
[-- Type: text/x-csrc, Size: 2763 bytes --]

/* 
 * Written 1999-03-19 by Jonathan Larmour, Cygnus Solutions
 * This file is in the public domain and may be used for any purpose
 */

/* CONFIGURATION CHECKS */

#include <pkgconf/system.h>     /* which packages are enabled/disabled */
#ifdef CYGPKG_KERNEL
# include <pkgconf/kernel.h>
#endif
#ifdef CYGPKG_LIBC
# include <pkgconf/libc.h>
#endif
#ifdef CYGPKG_IO_SERIAL
# include <pkgconf/io_serial.h>
#endif

#ifndef CYGFUN_KERNEL_API_C
# error Kernel API must be enabled to build this example
#endif

#ifndef CYGPKG_LIBC_STDIO
# error C library standard I/O must be enabled to build this example
#endif

#ifndef CYGPKG_IO_SERIAL_HALDIAG
# error I/O HALDIAG pseudo-device driver must be enabled to build this example
#endif

#ifndef CYGPKG_IO_SERIAL_ARM_NETX
# error netX serial driver is not included
#else
#include <pkgconf/io_serial_arm_netx.h>
#endif

#ifndef CYGPKG_IO_SERIAL_ARM_NETX_SERIAL0
# error netX UART0 not defined
#endif


/* INCLUDES */

#include <stdio.h>                      /* printf */
#include <string.h>                     /* strlen */
#include <cyg/kernel/kapi.h>            /* All the kernel specific stuff */
#include <cyg/io/io.h>                  /* I/O functions */
#include <cyg/hal/hal_arch.h>           /* CYGNUM_HAL_STACK_SIZE_TYPICAL */

#include <cyg/infra/diag.h>



/* DEFINES */

#define NTHREADS 1
#define STACKSIZE ( CYGNUM_HAL_STACK_SIZE_TYPICAL + 4096 )

/* STATICS */

static cyg_handle_t thread[NTHREADS];
static cyg_thread thread_obj[NTHREADS];
static char stack[NTHREADS][STACKSIZE];

/* FUNCTIONS */

static void simple_prog(CYG_ADDRESS data)
{
    cyg_io_handle_t handle;
    Cyg_ErrNo err;
    const char test_string[] = "serial example is working correctly!\n";
    cyg_uint32 len = strlen(test_string);

    diag_printf("Starting serial example\n");

    err = cyg_io_lookup( "/dev/haldiag", &handle );
    
    if (ENOERR == err) {
        diag_printf("Found /dev/haldiag. Writing string....\n");
        err = cyg_io_write( handle, test_string, &len );
        if (ENOERR == err) {
            diag_printf("I think I wrote the string. Did you see it?\n");
        }
    }

    err = cyg_io_lookup( "/dev/ser0", &handle );

    if (ENOERR == err) {
        diag_printf("Found /dev/ser0. Writing string....\n");
        err = cyg_io_write( handle, test_string, &len );
        if (ENOERR == err) {
            diag_printf("I think I wrote the string. Did you see it?\n");
        }
    }
    

    diag_printf("Serial example finished\n");
    printf("Serial example finished (printf)\n");
}

void cyg_user_start(void)
{
    cyg_thread_create(4, simple_prog, (cyg_addrword_t) 0, "serial",
                      (void *)stack[0], STACKSIZE, &thread[0], &thread_obj[0]);
    cyg_thread_resume(thread[0]);
}


[-- Attachment #4: 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

[ECOS] printf problem

[Manuel Borchers]

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

Hi all,

it's me again with 'serial' problems ;)

I got the netX serial driver working quite fine. So the next step was to
try out printf (I was using diag_printf before, which works flawlessly).

I enabled asserts, tracing and io init debugging. Stdio is still on the
default /dev/ttydiag (which works fine on the linux synthetic target).

But on my real hardware, I directly get an assertion: ASSERT FAIL:
<3>stream.cxx[603]virtual Cyg_ErrNo Cyg_StdioStream::write() Stream
object is not a valid stream!

I debugged that a few days ago, so it's somewaht summed up out of my
mind:

I stepped a bit through the constructors that fire up stdin and stdout.
The assertion seems to be raised because the magic word hasn't been
written. I trapped that down to the fact that the buffer used by the
stream has no size (i.e. is 0). 

And that's the point were I left, because I had no idea, why this could
be the case.

I also tried routing STDIO to /dev/ser0 and /dev/tty0, which resulted in
the same assertion (but I didn't step into the constructors in these
scenarios).

Find my minimal minimal config's attached, I'm importing for the
scenario.


Any hints on how to debug this any further or pointers what i'm missing
in my config are greatly appreciated.

Cheers,
Manuel


-- 
Manuel Borchers

Web: http://www.matronix.de
eMail: manuel@matronix.de

[-- Attachment #2: console_debug_to_uart1.ecm --]
[-- Type: text/plain, Size: 701 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_option CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNEL { user_value 1 };
cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL { user_value 1 };

[-- Attachment #3: disable_gdb_mangler.ecm --]
[-- Type: text/plain, Size: 828 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_option CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT {
#  user_value 0
#};
#
#cdl_option CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT {
#  user_value 0
#};

cdl_option CYGDBG_HAL_DIAG_TO_DEBUG_CHAN {
  user_value 0
};

cdl_option CYGSEM_HAL_DIAG_MANGLER {
  user_value None
};

[-- Attachment #4: ecos_default_curses.ecm --]
[-- Type: text/plain, Size: 1984 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 "Default config for netX50 for standalone apps" ;
    template    default ;
    package -hardware CYGPKG_HAL_ARM current ;
    package -hardware CYGPKG_HAL_ARM_ARM9_NETX50 current ;
    package -hardware CYGPKG_IO_SERIAL_ARM_NETX current ;
    package -template CYGPKG_HAL current ;
    package -template CYGPKG_IO current ;
    package -template CYGPKG_IO_SERIAL current ;
    package -template CYGPKG_INFRA current ;
    package -template CYGPKG_ISOINFRA current ;
    package -template CYGPKG_LIBC_STRING current ;
    package CYGPKG_MEMALLOC current ;
    package CYGPKG_PDCURSES current ;
};

cdl_component CYGPKG_IO_SERIAL_DEVICES {
    user_value 1
};

cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNEL {
    user_value 1
};

cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL {
    user_value 1
};

cdl_option CYGBLD_BUILD_GDB_STUBS {
    user_value 0
};

cdl_option CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS {
    user_value 0
};

cdl_option CYGSEM_HAL_USE_ROM_MONITOR {
    user_value 0 0
};

cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_COMMS {
    user_value 1
};

cdl_component CYG_HAL_STARTUP {
    user_value RAM
};

cdl_option CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE {
    user_value 4096
};

cdl_option CYGDBG_HAL_COMMON_INTERRUPTS_SAVE_MINIMUM_CONTEXT {
    user_value 0
};

cdl_option CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM {
    #inferred_value 0
    user_value 0
};

[-- Attachment #5: enable_io_init_debug.ecm --]
[-- Type: text/plain, Size: 610 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_option CYGDBG_IO_INIT {
    user_value 1
};

[-- Attachment #6: enable_tracing.ecm --]
[-- Type: text/plain, Size: 854 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_component CYGPKG_INFRA_DEBUG { user_value 1 };
cdl_component CYGDBG_USE_ASSERTS { user_value 1 };
cdl_component CYGDBG_USE_TRACING { user_value 1 };

#cdl_option CYGDBG_INFRA_DEBUG_TRACE_ASSERT_SIMPLE { user_value 1 };
#cdl_option CYGDBG_INFRA_DEBUG_TRACE_ASSERT_FANCY { user_value 1 };


[-- Attachment #7: 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 problem

[Aniket S Joshi]

Hi Andrew,

Thanks and regards,
Aniket Joshi

Senior Software Engineer
Larsen & Toubro Ltd,
Embedded System & Software (EmSys),
KIADB Industrial Estate Hebbal
Hootagalli, Mysore,
State: Karnataka, 
India
PIN: 570018

Ph:+91-821-2402561 Ext:2765
FAX: +91-821-2403752
http://www.lntemsys.com


>>> Andrew Lunn <andrew@lunn.ch> 08/30/04 08:00PM >>>
On Mon, Aug 30, 2004 at 06:33:46PM +0530, Aniket S Joshi wrote:
> Hi all,
> 
>  I am using Hitachi 7729 Platform with Ecos for my project & using network connection for my code download & debugging using insight.
> 
> using serial port of the controller for my application. but whenever i use any printf command in my code (for debugging) serial communication interrupt gets disturbed (it prints all the incoming data at a streatch (not as it comes , looks like pending interrupt) ,
>  I assume GDB has higher priority than serial (or any other).
> 
> How to change the interrupt priority of GDB? I want to make it the lowest.
> One more question..... How can i disable debugging feature in my application?

The hal diagnostis serial device driver is polled busy wait, not
interrupt driver. Since you are using gdb over ethernet you can use a
proper interrupt serial driver for the serial port. Enable
CYGPKG_IO_SERIAL_DEVICES.

yes , i am using interrupt serial driver only. But whenever i use printf command in my code serial interrupt misbehaves. 
To make the point ...
I am using serial port for MODBUS implementation. I have one free running timer...on every reception of serial byte i am coping free running timer data to array. which is working fine (timer data difference between consicutive serial bytes are proper ) until printf statement is not used. If i use printf statement in my code (in main function ...not in interrupt) timer data difference becomes very less ...looking at data looks like pending interrupt. 

pls guide






        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 



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

[Andrew Lunn]

On Mon, Aug 30, 2004 at 06:33:46PM +0530, Aniket S Joshi wrote:
> Hi all,
> 
>  I am using Hitachi 7729 Platform with Ecos for my project & using network connection for my code download & debugging using insight.
> 
> using serial port of the controller for my application. but whenever i use any printf command in my code (for debugging) serial communication interrupt gets disturbed (it prints all the incoming data at a streatch (not as it comes , looks like pending interrupt) ,
>  I assume GDB has higher priority than serial (or any other).
> 
> How to change the interrupt priority of GDB? I want to make it the lowest.
> One more question..... How can i disable debugging feature in my application?

The hal diagnostis serial device driver is polled busy wait, not
interrupt driver. Since you are using gdb over ethernet you can use a
proper interrupt serial driver for the serial port. Enable
CYGPKG_IO_SERIAL_DEVICES.

        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

[ECOS] Printf problem

[Aniket S Joshi]

Hi all,

 I am using Hitachi 7729 Platform with Ecos for my project & using network connection for my code download & debugging using insight.

using serial port of the controller for my application. but whenever i use any printf command in my code (for debugging) serial communication interrupt gets disturbed (it prints all the incoming data at a streatch (not as it comes , looks like pending interrupt) ,
 I assume GDB has higher priority than serial (or any other).

How to change the interrupt priority of GDB? I want to make it the lowest.
One more question..... How can i disable debugging feature in my application?

Waitng for your reply


Thanks In advance




Thanks and regards,
Aniket Joshi

Senior Software Engineer
Larsen & Toubro Ltd,
Embedded System & Software (EmSys),
KIADB Industrial Estate Hebbal
Hootagalli, Mysore,
State: Karnataka, 
India
PIN: 570018

Ph:+91-821-2402561 Ext:2765
FAX: +91-821-2403752
http://www.lntemsys.com



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