[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK
Date: Sat, 05 May 2012 18:18:33 +0200
User-agent: Thunderbird (Windows/20100228)

Joerg Wunsch schrieb:
Georg-Johann Lay wrote:

One hack would be that "interrupt" overrides/is stronger than "signal" and likewise for OS_task/OS_main.

I don't like it much, in particular since the name "signal" does not
mean anything to the casual embedded programmer, and it's something
fairly different than a "signal" to the casual UNIX programmer.

Well, if a Linux programmer comes over and expects anything, including
hardware dependent GNU extensions, work without any changes, then he
will experience considerable problems.

In other words, I think "signal" is a misnomer, and should not have
existed in the first place.

It there. It will stay there. We have to live with it.

And I still think it's not a misnomer, it's a RTFM.

All the ISR() stuff and deprecation if SIGNAL and INTERRUPT was -- if
I understand you correctly -- because users did not read the docs
and instead tried to deduce the semantics of the above attributes from
their identifier name.

Basically, yes.

The difference to my suggestion is, SIGNAL and INTERRUPT exposed the
misnamed attribute names into the library API, so users had to use
them, and eventually got confused by it.  Yes, you might blame them
for not reading the docs, but it's about the same as "Press start to
shutdown" (your Windows machine): being required to declare your
(standard) interrupt service routine by something that is not named
"interrupt" does not match the user's expectation.

Actually, on most embedded systems it would be a Kunstfehler to
disable interrupts like that.

If, for example, an OS that claims to work with hard real-time
application disables IRQs, it is pretty much useless.

Since the invention of the ISR API, users don't seem to have any
troubles anymore with that.

I guess this is not because they read the docs, it's just because
they copy-paste ISR and there is no equivalent for INTERRUPT :-/

So yes, we could just give the "interrupt" attribute a priority over
"signal"; users won't notice it, and no further change is needed.

Yeah, so we will see yet another FIXME in avr-gcc.

IMO the best thing is to have no warning because a warning confuses
with already present code.

I wish I had introduced an error _before_ AVR-LibC started messing
with interrupt+signal...

Or, we could use that occasion to finally also drop that misnamed
"signal" attribute alltogether, at least in the long run.

I don't see a point here. Deprecations are always really inconvenient.

The proposed "isr" and "interruptible" attribute names are just
because I personally find them both, descriptive, as well as no longer
self-contradictionary, since an "interruptible ISR" is something the
embedded developer could immediately guess how it works.

Why is it interruptible?
Because the user enabler IRQs in the ISR /after/ the prologue)?
Or because there is an SEI emit by the compiler /before/ the prologue?

This is quite a difference with respect to generated code (SP=val)
and with respect to IRQ latency.

What if the user wants an atomic prologue but enables interrupts in the

The compiler cannot see this in the code.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]