ARM Cortex Mx vs the rest of the gang - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: ARM Cortex Mx vs the rest of the gang
On 12/07/17 20:44, Don Y wrote:
Quoted text here. Click to load it

I've snipped most of this post - these posts are ridiculously long, and  
I expect few people will bother reading them any more.

Quoted text here. Click to load it

Cortex M devices do not have FIRQ or any other complicated modes.  They  
have a very simple and efficient interrupt system.  I don't know details  
for Cortex A devices.

Quoted text here. Click to load it

Modern hardware FPUs usually treat complex opcodes like FSIN as  
interruptable and either restart them, or continue from where they left  
off.  Of course, many modern FPUs simply don't implement such complex  
and time-consuming opcodes but stick to simpler arithmetic and  
instructions that only take a few clock cycles.

Quoted text here. Click to load it

gcc "knows" about interrupts, in that there are extensions (usually  
function __attribute__'s, perhaps also headers with specific features  
and maybe other extensions) that support interrupts on a wide variety of  
targets.  It does not "know" about them if you mean understanding about  
different execution contexts, or how to enable and disable interrupts.

On ARM Cortex M, gcc does not "know" about interrupts in this sense -  
simply because the interrupt hardware in the cpu means that there is no  
special effort needed.  Interrupt functions are normal C functions.

Re: ARM Cortex Mx vs the rest of the gang
On 07/13/17 21:31, David Brown wrote:
Quoted text here. Click to load it

Must have too much time on my hands, but yes, far too long.


Quoted text here. Click to load it

I write all interrupt handlers in C, but still need to know what
registers are used inside the handler, to avoid saving everything.

Since there is a disconnect between the mainline code and an interrupt
handler, how does gcc know which registers to save and restore ? Fine
if the toolchain vendor has provided something like #interrupt pragma,
but otherwise, you need asm macros at entry and exit for the register
saves. Or am I missing something ?...

Chris


Re: ARM Cortex Mx vs the rest of the gang
On 14/07/17 17:27, Chris wrote:
Quoted text here. Click to load it

No, you don't - at least, not for the normal registers (the FPU  
registers are more complex, as has already been covered).  That is the  
whole point of the way interrupts are handled on the Cortex M devices.  
The ABI for the device is fixed clearly - ARM has said exactly which  
registers are "volatile" and which are "non-volatile".  And the  
interrupt hardware preserves all the volatile registers before the  
interrupt function is started.  This means that as long as the C  
compiler generates code that is compatible with the ABI, it will already  
save exactly the registers it needs to save - no more (assuming an  
efficient compiler!) and no less.  You need to know about register usage  
for writing an RTOS with pre-emptive multitasking, and that sort of  
thing - you don't need to know at all for normal C code called from an  
interrupt.

I don't know of any other processors that handle this as smoothly as the  
Cortex M cpus - usually the compiler has to do /something/ special for  
interrupt functions, preserving some registers and exiting with a  
"return from interrupt" instruction.  But not on the Cortex M.

Quoted text here. Click to load it

Yes, you are missing something (not surprising, as the Cortex M is  
different from other processors in this regard).

It is normal practice to divide the register set into "volatile" or  
"caller-preserved" registers and "non-volatile" or "callee-preserved"  
registers.  When generating the code for a function, the compiler can  
use the "volatile" registers as it wants without saving and restoring  
their values.  But if it wants to use the "non-volatile" registers, it  
must preserve their values so that they are returned unchanged when the  
function exits.  The compiler will not generate code to save and restore  
these unless it actually /uses/ these registers.  And the same goes for  
any functions it calls further down the line.

So when an interrupt has triggered, the Cortex M preserves all the  
"volatile" registers and then calls the interrupt function, which is a  
perfectly normal function.


Quoted text here. Click to load it


Re: ARM Cortex Mx vs the rest of the gang
On 07/14/17 15:38, David Brown wrote:

Quoted text here. Click to load it

That's really an advance and makes the software task much easier.

Assume that works for N level nested interrupts as well ?...

Chris


Re: ARM Cortex Mx vs the rest of the gang
On 14/07/17 18:03, Chris wrote:
Quoted text here. Click to load it

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!

Re: ARM Cortex Mx vs the rest of the gang
On 07/14/17 18:20, David Brown wrote:

Quoted text here. Click to load it

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


Re: ARM Cortex Mx vs the rest of the gang
On 07/12/17 18:44, Don Y wrote:

Quoted text here. Click to load it

Probably don't disagree with much of what you say, but wading through
so much is hard waork. As I said, tl:dr applies :-).


Ok, keep it short. I like to get 8 hours sleep a night, perhaps there's
so much backup to do after a days interaction with life. Whatever, if
you still get stimulated by the advance of tech, then you have a life
and future...

Chris


Re: ARM Cortex Mx vs the rest of the gang
On 12.7.2017 ?. 02:16, Chris wrote:
Quoted text here. Click to load it

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/




Re: ARM Cortex Mx vs the rest of the gang
On 07/14/17 21:45, Dimiter_Popoff wrote:

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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


Re: ARM Cortex Mx vs the rest of the gang
On 15.7.2017 ?. 02:00, Chris wrote:
Quoted text here. Click to load it

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 :-).

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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/


Re: ARM Cortex Mx vs the rest of the gang
On 07/15/17 01:04, Dimiter_Popoff wrote:
Quoted text here. Click to load it

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


Re: ARM Cortex Mx vs the rest of the gang
On 7/14/17 5:45 PM, Dimiter_Popoff wrote:
Quoted text here. Click to load it

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.


Re: ARM Cortex Mx vs the rest of the gang
On 15.7.17 00:45, Dimiter_Popoff wrote:

Quoted text here. Click to load it

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


Re: ARM Cortex Mx vs the rest of the gang
On 15/07/17 10:53, Tauno Voipio wrote:
Quoted text here. Click to load it

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).

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Re: ARM Cortex Mx vs the rest of the gang

Quoted text here. Click to load it

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

Re: ARM Cortex Mx vs the rest of the gang
Quoted text here. Click to load it

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

Re: ARM Cortex Mx vs the rest of the gang
Op Mon, 12 Jun 2017 16:21:12 +0200 schreef StateMachineCOM
Quoted text here. Click to load it

No. Only when you switch to an FPU-enabled task. The task dispatcher just
needs to keep track of whose content is in the FPU registers, and
save/restore when ownership changes.

Quoted text here. Click to load it

A good task dispatcher has the FPU enable bit as part of the task context.
Code that enables this bit is easily found.

Quoted text here. Click to load it




--  
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

Site Timeline