is there a way to support one cpu without NVIC ?
You can support interrupt nesting using global interrupt disables, or [ideally] any register on the CPU or interrupt controller that allows a subset of interrupts to be masked - see my reply to your other post.
Interrupts will only nest if your hardware allows them to nest and if interrupts are enabled (you are outside of a critical section). It might be that you have to manually re-enabled interrupts in the ISR if your hardware disables interrupts before starting to execute the ISR.
yes, you are right…my cpu disable interrupts automatically before starting to execute the ISR …it I enable interrupt in ISR , it will bring new issue. that is current cpu execute a lower interrupt ISR, then timer interrupt (its priority is higher than the current interrupt) happen and cpu enter timer interrupt ISR, and yeild task(PendSV trap is software trap which is higher than interrupt), the current interrupt ISR cann’t be over normally…am I right ?
but in NVIC mode, PendSV is in lower priority, it will start to execute before current interrupt over… that why its interrupt can be nested.
Are you sure you want to implement interrupt nesting? On smaller MCUs
it can be faster to keep the interrupts as short as possible, deferring
any longer processing that needs to be done to a task.
I only want to know if it can support interrupt nesting in those type of cpu without NVIC, in fact, I saw more porting code doesn’t support interrupt nesting in FreeRTOS GCC folder
If you only have the ability to globally enable and disable interrupts,
rather than having the ability to simply mask off a subset of interrupt
priorities, then it is still possible to support interrupt nesting, but
it because a more detailed conversation about the capabilities of the
hardware. For example:
Does the hardware itself support interrupt nesting.
If you re-enable interrupts inside an ISR and a lower priority
interrupt is received by the hardware, what does it do? Accept it
immediately anyway, hold it pending, loose it, etc.?
Then there are questions about how you are going to perform context
switches from nested interrupts - you may need to manually count the
nesting depth and only context switch when the nesting count reaches
zero again, which means adding assembly code to the beginning and end of
each ISR, etc. It is all very hardware dependent.
if the interrupt controller has a mask register to mask subset of interrupt (not priority) which only disable subset of interrupt. how should I do ?
my cpu can’t save and restore context by hardware, it is done when enter ISR and exit ISR. so I think it has no capability for the only way you are saying .
having the ability to simply mask off a subset of interrupt priorities which means a register which can rearrange interrupt priority in stead of interrupt mask register ?
if a cpu has no sys tick trap, it must use timer interrupt as systick trap. there are two case.
so, could I think one cpu whithout system tick trap can’t support iinterrupt nesting ?
I dont understand your question but if the timer is the tick timer then it should be at the lowest priority.
the cpu has no priority register to make timer interrupt in lower priority
there is no way to put timer interrupt priority in lower priority… what happen ?
Do you really need interrupts to nest? Looks like it is going to be hard work on your processor.
Without a NVIC (or similar hardware) there is no natural order to interrupts, so you can’t natively let interrrupts nest. If you want to make the system allow interrupt nesting, then YOU need to provide code such that while in interrupt Y, it can be interrupted by interrupt Z but not by interrupt X where YOUR logical interrupt priority is X lower than Y and Z higher than Y. FreeRTOS assumes that the TimerTick interrupt is the lowest priority, so it can’t interrupt any other ISRs.
To do this nesting, YOU need to have code that when you enter interrupt Y, it saves enough context so it knows how to get back to the current state, then disables all interrupts of priorities up to Y, and THEN it can reenable the interrupts. When interrupt Y is done, it needs to restore the interrupt settings to what they were like when the interrupt entered. Note, this DOESN’T mean automatically reenabling all interrupts, as Y may have been nexting with X, so if so, it only wants to reenble from X+1 to Y.
This may well be a LOT of work to do this, and as Dave asked, is it really needed. You only need nesting when ‘low priority’ interrupts might take longer than the required response time of some high priority interrupt. One good design policy to prevent this is to keep the ISRs quick, and push to task level anything that requires real work.