zhuchunxia wrote on Tuesday, June 21, 2016:
HI:
is there a way to support one cpu without NVIC ?
rtel wrote on Tuesday, June 21, 2016:
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.
zhuchunxia wrote on Wednesday, June 22, 2016:
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.
rtel wrote on Wednesday, June 22, 2016:
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.
zhuchunxia wrote on Wednesday, June 22, 2016:
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
rtel wrote on Wednesday, June 22, 2016:
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.
zhuchunxia wrote on Wednesday, June 22, 2016:
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 .
zhuchunxia wrote on Wednesday, June 22, 2016:
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 ?
zhuchunxia wrote on Wednesday, June 22, 2016:
if a cpu has no sys tick trap, it must use timer interrupt as systick trap. there are two case.
- those interrupt which 's priority higher than timer interrupt will interrupt timer ISR, does it make sense ?
- those interrupt which’s priority lower than timer interrupt will be interrupted by timer interrupt… it is not allowed as timer ISR might issue a Yield task trap.
so, could I think one cpu whithout system tick trap can’t support iinterrupt nesting ?
davedoors wrote on Wednesday, June 22, 2016:
I dont understand your question but if the timer is the tick timer then it should be at the lowest priority.
zhuchunxia wrote on Thursday, June 23, 2016:
the cpu has no priority register to make timer interrupt in lower priority
zhuchunxia wrote on Thursday, June 23, 2016:
there is no way to put timer interrupt priority in lower priority… what happen ?
davedoors wrote on Thursday, June 23, 2016:
Do you really need interrupts to nest? Looks like it is going to be hard work on your processor.
richard_damon wrote on Friday, June 24, 2016:
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.