Posted by July 20, 2017
David Brown <david.brown@hesbynett.no> wrote:

> I don't know about Cortex R and Cortex A cores. I'd > guess Cortex R also have nested priority interrupt support, but perhaps > Cortex A is simpler (since this is a feature you want for real-time > control, not for application processors).
Neither Cortex-A nor -R support priorities beyond the traditional ARM operating modes, but the cores are often coupled with an external interrupt controller, leaving it up to the device manufacturer. -a
Posted by July 20, 2017
Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
> On 15.7.17 00:45, Dimiter_Popoff wrote: > >> I can't think of a single non-68k/coldfire processor which has the >> multiple priority interrupt levels (but I don't know ARM) or an >> equivalent. Did ARM come that much of age? I'd be surprised. > Cortex does. In the architecture there are 255 levels which > can be broken at a bit boundary to main levels and sublevels, > e.g. 32 main levels with 8 sublevels each (depending on the > chip implementor's decision).
These days, almost all processors have interrupt proprity levels. However none that I know of handle them as elegantly as Cortex-M, and instead require some combination of manual context saving and interrupt masking. -a
Posted by Chris July 16, 2017
On 07/15/17 01:04, Dimiter_Popoff wrote:
> On 15.7.2017 &#1075;. 02:00, Chris wrote: >> On 07/14/17 21:45, Dimiter_Popoff wrote: >> >>> >>> I can't think of a single non-68k/coldfire processor which has the >>> multiple priority interrupt levels (but I don't know ARM) or an >>> equivalent. Did ARM come that much of age? I'd be surprised.
The basic 68k did interrupt priorities in hardware, fwir. 3 bits of input to the chip, usually driven by a ttl 8-3 line priority encoder, with hardwired inputs to set priority. Not sure about the -020 and later details, but fwir, all later versions has a relocatable vector table at least, whereas in the original, it was fixed. I worked on a project using the Dragonball VZ and that was far more interesting, with relocatable vector table, control register, mask register, status register, pending register and level (priority) register, all interrupt related. Only used a fraction of the capability, but good to have it there. Last project used a Renesas device, which looked like the old Hitachi 8 bit series + 8 added address bits. Far from being a clean architecture but got the job done. As for ARM, only have limited experience of Cortex M3 and still haven't worked a project using it, which is where you really find out how good it is. On paper though, it ticks all the boxes from every angle, eg; has borrowed all the Dragonball int ideas and then some. The best book on the M3 is probably the Joseph Yiu Definitive Guide to the Arm Cortex M3. Expensive and goes on a bit in places, but more concise than the official docs. Has Arm come of age ?, yes, I think so and worth digging into... Chris
Posted by David Brown July 15, 2017
On 15/07/17 10:53, Tauno Voipio wrote:
> On 15.7.17 00:45, Dimiter_Popoff wrote: > >> I can't think of a single non-68k/coldfire processor which has the >> multiple priority interrupt levels (but I don't know ARM) or an >> equivalent. Did ARM come that much of age? I'd be surprised. > > Cortex does.
Cortex M, anyway. I don't know about Cortex R and Cortex A cores. I'd guess Cortex R also have nested priority interrupt support, but perhaps Cortex A is simpler (since this is a feature you want for real-time control, not for application processors).
> In the architecture there are 255 levels which > can be broken at a bit boundary to main levels and sublevels, > e.g. 32 main levels with 8 sublevels each (depending on the > chip implementor's decision).
Yes. Interrupts at higher main priority levels can break in while you are executing a lower level interrupt. Sublevels are used to determine which interrupt on the same main level is handled first when there are multiple interrupts triggered.
> > There is an exception (internally triggered interrupt) for > thread switching (PENDSV), and it simplifies the core thread > switching when run on lowest priority. > > The Cortex interrupt mechanism can handle nested interrupts > with plain C functions, and the nesting mechanism is up and > running in normal case. An interrupt handler has to disable > higher-priority interrupts if it wants to be alone. >
The Cortex M also has "interrupt chaining". When an interrupt is triggered, it pushes some of the key registers onto the stack before calling the interrupt function. If a new interrupt (at the same or lower level) is triggered before the first returns, then the processor skips the restore and re-stack of these registers before moving on to the new interrupt function.
Posted by Tauno Voipio July 15, 2017
On 15.7.17 00:45, Dimiter_Popoff wrote:

> I can't think of a single non-68k/coldfire processor which has the > multiple priority interrupt levels (but I don't know ARM) or an > equivalent. Did ARM come that much of age? I'd be surprised.
Cortex does. In the architecture there are 255 levels which can be broken at a bit boundary to main levels and sublevels, e.g. 32 main levels with 8 sublevels each (depending on the chip implementor's decision). There is an exception (internally triggered interrupt) for thread switching (PENDSV), and it simplifies the core thread switching when run on lowest priority. The Cortex interrupt mechanism can handle nested interrupts with plain C functions, and the nesting mechanism is up and running in normal case. An interrupt handler has to disable higher-priority interrupts if it wants to be alone. -- -TV
Posted by Dimiter_Popoff July 15, 2017
On 15.7.2017 &#1075;. 02:00, Chris wrote:
> On 07/14/17 21:45, Dimiter_Popoff wrote: > >> >> I can't think of a single non-68k/coldfire processor which has the >> multiple priority interrupt levels (but I don't know ARM) or an >> equivalent. Did ARM come that much of age? I'd be surprised. > > Neither do I. At the time, we avidly followed developments in Byte > magazine and remember being so impressed by the 68K architecture, > went out and spent a fortune on the 68KECB, just to learn about it. > It's the architecture that all others since have been compared > against, often unfavorably, but Motorola were influenced by > older mini architectures such as pdp11, or even Vax. "Get as much > mini arch into a micro as possible", I think was the reasoning. I > bet it would still be competitive even now with modern process > technology, but of course, CISC is out of fashion these days.
Well the prioritized scheme needs not be on CISC, e.g. on power a pair of registers to save the PC and the MSR per priority level would suffice (this is how they did the FIRQ). Of course and a RTI (rfi on power) opcode, different per level - and working :-).
> >> >> Even power do not have it, some cores do have a FIRQ which has >> priority over IRQ (i.e. will interrupt an IRQ handler). On the core >> I use (and did not use the FIRQ) there is a hardware mess with the >> return from FIRQ opcodes - and IIRC the suggested workaround would >> kill the "FIRQ interrupt IRQ" capability, LOL. (I think it was >> to copy the FIRQ return registers to those for IRQ and exectute >> a return from IRQ.... too bad if you had just interrupted an IRQ >> handler). >> > > Older arm arch was a mess, imho, looking like bits had been glued > on all over the place. The idea of IRQ and FIRQ harks back to 6800 > and 6502's IRQ and NMI, which served similar functions.
NMI was too cruel, I used it for step by step tracing only. They introduced the FIRQ on the 6809 (they being Motorola, obviously); perhaps were forced to as IRQ pushed all the registers and the 09 had a lot more than the 6800 (which pushed all IIRC in about 20uS @1 MHz...) The FIRQ on the 09 pushed just the CCR and the PC, 3 bytes.
> If they could > build compiler friendly orthoganal architecture micros 30 years ago, > there's no excuse not to do it now...
The guy who made power must have been really good, apart from the missing interrupt levels I can't say I have many wishes. In fact I live fine as it is, I just think of the moment I might need them :D. This has been some 30 years ago... still the architecture the rest want to catch up with. Then on the mpc5200B (the one in heaviest use here) there is an interrupt peripheral, which prioritizes the interrupts 68k style and feeds them via the single IRQ line to the core. I have not needed to do it but with a few reads and writes at the beginning of the IRQ handler and perhaps at its end one could emulate the complete 68k thing I believe (never seriously looked into it though, would take unmasking the irq in the core after stacking some stuff and making the intrerrupt controller shut up for the current and lower priorities). ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
Posted by Richard Damon July 15, 2017
On 7/14/17 5:45 PM, Dimiter_Popoff wrote:
> On 12.7.2017 &#1075;. 02:16, Chris wrote: >> ... >> I guess you are talking arm?. FIRQ is a leftover from early arm, fwir. >> Have you seen amount of tortuous code needed to get interrupts >> working properly with Arm7TDMI, for example?. About 2 pages of dense >> assembler, from memory. I rejected early arm almost on that basis >> alone, but there were other idiosyncracies. They fixed it eventually >> with a proper (68K) style vector table, but it took them a long time >> :-). Cortex was when Arm finally came of age. > > I can't think of a single non-68k/coldfire processor which has the > multiple priority interrupt levels (but I don't know ARM) or an > equivalent. Did ARM come that much of age? I'd be surprised. > > Even power do not have it, some cores do have a FIRQ which has > priority over IRQ (i.e. will interrupt an IRQ handler). On the core > I use (and did not use the FIRQ) there is a hardware mess with the > return from FIRQ opcodes - and IIRC the suggested workaround would > kill the "FIRQ interrupt IRQ" capability, LOL. (I think it was > to copy the FIRQ return registers to those for IRQ and exectute > a return from IRQ.... too bad if you had just interrupted an IRQ > handler). > > Dimiter >
The Microchip Pic24/dsPIC processors have a real priority interrupt system, where interrupts can automatically interrupt lower priority isrs. Its been a while since I dug into the Arm architecture at that level, but from what I remember, one irq handler naturally blocks all irq handlers, but if the handler saves a few things to the irq stack (like the link register which holds where to return to), it can re-enable the irq interrupt to allow nested interrupts.
Posted by Chris July 14, 2017
On 07/14/17 21:45, Dimiter_Popoff wrote:

> > I can't think of a single non-68k/coldfire processor which has the > multiple priority interrupt levels (but I don't know ARM) or an > equivalent. Did ARM come that much of age? I'd be surprised.
Neither do I. At the time, we avidly followed developments in Byte magazine and remember being so impressed by the 68K architecture, went out and spent a fortune on the 68KECB, just to learn about it. It's the architecture that all others since have been compared against, often unfavorably, but Motorola were influenced by older mini architectures such as pdp11, or even Vax. "Get as much mini arch into a micro as possible", I think was the reasoning. I bet it would still be competitive even now with modern process technology, but of course, CISC is out of fashion these days.
> > Even power do not have it, some cores do have a FIRQ which has > priority over IRQ (i.e. will interrupt an IRQ handler). On the core > I use (and did not use the FIRQ) there is a hardware mess with the > return from FIRQ opcodes - and IIRC the suggested workaround would > kill the "FIRQ interrupt IRQ" capability, LOL. (I think it was > to copy the FIRQ return registers to those for IRQ and exectute > a return from IRQ.... too bad if you had just interrupted an IRQ > handler). >
Older arm arch was a mess, imho, looking like bits had been glued on all over the place. The idea of IRQ and FIRQ harks back to 6800 and 6502's IRQ and NMI, which served similar functions. If they could build compiler friendly orthoganal architecture micros 30 years ago, there's no excuse not to do it now... Chris
Posted by Dimiter_Popoff July 14, 2017
On 12.7.2017 &#1075;. 02:16, Chris wrote:
> ... > I guess you are talking arm?. FIRQ is a leftover from early arm, fwir. > Have you seen amount of tortuous code needed to get interrupts > working properly with Arm7TDMI, for example?. About 2 pages of dense > assembler, from memory. I rejected early arm almost on that basis > alone, but there were other idiosyncracies. They fixed it eventually > with a proper (68K) style vector table, but it took them a long time > :-). Cortex was when Arm finally came of age.
I can't think of a single non-68k/coldfire processor which has the multiple priority interrupt levels (but I don't know ARM) or an equivalent. Did ARM come that much of age? I'd be surprised. Even power do not have it, some cores do have a FIRQ which has priority over IRQ (i.e. will interrupt an IRQ handler). On the core I use (and did not use the FIRQ) there is a hardware mess with the return from FIRQ opcodes - and IIRC the suggested workaround would kill the "FIRQ interrupt IRQ" capability, LOL. (I think it was to copy the FIRQ return registers to those for IRQ and exectute a return from IRQ.... too bad if you had just interrupted an IRQ handler). Dimiter ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
Posted by Chris July 14, 2017
On 07/14/17 18:20, David Brown wrote:

> Yes, it does. > > It is not a /huge/ advance - it is not that hard to use > "__attribute__((interrupt))" or a #pragma on your interrupt functions. > But it is nice and convenient, and more efficient than compiler > instructions to stack the volatile registers. > > Indeed, its convenience has a negative effect - you need to be careful > to name your interrupt functions appropriately, because it is not > obvious that they /are/ interrupt functions!
I have a naming convention to handle that, if that's what you are getting at. timer_drvr.c upper level timer driver code timer_isr.c lower level interrupt handler Same for anything else interrupt related.. Chris