avr-gcc-list
[Top][All Lists]
Advanced

[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: Joerg Wunsch
Subject: Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK
Date: Fri, 4 May 2012 23:02:08 +0200 (MET DST)

Georg-Johann Lay <address@hidden> 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.

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

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

Since the invention of the ISR API, users don't seem to have any
troubles anymore with that.  The support effort that used to be
involved around SIGNAL vs. INTERRUPT dropped to zero.  To me, this
proves the current API makes a lot of sense, and should be kept.

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

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

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.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)



reply via email to

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