ISR (interrupt service routine) code in isr.c

[Eirik Midttun]

I have seen quite a few times that C programs contain a file named
isr.c or files named a_isr.c, b_isr.c where a and b are hardware that
generate interrupts. Obviously these files contain code to be executed
on interrupts and is most common in embedded application.

My own preference is a different one. If I write a scheduler that uses
a timer, I would keep the timer interrupt code together with the code
that does the initialisation, adds tasks, and so on. I see no reason
for putting this function in one separate file or in file with all the
other ISRs.

Left a side the discussion of what is best practice, what is the idea
behind this? Why do some programmers organise the code in this way?

Regards,

Eirik

[Richard Tobin]

In article <11**********************@m58g2000cwm.googlegroups .com>,
Eirik Midttun <em******@gmail.comwrote:

>I have seen quite a few times that C programs contain a file named
isr.c or files named a_isr.c, b_isr.c where a and b are hardware that
generate interrupts. Obviously these files contain code to be executed
on interrupts and is most common in embedded application.

My own preference is a different one. If I write a scheduler that uses
a timer, I would keep the timer interrupt code together with the code
that does the initialisation, adds tasks, and so on. I see no reason
for putting this function in one separate file or in file with all the
other ISRs.

If the code handles hardware, it probably has hardware-specific
non-portable code. Separating portable from non-portable code is
generally a good idea: it localises the code that needs changing when
the platform changes, and it allows you to compile with stricter
checking on the portable parts.

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Jack Klein]

On 7 Feb 2007 03:48:24 -0800, "Eirik Midttun" <em******@gmail.com>
wrote in comp.lang.c:

I have seen quite a few times that C programs contain a file named
isr.c or files named a_isr.c, b_isr.c where a and b are hardware that
generate interrupts. Obviously these files contain code to be executed
on interrupts and is most common in embedded application.

Could very well be, but there is no such thing as an interrupt service
routine in standard C, so it is off-topic here.

My own preference is a different one. If I write a scheduler that uses
a timer, I would keep the timer interrupt code together with the code
that does the initialisation, adds tasks, and so on. I see no reason
for putting this function in one separate file or in file with all the
other ISRs.

Then why not put the code of the tasks, and main() as well, all in one
file? Why not have all the code in one source file? Might as well
eliminate the headers, as well, by copying their contents and pasting
it into the single source file as well. Then you just have to compile
the_universe.c and you're all done.

Left a side the discussion of what is best practice, what is the idea
behind this? Why do some programmers organise the code in this way?

As for why "some programmers" do things a certain way, I guess you
would have to ask them. The C language certainly has nothing at all
to say on the issue.

If you are not experienced enough to see the benefits of modularizing
code, especially separating code that is dependent on specific
hardware from code that is hardware independent, then you don't. If
you don't want to do it, don't do it. If you're writing code for you
own use, the only requirements are that you write it the way you want
to write it.

By the way, there is absolutely nothing at all in your post about the
C language.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html