[ECOS] One question.

[ECOS] One question.

[Zhao.Green]

Dear ALL:
	I use the ecos package , and I found the double type question
Double dnum1 = 1234567.1
Double dnum2 = 1234567
Double result = 0 ;

Result = dnum1-dnum2 ;

The result is 0.10000000009

Anybody know how to solve this question?

BR
Green

--
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] One question.

[Fabian Scheler]

> Double dnum1 = 1234567.1
> Double dnum2 = 1234567
> Double result = 0 ;
>
> Result = dnum1-dnum2 ;
>
> The result is 0.10000000009

Well, I guess this behaviour has nothing to do with eCos at all, I
think it depends on the floating point implementation you use, either
the library or the hardware - this error might be caused by rounding.

Ciao, Fabian

-- 
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] One question.

[Paul D. DeRocco]

> From: Zhao.Green@inventec-inc.com
>
> 	I use the ecos package , and I found the double type question
> Double dnum1 = 1234567.1
> Double dnum2 = 1234567
> Double result = 0 ;
>
> Result = dnum1-dnum2 ;
>
> The result is 0.10000000009
>
> Anybody know how to solve this question?

0.1 can't be represented exactly in binary, so there's an inevitable
roundoff error. Sometimes these errors are hidden by the implementation of
the binary to decimal conversion used in printing out the answer, but
sometimes not. I don't know if you're using printf in C, or << in C++, but
you might try requesting less precision in the output, to see if that rounds
the result back to 0.1.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.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

Re: [ECOS] One question.

[Edgar Grimberg]

> hoping to have helped you,

http://en.wikipedia.org/wiki/Floating_point

Maybe there is a wider explanation, assorted with links (see chapter
"Problems with floating-point")

Regards,
Edgar



-- 
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] One question.

[Michele Portolan]

Zhao.Green@inventec-inc.com wrote:
> Dear Sir:
> 	Sure, if I try to less precision in output. The result can be round back to 0.1.
> But if  the dnum1 = 0.00000000001 , dnum2 = dnum1.
> Result = dnum1+dnum2 
> The result is 0.00000000002
> This amaze me.
> 
This is quite normal: floating point use relative precision (depends on the size of the mantissa. When you write 0.00000000001 all zero are normalized, but when you use 1234567 0.1 must be too little if compared to 1234567 in your representation.

> When dnum1  = 0.00000000001, the register show this value is 9.9999999999999994e-12.

You should try to see the binary representation, once more there must is too much precision in the visualisation primitive.


hoping to have helped you,

Michele
> 
> 
> 
> BR
> Green
> 
> 
> 
> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Paul D. DeRocco
> Sent: Wednesday, May 31, 2006 2:29 PM
> To: eCos Discuss
> Subject: RE: [ECOS] One question.
> 
>> From: Zhao.Green@inventec-inc.com
>>
>> 	I use the ecos package , and I found the double type question Double 
>> dnum1 = 1234567.1 Double dnum2 = 1234567 Double result = 0 ;
>>
>> Result = dnum1-dnum2 ;
>>
>> The result is 0.10000000009
>>
>> Anybody know how to solve this question?
> 
> 0.1 can't be represented exactly in binary, so there's an inevitable roundoff error. Sometimes these errors are hidden by the implementation of the binary to decimal conversion used in printing out the answer, but sometimes not. I don't know if you're using printf in C, or << in C++, but you might try requesting less precision in the output, to see if that rounds the result back to 0.1.
> 
> --
> 
> Ciao,               Paul D. DeRocco
> Paul                mailto:pderocco@ix.netcom.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
> 
> 


-- 
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] One question.

[Zhao.Green]

Dear Sir:
	Sure, if I try to less precision in output. The result can be round back to 0.1.
But if  the dnum1 = 0.00000000001 , dnum2 = dnum1.
Result = dnum1+dnum2 
The result is 0.00000000002
This amaze me.

When dnum1  = 0.00000000001, the register show this value is 9.9999999999999994e-12.



BR
Green



-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Paul D. DeRocco
Sent: Wednesday, May 31, 2006 2:29 PM
To: eCos Discuss
Subject: RE: [ECOS] One question.

> From: Zhao.Green@inventec-inc.com
>
> 	I use the ecos package , and I found the double type question Double 
> dnum1 = 1234567.1 Double dnum2 = 1234567 Double result = 0 ;
>
> Result = dnum1-dnum2 ;
>
> The result is 0.10000000009
>
> Anybody know how to solve this question?

0.1 can't be represented exactly in binary, so there's an inevitable roundoff error. Sometimes these errors are hidden by the implementation of the binary to decimal conversion used in printing out the answer, but sometimes not. I don't know if you're using printf in C, or << in C++, but you might try requesting less precision in the output, to see if that rounds the result back to 0.1.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.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


--
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] One question..

[anton yakovlev]

Gary Thomas wrote:

>On Sat, 2004-06-26 at 06:26, anton yakovlev wrote:
>  
>
>>Gary Thomas wrote:
>>
>>    
>>
>>>On Sat, 2004-06-26 at 02:59, anton yakovlev wrote:
>>>      
>>>
>>>.. skipped ..
>>>      
>>>
>>Hm.. I did not think about this.. I use GNU ld with "-L <smth> 
>>-Wl,--gc-sections -nostartfiles -Ttarget.ld -nostdlib" flags.. Simple 
>>"hello, world" and some more complex programms work's properly.. How to 
>>check, which way the program was linked?..
>>    
>>
>
>The command "XXX-objdump -h file.elf" will show how the program was
>linked.
>  
>
(19:39:25 snoopy@starlake:project)$ v850-elf-objdump -h binary/tracker.elf

binary/tracker.elf:     file format elf32-v850

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000cf7e  00205000  00205000  00001000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .fini         00000000  00211f80  00211f80  0001780c  2**0
                  CONTENTS
  2 .rodata       00005faa  00211f80  00211f80  0000df80  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .rodata1      00000000  00217f2c  00217f2c  0001780c  2**0
                  CONTENTS
  4 .fixup        00000000  00217f2c  00217f2c  0001780c  2**0
                  CONTENTS
  5 .gcc_except_table 00000000  00217f2c  00217f2c  0001780c  2**0
                  CONTENTS
  6 .data         000038e0  00217f2c  00217f2c  00013f2c  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  7 .bss          00004604  0021b80c  0021b80c  0001780c  2**2
                  ALLOC
  8 .v850_ram     00000000  ffffe500  ffffe500  0001780c  2**0
                  CONTENTS
  9 .stab         00041a9c  00000000  00000000  0001780c  2**2
                  CONTENTS, READONLY, DEBUGGING
 10 .stabstr      00067796  00000000  00000000  000592a8  2**0
                  CONTENTS, READONLY, DEBUGGING

It seems, that program linked correctly..

>>PS: When I turn on full kernel debug, that my above programm work's 
>>fine.. but when I try to execute more complex multithreaded program, 
>>this programm failed while system initialization with "ASSERT FAIL: 
>>mutex.cxx cyg_bool Cyg_Mutex::lock()".. :(
>>    
>>
>
>This would be a separate problem.  Have you run the standard tests to 
>see how they perform on your platform?
>  
>
There are all kernel tests, that I have:

bin_sem0: are not compiled
bin_sem1: OK
bin_sem2: are not compiled
bin_sem3: OK
clock0: are not compiled
clock1: OK
clockcnv: OK
clocktruth: are not compiled
cnt_sem0: are not compiled
cnt_sem1: OK
dhrystone: NOTAPPLICABLE
except1: FAIL
flag0: are not compiled
flag1: OK
fptest: does not work, because problems with threads
intr0: OK
kalarm0: OK
kcache1: NOTAPPLICABLE
kcache2: NOTAPPLICABLE
kclock0: OK
kclock1: OK
kexcept1: FAIL
kflag0: OK
kflag1: OK
kill: OK
kintr0: OK
klock: OK
kmbox1: FAIL
kmutex0: OK
kmutex1: OK
kmutex3: OK
kmutex4: OK
kphilo: OK
ksched1: OK
ksem0: OK
ksem1: OK
kthread0: OK
kthread1: OK
mbox1: OK
mqueue1: are not compiled
mutex0: are not compiled
mutex1: OK
mutex2: OK
mutex3: OK
philo: are not compiled
release: OK
sched1: OK
smp: NOTAPPLICABLE
stress_threads: FAIL
sync2: OK
sync3: OK
tcdiag: are not compiled
thread0: are not compiled
thread1: OK
thread2: OK
thread_gdb: OK
timeslice: OK
tm_basic: are not compiled

Tests, that "are not compiled", failed while compilation with "undefined 
reference to `___gxx_personality_sj0'" error..


-- 
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] One question..

[Gary Thomas]

On Sat, 2004-06-26 at 06:26, anton yakovlev wrote:
> Gary Thomas wrote:
> 
> >On Sat, 2004-06-26 at 02:59, anton yakovlev wrote:
> >  
> >
> >>Gary Thomas wrote:
> >>    
> >>
> >>>On Fri, 2004-06-25 at 02:09, anton yakovlev wrote:
> >>>      
> >>>
> >>>>Hi, all!
> >>>>
> >>>>I have a programm:
> >>>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >>>>#include <stdio.h>
> >>>>#include <cyg/kernel/kapi.h>
> >>>>
> >>>>void first(cyg_addrword_t threadData) {
> >>>>
> >>>>   (void) threadData;
> >>>>   printf("the first thread\n");
> >>>>
> >>>>}
> >>>>
> >>>>static char stack_a[4096];
> >>>>static cyg_thread thread_a;
> >>>>static cyg_handle_t handle_a;
> >>>>
> >>>>void cyg_user_start(void) {
> >>>>  
> >>>>   cyg_thread_create(10, first, 0, "first", stack_a, 4096, &handle_a, 
> >>>>&thread_a);
> >>>>   cyg_thread_resume(handle_a);
> >>>>
> >>>>}
> >>>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >>>>but when i try to executing it, i see only following:
> >>>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >>>>RedBoot> load -r -m y -b 0x205000
> >>>>Raw file loaded 0x00205000-0x00210500
> >>>>xyzModem - CRC mode, 363(SOH)/0(STX)/0(CAN) packets, 3 retries
> >>>>RedBoot> go 0x205000
> >>>>        
> >>>>
> >>>Why did you specify raw mode (-r)?  When you do this, RedBoot loads the 
> >>>file directly into memory without any processing at all, probably not
> >>>what you want to do.
> >>>      
> >>>
> >>Because I upload exactly raw image.. neither elf-image, nor s-record..
> >>    
> >>
> >
> >That's fine (many people make mistakes here, but you've not). 
> >
> >Was the program linked to load at 0x205000?  eCos programs are *not* 
> >position independent and must be loaded to memory that matches how they
> >are built/linked.
> >  
> >
> Hm.. I did not think about this.. I use GNU ld with "-L <smth> 
> -Wl,--gc-sections -nostartfiles -Ttarget.ld -nostdlib" flags.. Simple 
> "hello, world" and some more complex programms work's properly.. How to 
> check, which way the program was linked?..

The command "XXX-objdump -h file.elf" will show how the program was
linked.

> 
> PS: When I turn on full kernel debug, that my above programm work's 
> fine.. but when I try to execute more complex multithreaded program, 
> this programm failed while system initialization with "ASSERT FAIL: 
> mutex.cxx cyg_bool Cyg_Mutex::lock()".. :(

This would be a separate problem.  Have you run the standard tests to 
see how they perform on your platform?

> 
> >>>How did you create the file that's being downloaded?  Is it an 
> >>>executable (ELF) image?  or possibly S-records?
> >>>      
> >>>
> >> From elf-image using objcopy..
> >>    
> >>
> >>>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >>>>i.e. thread want not to start.. Why so?..
> >>>>
> >>>>I have Falcom fx35xxlsi (based on NEC V850 processors family) platform 
> >>>>with eCos 2.0.. I build eCos from the sources.. Maybe I have broken 
> >>>>configuration?..
> >>>>        
> >>>>
-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
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] One question..

[anton yakovlev]

Gary Thomas wrote:

>On Sat, 2004-06-26 at 02:59, anton yakovlev wrote:
>  
>
>>Gary Thomas wrote:
>>    
>>
>>>On Fri, 2004-06-25 at 02:09, anton yakovlev wrote:
>>>      
>>>
>>>>Hi, all!
>>>>
>>>>I have a programm:
>>>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>>>#include <stdio.h>
>>>>#include <cyg/kernel/kapi.h>
>>>>
>>>>void first(cyg_addrword_t threadData) {
>>>>
>>>>   (void) threadData;
>>>>   printf("the first thread\n");
>>>>
>>>>}
>>>>
>>>>static char stack_a[4096];
>>>>static cyg_thread thread_a;
>>>>static cyg_handle_t handle_a;
>>>>
>>>>void cyg_user_start(void) {
>>>>  
>>>>   cyg_thread_create(10, first, 0, "first", stack_a, 4096, &handle_a, 
>>>>&thread_a);
>>>>   cyg_thread_resume(handle_a);
>>>>
>>>>}
>>>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>>>but when i try to executing it, i see only following:
>>>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>>>RedBoot> load -r -m y -b 0x205000
>>>>Raw file loaded 0x00205000-0x00210500
>>>>xyzModem - CRC mode, 363(SOH)/0(STX)/0(CAN) packets, 3 retries
>>>>RedBoot> go 0x205000
>>>>        
>>>>
>>>Why did you specify raw mode (-r)?  When you do this, RedBoot loads the 
>>>file directly into memory without any processing at all, probably not
>>>what you want to do.
>>>      
>>>
>>Because I upload exactly raw image.. neither elf-image, nor s-record..
>>    
>>
>
>That's fine (many people make mistakes here, but you've not). 
>
>Was the program linked to load at 0x205000?  eCos programs are *not* 
>position independent and must be loaded to memory that matches how they
>are built/linked.
>  
>
Hm.. I did not think about this.. I use GNU ld with "-L <smth> 
-Wl,--gc-sections -nostartfiles -Ttarget.ld -nostdlib" flags.. Simple 
"hello, world" and some more complex programms work's properly.. How to 
check, which way the program was linked?..

PS: When I turn on full kernel debug, that my above programm work's 
fine.. but when I try to execute more complex multithreaded program, 
this programm failed while system initialization with "ASSERT FAIL: 
mutex.cxx cyg_bool Cyg_Mutex::lock()".. :(

>>>How did you create the file that's being downloaded?  Is it an 
>>>executable (ELF) image?  or possibly S-records?
>>>      
>>>
>> From elf-image using objcopy..
>>    
>>
>>>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>>>i.e. thread want not to start.. Why so?..
>>>>
>>>>I have Falcom fx35xxlsi (based on NEC V850 processors family) platform 
>>>>with eCos 2.0.. I build eCos from the sources.. Maybe I have broken 
>>>>configuration?..
>>>>        
>>>>


-- 
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] One question..

[Gary Thomas]

On Sat, 2004-06-26 at 02:59, anton yakovlev wrote:
> Gary Thomas wrote:
> 
> >On Fri, 2004-06-25 at 02:09, anton yakovlev wrote:
> >  
> >
> >>Hi, all!
> >>
> >>I have a programm:
> >>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >>#include <stdio.h>
> >>#include <cyg/kernel/kapi.h>
> >>
> >>void first(cyg_addrword_t threadData) {
> >>
> >>    (void) threadData;
> >>    printf("the first thread\n");
> >>
> >>}
> >>
> >>static char stack_a[4096];
> >>static cyg_thread thread_a;
> >>static cyg_handle_t handle_a;
> >>
> >>void cyg_user_start(void) {
> >>   
> >>    cyg_thread_create(10, first, 0, "first", stack_a, 4096, &handle_a, 
> >>&thread_a);
> >>    cyg_thread_resume(handle_a);
> >>
> >>}
> >>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >>but when i try to executing it, i see only following:
> >>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >>RedBoot> load -r -m y -b 0x205000
> >>Raw file loaded 0x00205000-0x00210500
> >>xyzModem - CRC mode, 363(SOH)/0(STX)/0(CAN) packets, 3 retries
> >>RedBoot> go 0x205000
> >>    
> >>
> >
> >Why did you specify raw mode (-r)?  When you do this, RedBoot loads the 
> >file directly into memory without any processing at all, probably not
> >what you want to do.
> >  
> >
> Because I upload exactly raw image.. neither elf-image, nor s-record..

That's fine (many people make mistakes here, but you've not). 

Was the program linked to load at 0x205000?  eCos programs are *not* 
position independent and must be loaded to memory that matches how they
are built/linked.

> 
> >How did you create the file that's being downloaded?  Is it an 
> >executable (ELF) image?  or possibly S-records?
> >  
> >
>  From elf-image using objcopy..
> 
> >>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >>i.e. thread want not to start.. Why so?..
> >>
> >>I have Falcom fx35xxlsi (based on NEC V850 processors family) platform 
> >>with eCos 2.0.. I build eCos from the sources.. Maybe I have broken 
> >>configuration?..
> >>    
> >>
-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
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] One question..

[anton yakovlev]

Gary Thomas wrote:

>On Fri, 2004-06-25 at 02:09, anton yakovlev wrote:
>  
>
>>Hi, all!
>>
>>I have a programm:
>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>#include <stdio.h>
>>#include <cyg/kernel/kapi.h>
>>
>>void first(cyg_addrword_t threadData) {
>>
>>    (void) threadData;
>>    printf("the first thread\n");
>>
>>}
>>
>>static char stack_a[4096];
>>static cyg_thread thread_a;
>>static cyg_handle_t handle_a;
>>
>>void cyg_user_start(void) {
>>   
>>    cyg_thread_create(10, first, 0, "first", stack_a, 4096, &handle_a, 
>>&thread_a);
>>    cyg_thread_resume(handle_a);
>>
>>}
>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>but when i try to executing it, i see only following:
>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>RedBoot> load -r -m y -b 0x205000
>>Raw file loaded 0x00205000-0x00210500
>>xyzModem - CRC mode, 363(SOH)/0(STX)/0(CAN) packets, 3 retries
>>RedBoot> go 0x205000
>>    
>>
>
>Why did you specify raw mode (-r)?  When you do this, RedBoot loads the 
>file directly into memory without any processing at all, probably not
>what you want to do.
>  
>
Because I upload exactly raw image.. neither elf-image, nor s-record..

>How did you create the file that's being downloaded?  Is it an 
>executable (ELF) image?  or possibly S-records?
>  
>
 From elf-image using objcopy..

>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>i.e. thread want not to start.. Why so?..
>>
>>I have Falcom fx35xxlsi (based on NEC V850 processors family) platform 
>>with eCos 2.0.. I build eCos from the sources.. Maybe I have broken 
>>configuration?..
>>    
>>


-- 
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] One question..

[anton yakovlev]

sandeep wrote:

> anton yakovlev wrote:
>
>> Hi, all!
>>
>> I have a programm:
>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 
>>
>> #include <stdio.h>
>> #include <cyg/kernel/kapi.h>
>>
>> void first(cyg_addrword_t threadData) {
>>
>>    (void) threadData;
>>    printf("the first thread\n");
>>
>> }
>>
>> static char stack_a[4096];
>> static cyg_thread thread_a;
>> static cyg_handle_t handle_a;
>>
>> void cyg_user_start(void) {
>>      cyg_thread_create(10, first, 0, "first", stack_a, 4096, 
>> &handle_a, &thread_a);
>>    cyg_thread_resume(handle_a);
>
>      cyg_scheduler_start();

Hm.. According to eCos sources, this function invoked automatically in 
cyg_start(), after return from cyg_user_start()..

>>
>> }
>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 
>>
>> but when i try to executing it, i see only following:
>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 
>>
>> RedBoot> load -r -m y -b 0x205000
>> Raw file loaded 0x00205000-0x00210500
>> xyzModem - CRC mode, 363(SOH)/0(STX)/0(CAN) packets, 3 retries
>> RedBoot> go 0x205000
>>
>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 
>>
>> i.e. thread want not to start.. Why so?..
>>
>> I have Falcom fx35xxlsi (based on NEC V850 processors family) 
>> platform with eCos 2.0.. I build eCos from the sources.. Maybe I have 
>> broken configuration?..
>>
>>
>


-- 
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] One question..

[Gary Thomas]

On Fri, 2004-06-25 at 02:09, anton yakovlev wrote:
> Hi, all!
> 
> I have a programm:
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> #include <stdio.h>
> #include <cyg/kernel/kapi.h>
> 
> void first(cyg_addrword_t threadData) {
> 
>     (void) threadData;
>     printf("the first thread\n");
> 
> }
> 
> static char stack_a[4096];
> static cyg_thread thread_a;
> static cyg_handle_t handle_a;
> 
> void cyg_user_start(void) {
>    
>     cyg_thread_create(10, first, 0, "first", stack_a, 4096, &handle_a, 
> &thread_a);
>     cyg_thread_resume(handle_a);
> 
> }
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> but when i try to executing it, i see only following:
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> RedBoot> load -r -m y -b 0x205000
> Raw file loaded 0x00205000-0x00210500
> xyzModem - CRC mode, 363(SOH)/0(STX)/0(CAN) packets, 3 retries
> RedBoot> go 0x205000

Why did you specify raw mode (-r)?  When you do this, RedBoot loads the 
file directly into memory without any processing at all, probably not
what you want to do.

How did you create the file that's being downloaded?  Is it an 
executable (ELF) image?  or possibly S-records?

> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> i.e. thread want not to start.. Why so?..
> 
> I have Falcom fx35xxlsi (based on NEC V850 processors family) platform 
> with eCos 2.0.. I build eCos from the sources.. Maybe I have broken 
> configuration?..
-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
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] One question..

[anton yakovlev]

Hi, all!

I have a programm:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#include <stdio.h>
#include <cyg/kernel/kapi.h>

void first(cyg_addrword_t threadData) {

    (void) threadData;
    printf("the first thread\n");

}

static char stack_a[4096];
static cyg_thread thread_a;
static cyg_handle_t handle_a;

void cyg_user_start(void) {
   
    cyg_thread_create(10, first, 0, "first", stack_a, 4096, &handle_a, 
&thread_a);
    cyg_thread_resume(handle_a);

}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
but when i try to executing it, i see only following:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
RedBoot> load -r -m y -b 0x205000
Raw file loaded 0x00205000-0x00210500
xyzModem - CRC mode, 363(SOH)/0(STX)/0(CAN) packets, 3 retries
RedBoot> go 0x205000

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
i.e. thread want not to start.. Why so?..

I have Falcom fx35xxlsi (based on NEC V850 processors family) platform 
with eCos 2.0.. I build eCos from the sources.. Maybe I have broken 
configuration?..


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