NVIC

[MTS]

Hi guys. please tell me why you don't do enough NVIC? for example, when several timers are running, and it is necessary to parallelize tasks so that interrupts from each timer happen independently, but now until one interrupt comes out, the other will not be processed. with multi-core CPUs and parallel computations, it would be good if there were 2< NVIC

[Tesla DeLorean]

Doesn't each core have it's own NVIC? Aren't those documented by ARM via the TRM, and ST via the Programming Manual? The Grouping and Priority modes should facilitate orderly and preemptive interrupt processing on each.

The cores should operate reasonably independently, with common resources via dual-port memory and peripheral space. The complicated interactions and coding issues should be the material of college level classes.

The goal of most of the examples is to illustrate / prove specific functionality, not be representative of complex code you might have to write and understand for your own applications and work tasks.

[MTS]

0xE000EF00//STIR

 one register to control. what do I care just how much you've done there and what if I can't control it? now there is NO way to configure so that NVICS work independently. do you understand that? have you read the topic? I'm talking about the possibility of parallelization of interruptions. the priority of prying here was not said in the subject. in order to parallelize tasks, several NVIC and the ability to manage them are needed. there is no such possibility now.

[MTS]

---

@Tesla DeLorean wrote:

The cores should operate reasonably

---

how CPU cores work should be decided by the programmer who writes the scheduler. the operation of CPU cores should not be fixed by the manufacturer.

[Piranha]

First, if you would have read about ARM CPU cores, you would have seen their memory map and Private Peripheral Bus at 0xE0XXXXXX addresses. It's called private because it hosts the core peripherals, which are private for the CPU core. Therefore each core has it's own instance of the core peripherals.

Second, you seem to clearly lack any understanding of how interrupts work at all. NVIC doesn't execute interrupt code or any other code, because the only part, that executes code, is the processor. NVIC is just a core peripheral, which manages the interrupts.

Next time before boldly bragging about your "advanced" ideas and giving lessons to actual experts, at least learn the basics of the particular field so that it doesn't turn out as embarrassing as this time...

[MTS]

what do you want to say? professionals wouldn't do this in a microcontroller architecture. the essence of any controller is to bypass the CPU to take the load off the CPU. it doesn't matter how many cores you have in the microcontroller now, there may be 4 or more in the future, but the stm32H7 architecture itself is terrible today, it needs to be improved. the fact that your NVIC is not a real interrupt controller only means that you have not thought out the architecture well. even among the stupid ones, advice like mine can lead you indirectly to a clever idea that you will implement in the future. therefore, it is not necessary to ignore messages even from beginners like me. from the position of a beginner, I just have to say what is convenient and what is difficult. in order to be able to program your microcontrollers well, you need several NVICS, this will allow you to flexibly manage timers such as HRTIM and improved timers independently of each other. NVIC should become a real interrupt controller and not what it is now. it's bad form to brag that someone can't figure out the architecture of your microcontrollers. this is difficult to do because it is illogical and looks like chaos. there is no clear smart connection. something new with you is just new, it has nothing to do with the existing one. the interrupt controller must be able to carry out interrupts independently, then it can be called NVIC. and then you can do a lot of them and it will be useful. and now it's just an unfortunate and dead-end solution.

[MTS]

The CPU in particular, its cores only have to execute the code and the interrupts themselves are controlled by NVIC. parallelizing the code with a core or processor cores is not difficult. then all this has at least some reason. now in general it would be unclear. for example, two CPU cores and one NVIC and 4 timers. anyway, I see a queue in the code for one interrupt controller, if there were several of them, it would be better for me. the bottom line is that timers should be able to work independently . now one of the weak points is NVIC and the fact that until the CPU processes the code after one interrupt, it will not start executing the code of another interrupt on a timer. this is a problem that should have been solved a long time ago.

[KiptonM]

If I write my interrupts correctly I never have an issue.  

The secret is to get in and out of the interrupt as quickly as possible. 
Always do the minimum necessary to move the important data out of the interrupt and set a flag to tell the main process there is something to do.  That is what an interrupt should be doing. If you have to have a long interrupt, then make it lowest priority so other interrupts can still work, even though your design is bad. 

If your interrupt happens more than 50,000 times a second, then consider using the DMA to move it from the peripheral to memory, so the processor is not interrupted as often and has more time to process the data. 

Interrupts are for moving data. The main program is for processing data.

[MTS]

---

@KiptonM wrote:

The secret is to get in and out of the interrupt as quickly as possible. 

---

so that 's the problem ! the processor, its core or the core cannot handle multiple interrupts at once in any line of microcontrollers. and that would be just right. you just need several interrupt controllers and so that there is no such thing as now that until one CPU finishes executing the code on one interrupt, it will not start working on the second interrupt. this is a huge mistake and wrongness. the processor and its cores could handle multiple interrupts at once. only then would it make sense for HRTIM and timers working in conjunction.

this is a bottleneck.

[Danish1]

One problem is that the cores on a multi-core stm32 are often not the same - one an M4 and the other M0 for example. Although the M4 might be able to run code written for M0, it doesn’t reach full efficiency like that. And you can’t do it the other way round.

But if you want to achieve what you describe, remember you can have different priorities assigned to different interrupt sources, and you can arrange that high-priority ones will pre-empt i.e. interrupt low priority ones.

If you want the first-available core to take the next pending interrupt, there’s nothing stopping you from writing minimal interrupt code that captures each interrupt, silences it, then adds it to a queue that you have written (or several such queues if you want to have priority). And then have a top-priority task for each core that plucks off the highest-priority pending interrupt from that queue.

My code typically has multiple threads, each waiting on one or more flags that get set by small, fast and critically non-blocking interrupt-service-routines.

Code in those threads can be blocking, but other threads can keep the processor core(s) busy. It’s true one core might run out of work while the other still has work. But careful system design ensures nothing is missed or kept waiting too long.

For this I tend to use Rowley Crossworks’s “Crossworks Tasking Library” but I’m sure you can achieve the same effect with most RTOSs