On 1/16/2023 23:22, Lasse Langwadt Christensen wrote:> mandag den 16. januar 2023 kl. 21.53.01 UTC+1 skrev Dimiter Popoff: >> On 1/16/2023 11:10, Don Y wrote: >>> On 1/15/2023 7:10 AM, Dimiter_Popoff wrote: >>>> How many registers does it stack automatically? I knew the HLL nonsense >>>> would catch up with CPU design eventually. >>> >>> IIRC, it stacks PC, PSR, LR (i.e., R14) & R[0-3]. >> Lasse also mentioned it, I see and it makes sense; I did not realize >> this was a "small" flavour of ARM, I am not familiar with any ARM. > > now there is basically two types cortex-Mx which is a 32bit microcontroller > with increasing x features are added like DSP instructions single, and double, FPU > > and the cortex-A which is a 32/64bit cpu used in cell phones etc. > >>> >>> PC and PSR must be preserved, of course (if you have a special shadow >>> register for each, that's just an optimization -- that only works if >>> ISRs can't be interrupted. Remember, you can ALWAYS throw an exception, >>> even in an ISR! E.g. the "push" can signal a page fault). The link >>> register (think "BAL" -- what's old is now new! :> ) determines *how* >>> the ISR terminates. >> On power, you get the PC and the MSR saved in special purpose registers >> assigned to do exactly that. You have to stack them yourself, even that. >> You don't even have a stack pointer, it is up to you to assign one >> of the GPR-s to that. The 603e core maximizes delegation to a huge >> extent and this is very convenient when you know what you are doing. >> Even when you get a TLB miss, all you get is an exception plus >> r0-r3 being switched to a shadow bank, Z80 style, meant for you >> to locate the entry in the page translation table and put it in the >> TLB; if not in the table you do a page fault, go into allocation, >> swapping if needed, fixing etc., you know how it goes. You don't need >> to stack anything, the 4 regs you have are enough to do the TLB fix. >> > > look similar to the older generation ARM, ARM7-TDMI > > stack pointer was also just a GP register defined as stack pointer > > it had one IRQ, and it only shadowed the return address and status register > and an FIQ (fast) that shadowed the return address, status register, and (afair) > seven general purpose registers > > quite a bit code needed to find the interrupt source, stacking, etc. and even worse > if preemption was needed > > >
highest frequency periodic interrupt?
Started by ●January 13, 2023
Reply by ●January 16, 20232023-01-16
Reply by ●January 16, 20232023-01-16
On 1/16/2023 23:22, Lasse Langwadt Christensen wrote:> mandag den 16. januar 2023 kl. 21.53.01 UTC+1 skrev Dimiter Popoff: >> On 1/16/2023 11:10, Don Y wrote: >>> On 1/15/2023 7:10 AM, Dimiter_Popoff wrote: >>>> How many registers does it stack automatically? I knew the HLL nonsense >>>> would catch up with CPU design eventually. >>> >>> IIRC, it stacks PC, PSR, LR (i.e., R14) & R[0-3]. >> Lasse also mentioned it, I see and it makes sense; I did not realize >> this was a "small" flavour of ARM, I am not familiar with any ARM. > > now there is basically two types cortex-Mx which is a 32bit microcontroller > with increasing x features are added like DSP instructions single, and double, FPU > > and the cortex-A which is a 32/64bit cpu used in cell phones etc. > >>> >>> PC and PSR must be preserved, of course (if you have a special shadow >>> register for each, that's just an optimization -- that only works if >>> ISRs can't be interrupted. Remember, you can ALWAYS throw an exception, >>> even in an ISR! E.g. the "push" can signal a page fault). The link >>> register (think "BAL" -- what's old is now new! :> ) determines *how* >>> the ISR terminates. >> On power, you get the PC and the MSR saved in special purpose registers >> assigned to do exactly that. You have to stack them yourself, even that. >> You don't even have a stack pointer, it is up to you to assign one >> of the GPR-s to that. The 603e core maximizes delegation to a huge >> extent and this is very convenient when you know what you are doing. >> Even when you get a TLB miss, all you get is an exception plus >> r0-r3 being switched to a shadow bank, Z80 style, meant for you >> to locate the entry in the page translation table and put it in the >> TLB; if not in the table you do a page fault, go into allocation, >> swapping if needed, fixing etc., you know how it goes. You don't need >> to stack anything, the 4 regs you have are enough to do the TLB fix. >> > > look similar to the older generation ARM, ARM7-TDMI > > stack pointer was also just a GP register defined as stack pointer > > it had one IRQ, and it only shadowed the return address and status register > and an FIQ (fast) that shadowed the return address, status register, and (afair) > seven general purpose registers > > quite a bit code needed to find the interrupt source, stacking, etc. and even worse > if preemption was needed >Finding the source does not take much on SOCs with an interrupt priority encoder, they all have that one nowadays (off-core, it does only prioritize which vector will be supplied to the core which has just one IRQ line). Preemption from a hardware interrupt is a complex thing to do whatever the scheme unless the interrupt is guaranteed to be received only while running at user level. But true prioritized interrupts 68k style is a huge step forward ARM have made, this does make a difference.
Reply by ●January 16, 20232023-01-16
mandag den 16. januar 2023 kl. 22.56.54 UTC+1 skrev Dimiter Popoff:> On 1/16/2023 23:22, Lasse Langwadt Christensen wrote: > > mandag den 16. januar 2023 kl. 21.53.01 UTC+1 skrev Dimiter Popoff: > >> On 1/16/2023 11:10, Don Y wrote: > >>> On 1/15/2023 7:10 AM, Dimiter_Popoff wrote: > >>>> How many registers does it stack automatically? I knew the HLL nonsense > >>>> would catch up with CPU design eventually. > >>> > >>> IIRC, it stacks PC, PSR, LR (i.e., R14) & R[0-3]. > >> Lasse also mentioned it, I see and it makes sense; I did not realize > >> this was a "small" flavour of ARM, I am not familiar with any ARM. > > > > now there is basically two types cortex-Mx which is a 32bit microcontroller > > with increasing x features are added like DSP instructions single, and double, FPU > > > > and the cortex-A which is a 32/64bit cpu used in cell phones etc. > > > >>> > >>> PC and PSR must be preserved, of course (if you have a special shadow > >>> register for each, that's just an optimization -- that only works if > >>> ISRs can't be interrupted. Remember, you can ALWAYS throw an exception, > >>> even in an ISR! E.g. the "push" can signal a page fault). The link > >>> register (think "BAL" -- what's old is now new! :> ) determines *how* > >>> the ISR terminates. > >> On power, you get the PC and the MSR saved in special purpose registers > >> assigned to do exactly that. You have to stack them yourself, even that. > >> You don't even have a stack pointer, it is up to you to assign one > >> of the GPR-s to that. The 603e core maximizes delegation to a huge > >> extent and this is very convenient when you know what you are doing. > >> Even when you get a TLB miss, all you get is an exception plus > >> r0-r3 being switched to a shadow bank, Z80 style, meant for you > >> to locate the entry in the page translation table and put it in the > >> TLB; if not in the table you do a page fault, go into allocation, > >> swapping if needed, fixing etc., you know how it goes. You don't need > >> to stack anything, the 4 regs you have are enough to do the TLB fix. > >> > > > > look similar to the older generation ARM, ARM7-TDMI > > > > stack pointer was also just a GP register defined as stack pointer > > > > it had one IRQ, and it only shadowed the return address and status register > > and an FIQ (fast) that shadowed the return address, status register, and (afair) > > seven general purpose registers > > > > quite a bit code needed to find the interrupt source, stacking, etc. and even worse > > if preemption was needed > > > Finding the source does not take much on SOCs with an interrupt > priority encoder, they all have that one nowadays (off-core, it does > only prioritize which vector will be supplied to the core which has > just one IRQ line). > Preemption from a hardware interrupt is a complex thing to do whatever > the scheme unless the interrupt is guaranteed to be received only while > running at user level. > But true prioritized interrupts 68k style is a huge step forward ARM > have made, this does make a difference.yes, the cortex-M basically only have one IRQ like the old ARM, but a module called the Nested Vectored Interrupt Controller was added to the cortex-m that does all the decoding, vectoring, priority, stacking, unstacking thought a "back door"
Reply by ●January 16, 20232023-01-16
On 1/17/2023 0:05, Lasse Langwadt Christensen wrote:> mandag den 16. januar 2023 kl. 22.56.54 UTC+1 skrev Dimiter Popoff: >> On 1/16/2023 23:22, Lasse Langwadt Christensen wrote: >>> mandag den 16. januar 2023 kl. 21.53.01 UTC+1 skrev Dimiter Popoff: >>>> On 1/16/2023 11:10, Don Y wrote: >>>>> On 1/15/2023 7:10 AM, Dimiter_Popoff wrote: >>>>>> How many registers does it stack automatically? I knew the HLL nonsense >>>>>> would catch up with CPU design eventually. >>>>> >>>>> IIRC, it stacks PC, PSR, LR (i.e., R14) & R[0-3]. >>>> Lasse also mentioned it, I see and it makes sense; I did not realize >>>> this was a "small" flavour of ARM, I am not familiar with any ARM. >>> >>> now there is basically two types cortex-Mx which is a 32bit microcontroller >>> with increasing x features are added like DSP instructions single, and double, FPU >>> >>> and the cortex-A which is a 32/64bit cpu used in cell phones etc. >>> >>>>> >>>>> PC and PSR must be preserved, of course (if you have a special shadow >>>>> register for each, that's just an optimization -- that only works if >>>>> ISRs can't be interrupted. Remember, you can ALWAYS throw an exception, >>>>> even in an ISR! E.g. the "push" can signal a page fault). The link >>>>> register (think "BAL" -- what's old is now new! :> ) determines *how* >>>>> the ISR terminates. >>>> On power, you get the PC and the MSR saved in special purpose registers >>>> assigned to do exactly that. You have to stack them yourself, even that. >>>> You don't even have a stack pointer, it is up to you to assign one >>>> of the GPR-s to that. The 603e core maximizes delegation to a huge >>>> extent and this is very convenient when you know what you are doing. >>>> Even when you get a TLB miss, all you get is an exception plus >>>> r0-r3 being switched to a shadow bank, Z80 style, meant for you >>>> to locate the entry in the page translation table and put it in the >>>> TLB; if not in the table you do a page fault, go into allocation, >>>> swapping if needed, fixing etc., you know how it goes. You don't need >>>> to stack anything, the 4 regs you have are enough to do the TLB fix. >>>> >>> >>> look similar to the older generation ARM, ARM7-TDMI >>> >>> stack pointer was also just a GP register defined as stack pointer >>> >>> it had one IRQ, and it only shadowed the return address and status register >>> and an FIQ (fast) that shadowed the return address, status register, and (afair) >>> seven general purpose registers >>> >>> quite a bit code needed to find the interrupt source, stacking, etc. and even worse >>> if preemption was needed >>> >> Finding the source does not take much on SOCs with an interrupt >> priority encoder, they all have that one nowadays (off-core, it does >> only prioritize which vector will be supplied to the core which has >> just one IRQ line). >> Preemption from a hardware interrupt is a complex thing to do whatever >> the scheme unless the interrupt is guaranteed to be received only while >> running at user level. >> But true prioritized interrupts 68k style is a huge step forward ARM >> have made, this does make a difference. > > yes, the cortex-M basically only have one IRQ like the old ARM, > but a module called the Nested Vectored Interrupt Controller was added > to the cortex-m that does all the decoding, vectoring, priority, stacking, unstacking thought a "back door"Wait a second, this is not like 68k. If there is just one IRQ line the external controller cannot interrupt the core while it deals with an interrupt and is still being masked. Or is there something more sophisticated in that?
Reply by ●January 16, 20232023-01-16
mandag den 16. januar 2023 kl. 23.31.19 UTC+1 skrev Dimiter Popoff:> On 1/17/2023 0:05, Lasse Langwadt Christensen wrote: > > mandag den 16. januar 2023 kl. 22.56.54 UTC+1 skrev Dimiter Popoff: > >> On 1/16/2023 23:22, Lasse Langwadt Christensen wrote: > >>> mandag den 16. januar 2023 kl. 21.53.01 UTC+1 skrev Dimiter Popoff: > >>>> On 1/16/2023 11:10, Don Y wrote: > >>>>> On 1/15/2023 7:10 AM, Dimiter_Popoff wrote: > >>>>>> How many registers does it stack automatically? I knew the HLL nonsense > >>>>>> would catch up with CPU design eventually. > >>>>> > >>>>> IIRC, it stacks PC, PSR, LR (i.e., R14) & R[0-3]. > >>>> Lasse also mentioned it, I see and it makes sense; I did not realize > >>>> this was a "small" flavour of ARM, I am not familiar with any ARM. > >>> > >>> now there is basically two types cortex-Mx which is a 32bit microcontroller > >>> with increasing x features are added like DSP instructions single, and double, FPU > >>> > >>> and the cortex-A which is a 32/64bit cpu used in cell phones etc. > >>> > >>>>> > >>>>> PC and PSR must be preserved, of course (if you have a special shadow > >>>>> register for each, that's just an optimization -- that only works if > >>>>> ISRs can't be interrupted. Remember, you can ALWAYS throw an exception, > >>>>> even in an ISR! E.g. the "push" can signal a page fault). The link > >>>>> register (think "BAL" -- what's old is now new! :> ) determines *how* > >>>>> the ISR terminates. > >>>> On power, you get the PC and the MSR saved in special purpose registers > >>>> assigned to do exactly that. You have to stack them yourself, even that. > >>>> You don't even have a stack pointer, it is up to you to assign one > >>>> of the GPR-s to that. The 603e core maximizes delegation to a huge > >>>> extent and this is very convenient when you know what you are doing. > >>>> Even when you get a TLB miss, all you get is an exception plus > >>>> r0-r3 being switched to a shadow bank, Z80 style, meant for you > >>>> to locate the entry in the page translation table and put it in the > >>>> TLB; if not in the table you do a page fault, go into allocation, > >>>> swapping if needed, fixing etc., you know how it goes. You don't need > >>>> to stack anything, the 4 regs you have are enough to do the TLB fix. > >>>> > >>> > >>> look similar to the older generation ARM, ARM7-TDMI > >>> > >>> stack pointer was also just a GP register defined as stack pointer > >>> > >>> it had one IRQ, and it only shadowed the return address and status register > >>> and an FIQ (fast) that shadowed the return address, status register, and (afair) > >>> seven general purpose registers > >>> > >>> quite a bit code needed to find the interrupt source, stacking, etc. and even worse > >>> if preemption was needed > >>> > >> Finding the source does not take much on SOCs with an interrupt > >> priority encoder, they all have that one nowadays (off-core, it does > >> only prioritize which vector will be supplied to the core which has > >> just one IRQ line). > >> Preemption from a hardware interrupt is a complex thing to do whatever > >> the scheme unless the interrupt is guaranteed to be received only while > >> running at user level. > >> But true prioritized interrupts 68k style is a huge step forward ARM > >> have made, this does make a difference. > > > > yes, the cortex-M basically only have one IRQ like the old ARM, > > but a module called the Nested Vectored Interrupt Controller was added > > to the cortex-m that does all the decoding, vectoring, priority, stacking, unstacking thought a "back door" > Wait a second, this is not like 68k. If there is just one IRQ > line the external controller cannot interrupt the core while it > deals with an interrupt and is still being masked. Or is there something > more sophisticated in that?the core it self only has one interrupt signal, but the NVIC takes care of all the stuff that makes it possible for higher priority interrupts to interrupt an already running interrupt being "in" an interrupt only mask that priority and lower priorities
Reply by ●January 16, 20232023-01-16
On 1/17/2023 0:45, Lasse Langwadt Christensen wrote:> mandag den 16. januar 2023 kl. 23.31.19 UTC+1 skrev Dimiter Popoff: >> On 1/17/2023 0:05, Lasse Langwadt Christensen wrote: >>> mandag den 16. januar 2023 kl. 22.56.54 UTC+1 skrev Dimiter Popoff: >>>> On 1/16/2023 23:22, Lasse Langwadt Christensen wrote: >>>>> mandag den 16. januar 2023 kl. 21.53.01 UTC+1 skrev Dimiter Popoff: >>>>>> On 1/16/2023 11:10, Don Y wrote: >>>>>>> On 1/15/2023 7:10 AM, Dimiter_Popoff wrote: >>>>>>>> How many registers does it stack automatically? I knew the HLL nonsense >>>>>>>> would catch up with CPU design eventually. >>>>>>> >>>>>>> IIRC, it stacks PC, PSR, LR (i.e., R14) & R[0-3]. >>>>>> Lasse also mentioned it, I see and it makes sense; I did not realize >>>>>> this was a "small" flavour of ARM, I am not familiar with any ARM. >>>>> >>>>> now there is basically two types cortex-Mx which is a 32bit microcontroller >>>>> with increasing x features are added like DSP instructions single, and double, FPU >>>>> >>>>> and the cortex-A which is a 32/64bit cpu used in cell phones etc. >>>>> >>>>>>> >>>>>>> PC and PSR must be preserved, of course (if you have a special shadow >>>>>>> register for each, that's just an optimization -- that only works if >>>>>>> ISRs can't be interrupted. Remember, you can ALWAYS throw an exception, >>>>>>> even in an ISR! E.g. the "push" can signal a page fault). The link >>>>>>> register (think "BAL" -- what's old is now new! :> ) determines *how* >>>>>>> the ISR terminates. >>>>>> On power, you get the PC and the MSR saved in special purpose registers >>>>>> assigned to do exactly that. You have to stack them yourself, even that. >>>>>> You don't even have a stack pointer, it is up to you to assign one >>>>>> of the GPR-s to that. The 603e core maximizes delegation to a huge >>>>>> extent and this is very convenient when you know what you are doing. >>>>>> Even when you get a TLB miss, all you get is an exception plus >>>>>> r0-r3 being switched to a shadow bank, Z80 style, meant for you >>>>>> to locate the entry in the page translation table and put it in the >>>>>> TLB; if not in the table you do a page fault, go into allocation, >>>>>> swapping if needed, fixing etc., you know how it goes. You don't need >>>>>> to stack anything, the 4 regs you have are enough to do the TLB fix. >>>>>> >>>>> >>>>> look similar to the older generation ARM, ARM7-TDMI >>>>> >>>>> stack pointer was also just a GP register defined as stack pointer >>>>> >>>>> it had one IRQ, and it only shadowed the return address and status register >>>>> and an FIQ (fast) that shadowed the return address, status register, and (afair) >>>>> seven general purpose registers >>>>> >>>>> quite a bit code needed to find the interrupt source, stacking, etc. and even worse >>>>> if preemption was needed >>>>> >>>> Finding the source does not take much on SOCs with an interrupt >>>> priority encoder, they all have that one nowadays (off-core, it does >>>> only prioritize which vector will be supplied to the core which has >>>> just one IRQ line). >>>> Preemption from a hardware interrupt is a complex thing to do whatever >>>> the scheme unless the interrupt is guaranteed to be received only while >>>> running at user level. >>>> But true prioritized interrupts 68k style is a huge step forward ARM >>>> have made, this does make a difference. >>> >>> yes, the cortex-M basically only have one IRQ like the old ARM, >>> but a module called the Nested Vectored Interrupt Controller was added >>> to the cortex-m that does all the decoding, vectoring, priority, stacking, unstacking thought a "back door" >> Wait a second, this is not like 68k. If there is just one IRQ >> line the external controller cannot interrupt the core while it >> deals with an interrupt and is still being masked. Or is there something >> more sophisticated in that? > > the core it self only has one interrupt signal, but the NVIC takes care of all the stuff that > makes it possible for higher priority interrupts to interrupt an already running interrupt > > being "in" an interrupt only mask that priority and lower priorities > >I am not sure I get it, I have had such an interrupt controller on the power cores I have used (first one on the mpc8240, late 90-s). What happens to the core when the IRQ line from the interrupt controller is asserted? On power, this would cause the core to set the interrupt mask bit and go to a specific address, roughly speaking. Then it is up to the core to clear *its* mask bit in its MSR, no matter what the interrupt controller does. On 68k/coldfire it is different; the core has a 3 bit interrupt mask in its status register and 7 interrupt wires. If you assert say IRQ2 the core sets its mask to 2 which masks IRQ2 and goes through the IRQ2 vector. Now if IRQ3 is asserted it will be taken the same way immediately and the mask will be set to 3; if IRQ1 comes it will have to wait until the core sets it mask bits to 0. Level 7 IRQ is unmaskable (useful only for debugging purposes, not in general code). (Please feel free to ignore me if you don't feel like explaining all that ARM stuff now, obviously I can dig it myself if I really need it).
Reply by ●January 16, 20232023-01-16
mandag den 16. januar 2023 kl. 23.56.31 UTC+1 skrev Dimiter Popoff:> On 1/17/2023 0:45, Lasse Langwadt Christensen wrote: > > mandag den 16. januar 2023 kl. 23.31.19 UTC+1 skrev Dimiter Popoff: > >> On 1/17/2023 0:05, Lasse Langwadt Christensen wrote: > >>> mandag den 16. januar 2023 kl. 22.56.54 UTC+1 skrev Dimiter Popoff: > >>>> On 1/16/2023 23:22, Lasse Langwadt Christensen wrote: > >>>>> mandag den 16. januar 2023 kl. 21.53.01 UTC+1 skrev Dimiter Popoff: > >>>>>> On 1/16/2023 11:10, Don Y wrote: > >>>>>>> On 1/15/2023 7:10 AM, Dimiter_Popoff wrote: > >>>>>>>> How many registers does it stack automatically? I knew the HLL nonsense > >>>>>>>> would catch up with CPU design eventually. > >>>>>>> > >>>>>>> IIRC, it stacks PC, PSR, LR (i.e., R14) & R[0-3]. > >>>>>> Lasse also mentioned it, I see and it makes sense; I did not realize > >>>>>> this was a "small" flavour of ARM, I am not familiar with any ARM. > >>>>> > >>>>> now there is basically two types cortex-Mx which is a 32bit microcontroller > >>>>> with increasing x features are added like DSP instructions single, and double, FPU > >>>>> > >>>>> and the cortex-A which is a 32/64bit cpu used in cell phones etc. > >>>>> > >>>>>>> > >>>>>>> PC and PSR must be preserved, of course (if you have a special shadow > >>>>>>> register for each, that's just an optimization -- that only works if > >>>>>>> ISRs can't be interrupted. Remember, you can ALWAYS throw an exception, > >>>>>>> even in an ISR! E.g. the "push" can signal a page fault). The link > >>>>>>> register (think "BAL" -- what's old is now new! :> ) determines *how* > >>>>>>> the ISR terminates. > >>>>>> On power, you get the PC and the MSR saved in special purpose registers > >>>>>> assigned to do exactly that. You have to stack them yourself, even that. > >>>>>> You don't even have a stack pointer, it is up to you to assign one > >>>>>> of the GPR-s to that. The 603e core maximizes delegation to a huge > >>>>>> extent and this is very convenient when you know what you are doing. > >>>>>> Even when you get a TLB miss, all you get is an exception plus > >>>>>> r0-r3 being switched to a shadow bank, Z80 style, meant for you > >>>>>> to locate the entry in the page translation table and put it in the > >>>>>> TLB; if not in the table you do a page fault, go into allocation, > >>>>>> swapping if needed, fixing etc., you know how it goes. You don't need > >>>>>> to stack anything, the 4 regs you have are enough to do the TLB fix. > >>>>>> > >>>>> > >>>>> look similar to the older generation ARM, ARM7-TDMI > >>>>> > >>>>> stack pointer was also just a GP register defined as stack pointer > >>>>> > >>>>> it had one IRQ, and it only shadowed the return address and status register > >>>>> and an FIQ (fast) that shadowed the return address, status register, and (afair) > >>>>> seven general purpose registers > >>>>> > >>>>> quite a bit code needed to find the interrupt source, stacking, etc. and even worse > >>>>> if preemption was needed > >>>>> > >>>> Finding the source does not take much on SOCs with an interrupt > >>>> priority encoder, they all have that one nowadays (off-core, it does > >>>> only prioritize which vector will be supplied to the core which has > >>>> just one IRQ line). > >>>> Preemption from a hardware interrupt is a complex thing to do whatever > >>>> the scheme unless the interrupt is guaranteed to be received only while > >>>> running at user level. > >>>> But true prioritized interrupts 68k style is a huge step forward ARM > >>>> have made, this does make a difference. > >>> > >>> yes, the cortex-M basically only have one IRQ like the old ARM, > >>> but a module called the Nested Vectored Interrupt Controller was added > >>> to the cortex-m that does all the decoding, vectoring, priority, stacking, unstacking thought a "back door" > >> Wait a second, this is not like 68k. If there is just one IRQ > >> line the external controller cannot interrupt the core while it > >> deals with an interrupt and is still being masked. Or is there something > >> more sophisticated in that? > > > > the core it self only has one interrupt signal, but the NVIC takes care of all the stuff that > > makes it possible for higher priority interrupts to interrupt an already running interrupt > > > > being "in" an interrupt only mask that priority and lower priorities > > > > > I am not sure I get it, I have had such an interrupt controller on > the power cores I have used (first one on the mpc8240, late 90-s). > > What happens to the core when the IRQ line from the interrupt > controller is asserted? On power, this would cause the core > to set the interrupt mask bit and go to a specific address, > roughly speaking. Then it is up to the core to clear *its* > mask bit in its MSR, no matter what the interrupt controller > does. > > On 68k/coldfire it is different; the core has a 3 bit interrupt > mask in its status register and 7 interrupt wires. > If you assert say IRQ2 the core sets its mask to 2 which masks > IRQ2 and goes through the IRQ2 vector. Now if IRQ3 is asserted > it will be taken the same way immediately and the mask will be > set to 3; if IRQ1 comes it will have to wait until the core sets > it mask bits to 0. Level 7 IRQ is unmaskable (useful only for > debugging purposes, not in general code). > > (Please feel free to ignore me if you don't feel like explaining > all that ARM stuff now, obviously I can dig it myself if I > really need it).it is basically the same as how you describe the 68K it just isn't inside the core it is in a module that sits next to the core all the different interrupts a connected to the NVIC and single interrupt from the NVIC to the core, all the different interrupts have a programmable priority level when an unmasked interrupt is asserted the NVIC interrupts the core, mask same and lower priorities, "reenables" interrupts and vector to that ISR same happens if another interrupt that isn't masked i.e. higher priority is asserted while an ISR is running https://www.motioncontroltips.com/wp-content/uploads/2019/03/Nested-Interrupt-Diagram-Feature.jpg main is interrupted by ISR1, ISR1 is interrupted by the higher priority ISR2
Reply by ●January 16, 20232023-01-16
On 1/16/2023 3:56 PM, Dimiter_Popoff wrote:> I am not sure I get it, I have had such an interrupt controller on > the power cores I have used (first one on the mpc8240, late 90-s). > > What happens to the core when the IRQ line from the interrupt > controller is asserted? On power, this would cause the core > to set the interrupt mask bit and go to a specific address, > roughly speaking. Then it is up to the core to clear *its* > mask bit in its MSR, no matter what the interrupt controller > does.There is one EXTERNAL interrupt signal available. All of the INTERNAL (SoC) interrupt sources each connect to the NVIC directly. There are dozens of such sources. The NVIC makes it possible (to some extent) to prioritize how "important" (priority) each source is.> On 68k/coldfire it is different; the core has a 3 bit interrupt > mask in its status register and 7 interrupt wires. > If you assert say IRQ2 the core sets its mask to 2 which masks > IRQ2 and goes through the IRQ2 vector. Now if IRQ3 is asserted > it will be taken the same way immediately and the mask will be > set to 3; if IRQ1 comes it will have to wait until the core sets > it mask bits to 0. Level 7 IRQ is unmaskable (useful only for > debugging purposes, not in general code).There are 256 interrupt vectors (address to which control should be transferred, more-or-less) each which can have a priority assigned. Remember, *exceptions* are also treated the same (or, you can view interrupts AS exceptions). The NVIC looks at the priorities for all exceptions that want to be serviced, "now", and picks the one with the highest priority (lower values represent higher priorities). Thereafter (until the exception is "done"), only exceptions of higher priority can interrupt the handling of the exception. So, a bus fault can interrupt your "handling" of the jiffy (also an exception); an NMI can interrupt the handling of a timer interrupt (because timers come into the NVIC as "external interrupts"). etc.> (Please feel free to ignore me if you don't feel like explaining > all that ARM stuff now, obviously I can dig it myself if I > really need it). >
Reply by ●January 16, 20232023-01-16
On 1/16/2023 1:52 PM, Dimiter_Popoff wrote:> I was somewhat surprised that ARM has the ability to truly prioritize > interrupts, 68k style. Both you and Lasse said that, this is an > important thing to have.It's almost essential when you have as many *possible* IRQ sources ("exceptions") as these devices *can* support. You need <something> to at least summarize the state of all (unmasked) requests that you can quickly examine AT entry to the service routine -- otherwise you'd be wasting time polling a bunch of status registers: "Are YOU the source of this IRQ?" You have to also remember that ARM is just IP. Vendors "assemble" the IP into real devices. So, they have a library of "blocks" to choose from. The "Timer Status Register" will be present in a *timer* block -- which may or may not be present in a particular design. Ditto PWM controller, etc. You want a means of bringing together this (IRQ) information from disjoint blocks to a place where they can all be examined/processed. Instead of just giving you a 256bit status "word" representing the status of each IRQ source, the NVIC also lets you arrange them into some order that is appropriate for YOUR application. And, because *it* ultimately signals the core to handle the exception, *it* knows when an ISR is being executed -- and WHY (priority).
Reply by ●January 17, 20232023-01-17
On a sunny day (Mon, 16 Jan 2023 06:29:25 -0800) it happened John Larkin <jlarkin@highlandSNIPMEtechnology.com> wrote in <cenashpl5f7cdk37nq4dab7hcdlqknptqh@4ax.com>:>We wrote one Linux program that just toggled a test point as fast as >it could. That was interesting on a scope, namely the parts that >didn't toggle.That way the task switch will interrupt, any multitasker does that. It all depends look at 'using raspberry Pi as FM transmitter' (80 to 100 MHz or so): https://linuxhint.com/turn-raspberry-pi-fm-transmitter/ That code gave me the following idea, freq_pi: http://panteltje.com/panteltje/newsflex/download.html#freq_pi and that was for a very old Pi model, somebody then ported it to a later model, no idea how fast you can go on a Pi4. So, basically, you mentioned: "will give it (Pi4) to some programmer" Now let me tell you this!!! STUDY THE HARDWARE that Pi4 has some quite complex very powerful hardware on board. Using that will beat any 'just code a loop in C or asm or whatever' or interrupt stuff. The same goes for most micros, most have extra hardware on board. What we see now is programmers who have no clue about hardware building libraries that are bloated and slow that then are used by others that have even less knowledge of the hardware AND of programming and user interfaces to make modern bloat like microsore and jmail email crap. So my advice to you: study the hardware of that Pi4 you bought for all those dollars. Most of the time no need to learn ARM asm (and all its registers) just make use of the hardware there is. 'A programmer' likely will not understand the hardware and resort to bloat where it is not needed.
