Yes, I understand the idea. Although the manufacturer's decision to save slots in such a powerful controller, simply based on the fact that more than 16 interrupts will not have to be processed, seems unfortunate against the background of the complexity of configuring interrupt handling. Especially considering the documentation is not very clear.
But okay, I'm glad you helped me figure it out.
But I still don't understand this phrase: "but this means that if you add more code that uses interrupts later something else might try to use the same slot and will replace your interrupt". How is this possible? If I write the code myself, select the peripheral modules myself, and assign the handlers to specific interrupt sources myself, then who can "come and interfere"?
And one more question, if you don't mind. Why does this function work correctly, since the slot addresses have an increment of 4, not 1?
// function for IELSR slots checking
void listEventLinks()
{
for (uint8_t i = 0; i < 32; i++)
{
volatile uint32_t val = *(ICU_IELSR00 + (i));
Serial.print("IELSR");
Serial.print(i);
Serial.print(" : ");
Serial.println(val, HEX);
}
}
The alternative is that you can only have 16 possible interrupt sources. On a chip with so many powerful peripherals this would be an unacceptable limit. If they're going to allow for more interrupt sources then there has to be a way to choose which interrupt sources you are going to use.
You are completely misunderstanding this. This isn't some oversight or poor design. This is the next step that allows you to have extra capability.
It was perfectly clear to me. What are you reading? Are you looking at the processor user manual? That's where the good info is.
Perhaps you use a library and that library calls to attach an interrupt in the normal way. When you started the program the IRQManager put the AGT0 interrupt in slot 0 and maybe two serial interrupts in 1 and 2. Now you come along and claim slot 3 for an ADC interrupt. Then your code calls some library that attaches another interrupt in the same way. The IRQManager knows about the first three interrupts, so it assumes that the next open slot is slot 3. It doesn't know that you've attached an interrupt there. Your interrupt isn't in the list it's keeping. So it dutifully puts the new interrupt in slot 3 and covers yours up.
It could be as simple as calling Serial.begin in the wrong place.
That's why we let the IRQManager handle assigning the vector table. You need one piece of code doing that.
You're so far off the reservation with this one that I'm not going to consider why it does what it does. If you use the code correctly then things work correctly. If you work by coding things the way YOU think they SHOULD work instead of how they actually do work then you're just going to continue to have problems.
This is not that hard and it's not that complicated, but it does require that you stop thinking about things in terms of how the lower power chips work.
Why? What prevented the developers from adding more interrupt slots to such a powerful chip? This is where you wouldn't expect savings.
It was perfectly clear to me. What are you reading? Are you looking at the processor user manual? That's where the good info is.
I am happy for you. And this is what I am reading. You may have read the documentation for Microchip's PIC chips. I consider it the standard of quality documentation. ST is also doing well. And about Renesas, this is not just my opinion, but let's assume that I am simply inattentive.
When you started the program the IRQManager...
No, you misunderstood. I didn't mean using IRQManager at all.
You're so far off the reservation with this one that I'm not going to consider why it does what it does.
OK, I see that I'm annoying you with my questions. Sorry. After all, I came here for help, not to argue. Thank you again and all the best.
You'd have to ask someone at Renesas why those engineering decisions were made. It probably had something to do with the space on the silicon and all the other things they wanted to add. It's a very common way of handling things whether you're used to it or not.
Again, this is a complaint you should take up with Renesas and not me. I've got no horse in that race. I read the hardware users manual and followed the flow charts there. It's not the best but there's enough there to at least understand what's going on. Check out the manual for the FSP too. This thread has links to both.
You don't have a choice. When your program starts, the Arduino core is going to attach the AGT0 underflow interrupt before your code ever starts. If you call Serial.begin then at least two maybe four more interrupts get attached by the core and that's done through IRQManager.
The IRQManager class is like the hotel desk clerk handing out rooms. You have to have one central point for that to happen. If you have three different people handing out rooms and they aren't coordinating, then pretty soon two people end up being given the same room and chaos ensues.
No, I only mean that the snippet you posted isn't legible as code that would work in any fashion I know. Without seeing a complete piece there and being able to run it myself I can't tell you what is happening there. I know that isn't how one would normally address that register in code so I don't really know what it ends up pointing to. I also can't see the output so I don't know what actually happened.
What I do know is that in your attempt to solve your problem you came upon the same hack I did a year ago. What you may not have known was that in the intervening time I had gone and added the fix to the Arduino core making that hack unnecessary. The fix also solved a potential bug that was present if said hack wasn't used carefully.
It was a clever hack. @susan-parker and I sort of discovered it separately and used in slightly different ways. But at the end of the day a fix was made and a function was added that allows you to easily attach and manage any interrupt. There's just a slightly different pattern to follow than what you might be used to.
Also note that nothing is being "searched for". We're just using a macro so it doesn't need to be hard coded as a number. This adds flexibility to the code and it is a good thing.
What you also may be unaware of, and it sort of makes this whole thing a moot point, is that the Arduino core already has functions to attach the interrupt you want to use. No need to reinvent this wheel:
Absolutely. If you got the impression that this is some kind of reproach or claim against you, then I'm sorry.
No, I only mean that the snippet you posted isn't legible as code that would work in any fashion I know. Without seeing a complete piece there and being able to run it myself I can't tell you what is happening there. I know that isn't how one would normally address that register in code so I don't really know what it ends up pointing to. I also can't see the output so I don't know what actually happened.
That code wasn't about something you'd need to do. That was me trying to figure out how the thing worked. If you keep going on that thread you get to this post which is the end of the story there.
But again, you don't need this. The Arduino core already has functions to attach the ADC interrupts.
The way I did it wasn't using addresses. There is a file that has all of the addresses sorted out into structs and arrays. I was using the core code the way it is meant to be used.
I'm not sure what memory address you ended up looking at. Like I said, that is just a snippet and I can't see any output. It would be a waste of my time to think about it at all. If you want to post a complete example that I can try and see the output from, then maybe I could explain it to you.
I have a feeling that you're just suffering from a complete misunderstanding of how this very different core is put together and you're trying to understand things in terms of a different processor that you do understand. I fell victim to the same thing when I first started looking at the R4. But that approach did not work.
And I naively thought you were familiar with it. My mistake. Okay, don't pay attention, I don't want you to waste your time.
Dear friend! I appreciate your concern, but let's not get carried away by generalizations and psychology. This is a technical forum and I am solving a technical problem in the same way as you did in your time. Therefore, I find the terms "suffering" and "complete misunderstanding" extremely unacceptable here. Refrain from being a psychologist, please.
Is that core code or the stuff she wrote? Again you have to be careful what you're looking at.
I'm a coder. I have no idea how that you're offended by.
I feel like you have the answer. If you'll follow some links and do some reading you'll find that file. I know I've linked you out to a thread that talks about it.