Hi group,
The subject says it all :-) Where are these priority values defined? I
could not find them, and well, I would need something "in between" the two.
TIA
Markus
Crossworks - ctl_set_isr() where is LOWEST_PRIORITY, HIGHEST_PRIORITY etc. defined?
Started by ●April 24, 2008
Reply by ●April 25, 20082008-04-25
Hi Markus,
0 is the lowest, 255 is the highest - there are some words on this in
the documenation. The boiler plate CTL main function starts all tasks
at priority 255 and then drops to priority 0 to let everything go and
become the idle task.
Regards
Michael
>
> Hi group,
>
> The subject says it all :-) Where are these priority values defined? I
> could not find them, and well, I would need something "in between"
the two.
>
> TIA
>
> Markus
>
0 is the lowest, 255 is the highest - there are some words on this in
the documenation. The boiler plate CTL main function starts all tasks
at priority 255 and then drops to priority 0 to let everything go and
become the idle task.
Regards
Michael
>
> Hi group,
>
> The subject says it all :-) Where are these priority values defined? I
> could not find them, and well, I would need something "in between"
the two.
>
> TIA
>
> Markus
>
Reply by ●April 25, 20082008-04-25
--- In l..., "nutleycottage" wrote:
>
> Hi Markus,
>
> 0 is the lowest, 255 is the highest - there are some words on this in
> the documenation. The boiler plate CTL main function starts all tasks
> at priority 255 and then drops to priority 0 to let everything go and
> become the idle task.
>
> Regards
> Michael
> >
I think that the OP is asking about interrupt priorities. Interrupt
priorities<>thread priorities.
IIRC, the interrupt priority is controlled by the position of the
entry in the vector table? (I have forgotten!). It is only relevant
during interrupts.
The thread priority is an attribute of the thread and used by the
scheduler in its dispatching algorithm to decide which ready thread to
make running. It is only relevant after interrupts have exited.
Rgds,
Martin
>
> Hi Markus,
>
> 0 is the lowest, 255 is the highest - there are some words on this in
> the documenation. The boiler plate CTL main function starts all tasks
> at priority 255 and then drops to priority 0 to let everything go and
> become the idle task.
>
> Regards
> Michael
> >
I think that the OP is asking about interrupt priorities. Interrupt
priorities<>thread priorities.
IIRC, the interrupt priority is controlled by the position of the
entry in the vector table? (I have forgotten!). It is only relevant
during interrupts.
The thread priority is an attribute of the thread and used by the
scheduler in its dispatching algorithm to decide which ready thread to
make running. It is only relevant after interrupts have exited.
Rgds,
Martin
Reply by ●April 25, 20082008-04-25
> I think that the OP is asking about interrupt
priorities. Interrupt
> priorities<>thread priorities.
>
Exactly. In fact, I wonder if Crossworks is having more predefined
vaules for the priority parameter of this call. Anyone?
Markus
> priorities<>thread priorities.
>
Exactly. In fact, I wonder if Crossworks is having more predefined
vaules for the priority parameter of this call. Anyone?
Markus
Reply by ●April 25, 20082008-04-25
> Exactly. In fact, I wonder if Crossworks is having
more predefined
> vaules for the priority parameter of this call. Anyone?
>
> Markus
>
I would like to know too. I'm afraid to admit that I chose values
'that worked'. I am not at work now and I can't remember which I
used. The actual priority levels were not that important to me in my
app - all my interrupt handlers all use the same queue to get & return
buffers & so I cannot allow nested interrupts, (I have no critical
need for ultra-fast interrupt handling, so it does not matter - as
long as they happen eventually, I will be fine).
I think I used 6 & 7 for the UARTs and maybee 12 & 13 for the CAN. I
will have to look at my code to be sure.
Some values did not work, (ie crashed/locked or interrupts did not
happen), but again, I don't remember which they were - I just changed
them till everything worked OK :)
Rgds,
Martin
> vaules for the priority parameter of this call. Anyone?
>
> Markus
>
I would like to know too. I'm afraid to admit that I chose values
'that worked'. I am not at work now and I can't remember which I
used. The actual priority levels were not that important to me in my
app - all my interrupt handlers all use the same queue to get & return
buffers & so I cannot allow nested interrupts, (I have no critical
need for ultra-fast interrupt handling, so it does not matter - as
long as they happen eventually, I will be fine).
I think I used 6 & 7 for the UARTs and maybee 12 & 13 for the CAN. I
will have to look at my code to be sure.
Some values did not work, (ie crashed/locked or interrupts did not
happen), but again, I don't remember which they were - I just changed
them till everything worked OK :)
Rgds,
Martin
Reply by ●April 25, 20082008-04-25
I meanwhile found out that:
HIGHEST_PRIORITY equals 1
LOWEST_PRIORITY equals 15
The priority value has to be written into the vector priority register
of the corresponding VIC table. The LPC23xx user manual says:
<------ snip ------->
Vector Priority Registers 0-31 (VICVectPriority0-31 - 0xFFFF F200 to 27C)
These registers select a priority level for the 32 vectored IRQs. There
are 16 priority
levels, corresponding to the values 0 through 15 decimal, of which 15 is
the lowest priority.
The reset value of these registers defaults all interrupt to the lowest
<------ snip ------->
What's interesting about this is that the highest value seem to be '0'
as oposed to what CrossWorks has
defined. I meanwhile was able to locate the corresponding source code of
ctl_set_isr() however, as strange
as this currently seem to me, the constants seem to be defined in a file
not ending with .h or .c or .s. At least I was
not able to find it in the CrossWork file tree using a recursive grep
operation. Anyways, I know now that the value
can go from 0 to 15. I just wonder why the Crosswork people were
choosing 1 as the highest value. Maybe we
hear from them? Paul?
Markus
mjames_doveridge schrieb:
>
> > Exactly. In fact, I wonder if Crossworks is having more predefined
> > vaules for the priority parameter of this call. Anyone?
> >
> > Markus
> > I would like to know too. I'm afraid to admit that I chose values
> 'that worked'. I am not at work now and I can't remember which I
> used. The actual priority levels were not that important to me in my
> app - all my interrupt handlers all use the same queue to get & return
> buffers & so I cannot allow nested interrupts, (I have no critical
> need for ultra-fast interrupt handling, so it does not matter - as
> long as they happen eventually, I will be fine).
>
> I think I used 6 & 7 for the UARTs and maybee 12 & 13 for the CAN. I
> will have to look at my code to be sure.
>
> Some values did not work, (ie crashed/locked or interrupts did not
> happen), but again, I don't remember which they were - I just changed
> them till everything worked OK :)
>
> Rgds,
> Martin
>
>
HIGHEST_PRIORITY equals 1
LOWEST_PRIORITY equals 15
The priority value has to be written into the vector priority register
of the corresponding VIC table. The LPC23xx user manual says:
<------ snip ------->
Vector Priority Registers 0-31 (VICVectPriority0-31 - 0xFFFF F200 to 27C)
These registers select a priority level for the 32 vectored IRQs. There
are 16 priority
levels, corresponding to the values 0 through 15 decimal, of which 15 is
the lowest priority.
The reset value of these registers defaults all interrupt to the lowest
<------ snip ------->
What's interesting about this is that the highest value seem to be '0'
as oposed to what CrossWorks has
defined. I meanwhile was able to locate the corresponding source code of
ctl_set_isr() however, as strange
as this currently seem to me, the constants seem to be defined in a file
not ending with .h or .c or .s. At least I was
not able to find it in the CrossWork file tree using a recursive grep
operation. Anyways, I know now that the value
can go from 0 to 15. I just wonder why the Crosswork people were
choosing 1 as the highest value. Maybe we
hear from them? Paul?
Markus
mjames_doveridge schrieb:
>
> > Exactly. In fact, I wonder if Crossworks is having more predefined
> > vaules for the priority parameter of this call. Anyone?
> >
> > Markus
> > I would like to know too. I'm afraid to admit that I chose values
> 'that worked'. I am not at work now and I can't remember which I
> used. The actual priority levels were not that important to me in my
> app - all my interrupt handlers all use the same queue to get & return
> buffers & so I cannot allow nested interrupts, (I have no critical
> need for ultra-fast interrupt handling, so it does not matter - as
> long as they happen eventually, I will be fine).
>
> I think I used 6 & 7 for the UARTs and maybee 12 & 13 for the CAN. I
> will have to look at my code to be sure.
>
> Some values did not work, (ie crashed/locked or interrupts did not
> happen), but again, I don't remember which they were - I just changed
> them till everything worked OK :)
>
> Rgds,
> Martin
>
>
Reply by ●April 25, 20082008-04-25
--- In l..., "mjames_doveridge" wrote:
>
> > Exactly. In fact, I wonder if Crossworks is having more
predefined
> > vaules for the priority parameter of this call. Anyone?
> >
> > Markus
> > I would like to know too.
> Rgds,
> Martin
>
Guys - This is one of the "crossy" features of Crossworks. The range
of allowable priority numbers depends entirely on the flavor of VIC
you are using. You should check out the source of ctl_set_isr() for
your particular VIC [generally in a file called 'vic.c'
or 'vic_pl192.c', depending... ] and the user's manual for your chip.
Highest priority # for VIC interrupts is 0, which in stock CTL code
is snarfed up by the tick timer. Lowest priority is set by the
design of the VIC, generally 16 or 32.
HTH,
MM
>
> > Exactly. In fact, I wonder if Crossworks is having more
predefined
> > vaules for the priority parameter of this call. Anyone?
> >
> > Markus
> > I would like to know too.
> Rgds,
> Martin
>
Guys - This is one of the "crossy" features of Crossworks. The range
of allowable priority numbers depends entirely on the flavor of VIC
you are using. You should check out the source of ctl_set_isr() for
your particular VIC [generally in a file called 'vic.c'
or 'vic_pl192.c', depending... ] and the user's manual for your chip.
Highest priority # for VIC interrupts is 0, which in stock CTL code
is snarfed up by the tick timer. Lowest priority is set by the
design of the VIC, generally 16 or 32.
HTH,
MM
Reply by ●April 25, 20082008-04-25
> operation. Anyways, I know now that the value
> can go from 0 to 15. I just wonder why the Crosswork people were
> choosing 1 as the highest value. Maybe we
> hear from them? Paul?
>
Perhaps 0 is reserved for something, maybee Timer0 that is used for
the ctl OS timer interrupt?
Rgds,
Martin
> can go from 0 to 15. I just wonder why the Crosswork people were
> choosing 1 as the highest value. Maybe we
> hear from them? Paul?
>
Perhaps 0 is reserved for something, maybee Timer0 that is used for
the ctl OS timer interrupt?
Rgds,
Martin
Reply by ●April 25, 20082008-04-25
Markus,
> I meanwhile found out that:
>
> HIGHEST_PRIORITY equals 1
> LOWEST_PRIORITY equals 15
...for a specific implementation, yes. Each chip has its own idea of
priority.
> I know now that the value can go from 0 to 15.
...for a specific LPC. Some devices have cascaded VICs. Some have "bigger"
VICs.
> I just wonder why the Crosswork people were choosing 1 as the highest
value. Maybe we
> hear from them? Paul?
Because 0 is taken by the CTL timer ISR, see ctl_start_timer in LPC210x.c
(for instance).
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
> I meanwhile found out that:
>
> HIGHEST_PRIORITY equals 1
> LOWEST_PRIORITY equals 15
...for a specific implementation, yes. Each chip has its own idea of
priority.
> I know now that the value can go from 0 to 15.
...for a specific LPC. Some devices have cascaded VICs. Some have "bigger"
VICs.
> I just wonder why the Crosswork people were choosing 1 as the highest
value. Maybe we
> hear from them? Paul?
Because 0 is taken by the CTL timer ISR, see ctl_start_timer in LPC210x.c
(for instance).
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Reply by ●April 25, 20082008-04-25
Paul,
Thanks for sheeding light on this. I don't need it anymore cause it's
easy enough to just use some middle value for my purpose, but out of
curiosity, I use an LPC2378 based project. Where are the two constants
then defined?
TIA
Markus
Paul Curtis schrieb:
>
> Markus,
>
> > I meanwhile found out that:
> >
> > HIGHEST_PRIORITY equals 1
> > LOWEST_PRIORITY equals 15
>
> ...for a specific implementation, yes. Each chip has its own idea of
> priority.
>
> > I know now that the value can go from 0 to 15.
>
> ...for a specific LPC. Some devices have cascaded VICs. Some have "bigger"
> VICs.
>
> > I just wonder why the Crosswork people were choosing 1 as the highest
> value. Maybe we
> > hear from them? Paul?
>
> Because 0 is taken by the CTL timer ISR, see ctl_start_timer in LPC210x.c
> (for instance).
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
>
Thanks for sheeding light on this. I don't need it anymore cause it's
easy enough to just use some middle value for my purpose, but out of
curiosity, I use an LPC2378 based project. Where are the two constants
then defined?
TIA
Markus
Paul Curtis schrieb:
>
> Markus,
>
> > I meanwhile found out that:
> >
> > HIGHEST_PRIORITY equals 1
> > LOWEST_PRIORITY equals 15
>
> ...for a specific implementation, yes. Each chip has its own idea of
> priority.
>
> > I know now that the value can go from 0 to 15.
>
> ...for a specific LPC. Some devices have cascaded VICs. Some have "bigger"
> VICs.
>
> > I just wonder why the Crosswork people were choosing 1 as the highest
> value. Maybe we
> > hear from them? Paul?
>
> Because 0 is taken by the CTL timer ISR, see ctl_start_timer in LPC210x.c
> (for instance).
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
>
