cli() and sei() for Maple 5 « LeafLabs Garden

LeafLabs Garden » Support » Maple Hardware Support

cli() and sei() for Maple 5

(10 posts) (3 voices)

Started 3 years ago by pico
Latest reply from mbolivar

pico
Member

After some reading, I found the asm instructions to disable/enable interrupts by setting PRIMASK for the Cortex-M3, so I'm assuming this should work for a Maple 5:
#define _cli asm("CPSID i\n\t")
#define _sei asm("CPSIE i\n\t")
Any reason why this might be problematic? Any reason why they weren't included in the libs for greater compatibility with Arduino code?

FWIW, they seem to be compiling and working as expected so far in my programs I'm porting to Maple 5 from AVR Arduino.

But thought I'd ask in case I'm missing something basic (or even not so basic) here...

Posted 3 years ago #
mbolivar
LeafLabs

I've thought about doing something like that. The only part I worry about is that apparently cli()/sei() imply memory barriers:

http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html#ga68c330e94fe121eba993e5a5973c3162

To faithfully emulate them, then, we'd need to do the same thing. I'm not sure which of the ARM memory barriers is equivalent to the AVR version. Can anyone provide some advice here?

Posted 3 years ago #
pico
Member

Not sure if talking about exactly the same thing, but I've started porting over the ATOMIC_BLOCK macros to see if I can get equivalents working under ARM, and I've come across this construct:
static __inline__ void __iRestore(const uint32_t *__s) \ { __set_primask(*__s); __asm__ volatile ("" ::: "memory"); }
where the asm "memory" directive is in the "clobber list" position in an otherwise empty line of assembly code, which I understand constrains any reordering optimisations at that point the compiler might otherwise consider.

Along with "volatile", these are directives that basically close off optimisations to prevent these instruction being moved to unexpected places.

Is this what you mean by a "memory barrier"?

FWIW, the version of the port I am currently testing compiles and assembles without complaint with these directives, so perhaps there is nothing going on that isn't portable across the AVR and ARM versions of GCC.

Posted 3 years ago #
pico
Member

Having read a little more about "memory barriers", I see that there are _CPU_ memory barrier instructions to conttrol out-of-sequence execution of instructions due to e.g., pipelining, and there are also _compiler_ memory barrier directives, such as the "":::"memory" directive GCC uses to control reording due to optimisations.

Perhaps a "belts and braces" way to implement a memory barrier/execution order safe cli() would be something like this:
__asm__ volatile ("CPSID i\n\t""dmb\n\t" ::: "memory")
What do you think?

Posted 3 years ago #
mbolivar
LeafLabs

FWIW, the version of the port I am currently testing compiles and assembles without complaint

Just because it builds doesn't mean the memory ordering constraints it implies are the same. If this is going to go into the core library, it's important to get those right.

Perhaps a "belts and braces" way to implement a memory barrier/execution order safe cli() would be something like this:

__asm__ volatile ("CPSID i\n\t""dmb\n\t" ::: "memory")

That seems pretty reasonable. Are you confident that dmb provides the same semantics as cli() (versus dsb, etc.)? The AVR docs for cli() are a little underspecified for my taste.

Next question -- where should these go? I was thinking of adding a Wirish-level avr_compat.h header for things like this. People can then include it as a quick-and-dirty mechanism when porting code. Seem reasonable?

By the way, noInterrupts() and interrupts() should both compile down to the single machine instruction they imply (cpsid i/cpsie i), so it's nice to use them instead of assembly for readability.

Posted 3 years ago #
x893
Member

I see core_cm3.h from ST library and see next

static inline void __enable_irq() { __asm volatile ("cpsie i"); }
static inline void __disable_irq() { __asm volatile ("cpsid i"); }

this not work ?

Posted 3 years ago #
x893
Member

For atomic i use very simple construction (thread safe)
volatile uint32_t CriticalSectionCount = 0;
void CriticalSectionEnter(void)
{
if (CriticalSectionCount++ == 0) __disable_irq();
}
void CriticalSectionExit(void)
{
if (--CriticalSectionCount == 0) __enable_irq();
}

and in code
...
CriticalSectionEnter();
// execute with disable irq, also can call other critical codes
CriticalSectionExit();

Posted 3 years ago #
mbolivar
LeafLabs

x893,

this not work ?

no; that enables/disables interrupts, but neither implies a memory barrier. so it might work like cli()/sei() in some situations, but not others. please read my above message in this thread discussing cli()/sei() and memory barriers:

http://forums.leaflabs.com/topic.php?id=2617#post-13004

Posted 3 years ago #

If i add

static inline void __ISB() { __asm volatile ("isb"); }
static inline void __DSB() { __asm volatile ("dsb"); }
static inline void __DMB() { __asm volatile ("dmb"); }

and modify

void CriticalSectionEnter(void)
{
  if (CriticalSectionCount == 0)
  {
    __disable_irq();
    __DMB();
    __DSB();
    __ISB();
  }
  CriticalSectionCount++;
}

Posted 3 years ago #

mbolivar
LeafLabs

heh, that's definitely one way of going about it.

throwing in every fence available on the architecture is the definitely thermonuclear option, though. i suppose that's the safest thing to do given that we haven't heard any feedback on the semantics of the memory barriers implied by cli()/sei().

Posted 3 years ago #

RSS feed for this topic

Reply

You must log in to post.