RE: Cortex-M3 HAL interrupt-priority code bug

["Christophe Coutand" <ccoutand@stmi.com>]

My understanding is:

CYGNUM_HAL_CORTEXM_PRIORITY_MAX is defined equal to
1<<(8-CYGNUM_HAL_CORTEXM_PRIORITY_LEVEL_BITS)

What the eCos implementation really does is to reserved level 0 for
DEBUG and SVC traps. If you call hal_interrupt_set_level with level 0
what you will really get is a priority of 1. Nothing wrong with that?

Christophe

-----Original Message-----
From: ecos-devel-owner@ecos.sourceware.org
[mailto:ecos-devel-owner@ecos.sourceware.org] On Behalf Of Nick Garnett
Sent: 25. november 2010 12:19
To: Nagaraj K
Cc: ecos-devel@ecos.sourceware.org
Subject: Re: Cortex-M3 HAL interrupt-priority code bug

Nagaraj K <nagaraj.kmurthy@gmail.com> writes:

> I see that this function wrongly implements the priority level in
> Cortex-M3 processor. According to the Cortex-M3 data sheet, we need to
> write the priority level to the top N bits of the register where N is
> the number of priority level bits implemented in this particular
> version of the cortex variant.

The intention in the design of the hardware is that software can use a
256 level prioirity scheme on all implementations. By defining the
actual priority in terms of the top N bits of the registers, the
hardware essentially groups the 256 virtual priorities into a set of
real priorities by ignoring the less significant bits.

eCos simply follows the lead given by the hardware and implements 256
priorities. It is a good scheme and allows us to write code that will
work in all implementations.

-- 
Nick Garnett                                      eCos Kernel Architect
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