[ECOS] priority of main thread

[ECOS] priority of main thread

[Robert Brusa]

Hi,
in my system, I have a cyg_user_start() as well as a main() function. The  
first includes calls to initialize various modules. main() contains an  
eternal loop and is assumed to work as a normal thread. The problem is  
that main produces a hanger when I call cyg_spi_transfer to read my  
onboard-RTC. When using this RTC-module in a test program with a single  
thread it works. It also works (in main) when I change the transfer-mode  
to polling. This let me think that there is some kind of priority problem.  
How can I access and manipulate the priority of main? I have no handle for  
this thread. Thanks for advice.
    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] priority of main thread

[Gary Thomas]

Robert Brusa wrote:
> Hi,
> in my system, I have a cyg_user_start() as well as a main() function.
> The first includes calls to initialize various modules. main() contains
> an eternal loop and is assumed to work as a normal thread. The problem
> is that main produces a hanger when I call cyg_spi_transfer to read my
> onboard-RTC. When using this RTC-module in a test program with a single
> thread it works. It also works (in main) when I change the transfer-mode
> to polling. This let me think that there is some kind of priority
> problem. How can I access and manipulate the priority of main? I have no
> handle for this thread. Thanks for advice.

How is main() getting started?  Since you've overridden the
default cyg_user_start() [which normally starts the main thread],
it's not clear to me how main() even runs.

-- 
------------------------------------------------------------
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] priority of main thread

[Andrew Lunn]

On Thu, Nov 20, 2008 at 04:22:58PM +0100, Robert Brusa wrote:
> Hi,
> in my system, I have a cyg_user_start() as well as a main() function. The 
> first includes calls to initialize various modules. main() contains an  
> eternal loop and is assumed to work as a normal thread. The problem is  
> that main produces a hanger when I call cyg_spi_transfer to read my  
> onboard-RTC. When using this RTC-module in a test program with a single  
> thread it works. It also works (in main) when I change the transfer-mode  
> to polling. This let me think that there is some kind of priority 
> problem.

I would not necessarily agree with this. If it is a priority problem,
it suggests one of the threads running with higher priority than main
is spinning, so stopping main from running. This is normally a
bug. However this does not really fit with PIO working.

This actually sounds like an interrupt problem. I would put a
breakpoint on the interrupt handler and see if it gets called.

   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] priority of main thread

[Robert Brusa]

On Thu, 20 Nov 2008 16:34:18 +0100, Gary Thomas <gary@mlbassoc.com> wrote:

> How is main() getting started?  Since you've overridden the
> default cyg_user_start() [which normally starts the main thread],
> it's not clear to me how main() even runs.
>

If there is anywhere a main in a project, it gets started - but after  
cyg_user_start. That's what I have read in the manual and somewhere I have  
read that a main is required when one uses some (which?) standard  
libraries that need initialisation. Because I use math and other  
libraries, I decided to have a main in my code. May be its not necessary,  
but it should do no harm (I hope).
    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] priority of main thread

[Gary Thomas]

Robert Brusa wrote:
> On Thu, 20 Nov 2008 16:34:18 +0100, Gary Thomas <gary@mlbassoc.com> wrote:
> 
>> How is main() getting started?  Since you've overridden the
>> default cyg_user_start() [which normally starts the main thread],
>> it's not clear to me how main() even runs.
>>
> 
> If there is anywhere a main in a project, it gets started - but after
> cyg_user_start. That's what I have read in the manual and somewhere I
> have read that a main is required when one uses some (which?) standard
> libraries that need initialisation. Because I use math and other
> libraries, I decided to have a main in my code. May be its not
> necessary, but it should do no harm (I hope).

Actually, main() is started by cyg_user_startup().  Look at
  .../language/c/libc/startup/current/src/cstartup.cxx


-- 
------------------------------------------------------------
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] priority of main thread

[Jonathan Larmour]

Gary Thomas wrote:
> Robert Brusa wrote:
>> On Thu, 20 Nov 2008 16:34:18 +0100, Gary Thomas <gary@mlbassoc.com> wrote:
>>
>>> How is main() getting started?  Since you've overridden the
>>> default cyg_user_start() [which normally starts the main thread],
>>> it's not clear to me how main() even runs.
>>>
>> If there is anywhere a main in a project, it gets started - but after
>> cyg_user_start. That's what I have read in the manual and somewhere I
>> have read that a main is required when one uses some (which?) standard
>> libraries that need initialisation. Because I use math and other
>> libraries, I decided to have a main in my code. May be its not
>> necessary, but it should do no harm (I hope).
> 
> Actually, main() is started by cyg_user_startup().  Look at
>   .../language/c/libc/startup/current/src/cstartup.cxx

Actually it only gets started from cyg_user_start() if the user enables
CYGSEM_LIBC_STARTUP_MAIN_INITCONTEXT. But that is only the default if there
is no eCos kernel at all.

Otherwise (in the more normal case), it is created and started from a
static constructor. So overriding cyg_user_start() makes no difference.

To answer the poster's question, the priority is set with the
CYGNUM_LIBC_MAIN_THREAD_PRIORITY configuration option in the
CYGPKG_LIBC_STARTUP ("ISO environment startup/termination") package.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

-- 
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] priority of main thread

[Robert Brusa]

On Fri, 21 Nov 2008 15:57:31 +0100, Jonathan Larmour  
<jifl@ecoscentric.com> wrote:

> Gary Thomas wrote:
...cut....
>
> Actually it only gets started from cyg_user_start() if the user enables
> CYGSEM_LIBC_STARTUP_MAIN_INITCONTEXT. But that is only the default if  
> there
> is no eCos kernel at all.
>
> Otherwise (in the more normal case), it is created and started from a
> static constructor. So overriding cyg_user_start() makes no difference.
>
> To answer the poster's question, the priority is set with the
> CYGNUM_LIBC_MAIN_THREAD_PRIORITY configuration option in the
> CYGPKG_LIBC_STARTUP ("ISO environment startup/termination") package.
>
> Jifl
Thank you all for your help. "no eCOS kernel at all" That was the point.  
Somehow, the configuration I was working with was broken. This went  
unnoticed, because I run config with the -i option, because my system uses  
a 25 MHz crystal and this was considered illegal sometimes earlier (but  
now is perfectly ok according to the data sheet). Anyway, I got tired  
looking at the ever same error message about this quarz - and stopped  
looking at the output. And voilà - it caught me!
Again - thanks for all your help.
    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] priority of main thread

[Robert Brusa]

On Mon, 24 Nov 2008 09:02:54 +0100, Robert Brusa <Bob.Brusa@gmail.com>  
wrote:

> On Fri, 21 Nov 2008 15:57:31 +0100, Jonathan Larmour  
> <jifl@ecoscentric.com> wrote:
>
>> Gary Thomas wrote:
> ...cut....
>>
>> Actually it only gets started from cyg_user_start() if the user enables
>> CYGSEM_LIBC_STARTUP_MAIN_INITCONTEXT. But that is only the default if  
>> there
>> is no eCos kernel at all.
>>
>> Otherwise (in the more normal case), it is created and started from a
>> static constructor. So overriding cyg_user_start() makes no difference.
>>
>> To answer the poster's question, the priority is set with the
>> CYGNUM_LIBC_MAIN_THREAD_PRIORITY configuration option in the
>> CYGPKG_LIBC_STARTUP ("ISO environment startup/termination") package.
>>
>> Jifl
> Thank you all for your help. "no eCOS kernel at all" That was the point.  
> Somehow, the configuration I was working with was broken. This went  
> unnoticed, because I run config with the -i option, because my system  
> uses a 25 MHz crystal and this was considered illegal sometimes earlier  
> (but now is perfectly ok according to the data sheet). Anyway, I got  
> tired looking at the ever same error message about this quarz - and  
> stopped looking at the output. And voilà - it caught me!
> Again - thanks for all your help.
>     Robert
>
The problem is not so simple: I went back and created ecos.ecc from the  
original CVS (ecos-2.x downloaded in June 08). The config commands used  
are then:
ecosconfig new at91sam7xek default
ecosconfig add CYGPKG_IO_FLASH
ecosconfig add CYGPKG_IO_SPI
ecosconfig -i tree
ecosconfig --verbose check
make

When inspecting my ecos.ecc I find the "configuration broken"-message. I  
change from the default ML-scheduler to the bitmap schedule. The  
broken-message persists:

cdl_option CYGSEM_KERNEL_SCHED_BITMAP {
     # Flavor: bool
     user_value 1
     # value_source user
     # Default value: 0
     # Requires: !CYGPKG_KERNEL_SMP_SUPPORT
     #     CYGPKG_KERNEL_SMP_SUPPORT == 0
     #   --> 1

     # The following properties are affected by this value
     # option CYGPRI_KERNEL_SCHED_IMPL_HXX
     #     Calculated:   CYGSEM_KERNEL_SCHED_BITMAP  ?  
"<cyg/kernel/bitmap.hxx>"  : CYGSEM_KERNEL_SCHED_MLQUEUE ?  
"<cyg/kernel/mlqueue.hxx>" : CYGSEM_KERNEL_SCHED_LOTTERY ?  
"<cyg/kernel/lottery.hxx>" : "!!!-- Configuration broken - no scheduler  
selected --!!!"
     # component CYGSEM_KERNEL_SCHED_TIMESLICE
     #     Requires: !CYGSEM_KERNEL_SCHED_BITMAP
};

I do not understand this message. Could someone please explain me its  
meaning - and what to do about it. Thank you.
    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] priority of main thread

[Jonathan Larmour]

Robert Brusa wrote:
> On Mon, 24 Nov 2008 09:02:54 +0100, Robert Brusa <Bob.Brusa@gmail.com>  
> wrote:
> 
>> On Fri, 21 Nov 2008 15:57:31 +0100, Jonathan Larmour  
>> <jifl@ecoscentric.com> wrote:
>>
>>> Gary Thomas wrote:
>>
>> ...cut....
>>
>>>
>>> Actually it only gets started from cyg_user_start() if the user enables
>>> CYGSEM_LIBC_STARTUP_MAIN_INITCONTEXT. But that is only the default 
>>> if  there
>>> is no eCos kernel at all.
>>>
>>> Otherwise (in the more normal case), it is created and started from a
>>> static constructor. So overriding cyg_user_start() makes no difference.
>>>
>>> To answer the poster's question, the priority is set with the
>>> CYGNUM_LIBC_MAIN_THREAD_PRIORITY configuration option in the
>>> CYGPKG_LIBC_STARTUP ("ISO environment startup/termination") package.
>>>
>>> Jifl
>>
>> Thank you all for your help. "no eCOS kernel at all" That was the 
>> point.  Somehow, the configuration I was working with was broken. This 
>> went  unnoticed, because I run config with the -i option, because my 
>> system  uses a 25 MHz crystal and this was considered illegal 
>> sometimes earlier  (but now is perfectly ok according to the data 
>> sheet). Anyway, I got  tired looking at the ever same error message 
>> about this quarz - and  stopped looking at the output. And voilà - it 
>> caught me!
>> Again - thanks for all your help.
>>     Robert
>>
> The problem is not so simple: I went back and created ecos.ecc from the  
> original CVS (ecos-2.x downloaded in June 08). The config commands used  
> are then:
> ecosconfig new at91sam7xek default
> ecosconfig add CYGPKG_IO_FLASH
> ecosconfig add CYGPKG_IO_SPI
> ecosconfig -i tree
> ecosconfig --verbose check
> make
> 
> When inspecting my ecos.ecc I find the "configuration broken"-message. 
> I  change from the default ML-scheduler to the bitmap schedule. The  
> broken-message persists:
> 
> cdl_option CYGSEM_KERNEL_SCHED_BITMAP {
>     # Flavor: bool
>     user_value 1
>     # value_source user
>     # Default value: 0
>     # Requires: !CYGPKG_KERNEL_SMP_SUPPORT
>     #     CYGPKG_KERNEL_SMP_SUPPORT == 0
>     #   --> 1
> 
>     # The following properties are affected by this value
>     # option CYGPRI_KERNEL_SCHED_IMPL_HXX
>     #     Calculated:   CYGSEM_KERNEL_SCHED_BITMAP  ?  
> "<cyg/kernel/bitmap.hxx>"  : CYGSEM_KERNEL_SCHED_MLQUEUE ?  
> "<cyg/kernel/mlqueue.hxx>" : CYGSEM_KERNEL_SCHED_LOTTERY ?  
> "<cyg/kernel/lottery.hxx>" : "!!!-- Configuration broken - no scheduler  
> selected --!!!"
>     # component CYGSEM_KERNEL_SCHED_TIMESLICE
>     #     Requires: !CYGSEM_KERNEL_SCHED_BITMAP
> };
> 
> I do not understand this message. Could someone please explain me its  
> meaning - and what to do about it. Thank you.

There's no problem here that I can see. That message is not being reported 
to you as such, that line is purely informative. Instead it is saying that 
the CYGPRI_KERNEL_SCHED_IMPL_HXX option is affected by the option 
CYGSEM_KERNEL_SCHED_BITMAP. And the reason it is affected is because the 
value of the CYGPRI_KERNEL_SCHED_IMPL_HXX is calculated as having the value:

CYGSEM_KERNEL_SCHED_BITMAP  ?  "<cyg/kernel/bitmap.hxx>"  : 
CYGSEM_KERNEL_SCHED_MLQUEUE ?  "<cyg/kernel/mlqueue.hxx>" : 
CYGSEM_KERNEL_SCHED_LOTTERY ?  "<cyg/kernel/lottery.hxx>" : "!!!-- 
Configuration broken - no scheduler  selected --!!!"

That is one long expression. Since you have enabled 
CYGSEM_KERNEL_SCHED_BITMAP the other cases of that expression don't have 
any effect.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine

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