* [ECOS] priority of main thread
@ 2008-11-20 15:34 Robert Brusa
2008-11-20 16:02 ` Gary Thomas
2008-11-20 16:03 ` Andrew Lunn
0 siblings, 2 replies; 9+ messages in thread
From: Robert Brusa @ 2008-11-20 15:34 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] priority of main thread
2008-11-20 15:34 [ECOS] priority of main thread Robert Brusa
@ 2008-11-20 16:02 ` Gary Thomas
2008-11-20 16:06 ` Robert Brusa
2008-11-20 16:03 ` Andrew Lunn
1 sibling, 1 reply; 9+ messages in thread
From: Gary Thomas @ 2008-11-20 16:02 UTC (permalink / raw)
To: Bob.Brusa; +Cc: MailingList:ecos-discuss ;
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] priority of main thread
2008-11-20 15:34 [ECOS] priority of main thread Robert Brusa
2008-11-20 16:02 ` Gary Thomas
@ 2008-11-20 16:03 ` Andrew Lunn
1 sibling, 0 replies; 9+ messages in thread
From: Andrew Lunn @ 2008-11-20 16:03 UTC (permalink / raw)
To: Robert Brusa; +Cc: ecos-discuss
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] priority of main thread
2008-11-20 16:02 ` Gary Thomas
@ 2008-11-20 16:06 ` Robert Brusa
2008-11-20 18:42 ` Gary Thomas
0 siblings, 1 reply; 9+ messages in thread
From: Robert Brusa @ 2008-11-20 16:06 UTC (permalink / raw)
To: Gary Thomas; +Cc: MailingList:ecos-discuss ;
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] priority of main thread
2008-11-20 16:06 ` Robert Brusa
@ 2008-11-20 18:42 ` Gary Thomas
2008-11-21 18:07 ` Jonathan Larmour
0 siblings, 1 reply; 9+ messages in thread
From: Gary Thomas @ 2008-11-20 18:42 UTC (permalink / raw)
To: Bob.Brusa; +Cc: MailingList:ecos-discuss ;
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] priority of main thread
2008-11-20 18:42 ` Gary Thomas
@ 2008-11-21 18:07 ` Jonathan Larmour
2008-11-24 11:06 ` Robert Brusa
0 siblings, 1 reply; 9+ messages in thread
From: Jonathan Larmour @ 2008-11-21 18:07 UTC (permalink / raw)
To: Gary Thomas; +Cc: Bob.Brusa, eCos discussion
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] priority of main thread
2008-11-21 18:07 ` Jonathan Larmour
@ 2008-11-24 11:06 ` Robert Brusa
2008-11-24 11:53 ` Robert Brusa
0 siblings, 1 reply; 9+ messages in thread
From: Robert Brusa @ 2008-11-24 11:06 UTC (permalink / raw)
To: Jonathan Larmour, Gary Thomas; +Cc: eCos discussion
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] priority of main thread
2008-11-24 11:06 ` Robert Brusa
@ 2008-11-24 11:53 ` Robert Brusa
2008-11-24 12:57 ` Jonathan Larmour
0 siblings, 1 reply; 9+ messages in thread
From: Robert Brusa @ 2008-11-24 11:53 UTC (permalink / raw)
To: Bob.Brusa, Jonathan Larmour, Gary Thomas; +Cc: eCos discussion
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] priority of main thread
2008-11-24 11:53 ` Robert Brusa
@ 2008-11-24 12:57 ` Jonathan Larmour
0 siblings, 0 replies; 9+ messages in thread
From: Jonathan Larmour @ 2008-11-24 12:57 UTC (permalink / raw)
To: Bob.Brusa; +Cc: eCos discussion
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-11-24 11:15 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-11-20 15:34 [ECOS] priority of main thread Robert Brusa
2008-11-20 16:02 ` Gary Thomas
2008-11-20 16:06 ` Robert Brusa
2008-11-20 18:42 ` Gary Thomas
2008-11-21 18:07 ` Jonathan Larmour
2008-11-24 11:06 ` Robert Brusa
2008-11-24 11:53 ` Robert Brusa
2008-11-24 12:57 ` Jonathan Larmour
2008-11-20 16:03 ` Andrew Lunn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).