rtel wrote on Wednesday, March 14, 2018:
Does the configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY fit the cortex M
series priority scheme?
I’m not sure I understand your question.
configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY is only for Cortex-M
devices, as far as I recall.
Let say I want to make sure interrupt prioirty 0, 1 ,2 are the highest
Which they are - that is set by hardware.
and don’t get disable my the RTOS. Therefore interrupt 3 through 15 are
to be disable.
Ok - if you have 15 priorities only, then your MCU has 4 priority bits
(not all Cortex-M devices have the same number of priority bits).
Note
- I am using ARM scheme when referenceing priorities here. i.e. Low
numerical numbers are high priorities.
*So I set *
/configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY = 3
*OR */ configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY (15 - 3) =12
There are two constants that set this, you can take your pick as to
which you want to use.
First configMAX_SYSCALL_INTERRUPT_PRIORITY, which was the original
constant, and implemented before ARM provided any libraries for the
Cortex-M. That uses the ARM hardware scheme for priority setting, which
is more complex than you would think it needed to be, with an attempt to
explain it here: RTOS for ARM Cortex-M
Then there is configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY, which
defines priorities the way the ARM libraries expect it to be defined,
which is easier to understand, but unfortunately different to the way
the hardware works - so the libraries manipulate the specified
priorities before writing to the hardware registers. The main
difference is that the libraries don’t shift priorities to the highest
bits, whereas the hardware does.
The equation for working out one from the other is as follows:
#define configMAX_SYSCALL_INTERRUPT_PRIORITY (
configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS)
)
where in your case (from the information you provided) configPRIO_BITS is 4.