Reply by Paul Curtis April 25, 20082008-04-25
...oh, and if you want to search the current project:

Click Search > Find and Replace

Set: Find > HIGHEST
Set: Look in > Current Project

Click: Find All

This won't just search the project directory, it will search in your
project. Unfortunately the feature that finds pre-processor symbols and so
on, an enhancement of the source navigator, isn't in V1.

Regards,

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

> -----Original Message-----
> From: l... [mailto:l...] On
> Behalf Of Markus Zingg
> Sent: 25 April 2008 16:51
> To: l...
> Subject: Re: [lpc2000] Re: Crossworks - ctl_set_isr() where is
> LOWEST_PRIORITY, HIGHEST_PRIORITY etc. d
>
> 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
> >
> >
>

An Engineer's Guide to the LPC2100 Series

Reply by Paul Curtis April 25, 20082008-04-25
Hi,

> > HIGHEST_PRIORITY equals 1
> > LOWEST_PRIORITY equals 15
>
> 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?

I'm not sure where you're finding reference to these...

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

Reply by Markus Zingg 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
>
>
Reply by Paul Curtis 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

Reply by mjames_doveridge 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

Reply by Mike McIntyre 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

Reply by Markus Zingg 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
>
>
Reply by mjames_doveridge 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

Reply by Markus Zingg 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
Reply by mjames_doveridge 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