ARM and interrupts

Bill Gatliff bgat@billgatliff.com
Thu Mar 18 08:00:00 GMT 2004


Toralf:


Whether you need a kernel or not is a function of many things, including 
the nature of your application, your tools, and your skills...

There isn't anything specific in Newlib related to ARM interrupts or 
exceptions, except for the SWI stuff it uses to talk with Angel (if you 
configure it that way). Everything else you provide on your own.

I do quite a bit of ARM vector work, it's an essential part of how my 
debugging agents do their thing. Search for "gdbstubs" on Sourceforge 
for some code examples. It isn't rocket science at all.

I teach a class on GNU tools, called Embedded GNU Jumpstart. We use ARM 
boards in that class, and yes, we write exception/interrupt handlers and 
the corresponding vector code.

See also the ARM Architecture Reference Manual, by David Seal. It 
contains some brief examples too.


Regards,


b.g.


Thierry Moreau wrote:

>Toralf Lund wrote:
>
>  
>
>>I'm wondering about how to set up the interrupt vectors correctly on an
>>ARM-9 setup w/o debug monitors. Has anyone else done this? Is there any
>>kind of support for it in newlib? I mean, is the code that needs to be
>>loaded at address 0 included anywhere? (That would not be the normal
>>_start code, as far as I can tell.)
>>    
>>
>
>Ah! When a developer says "my project is so small, no need for an O/S", he
>removes everything from kernels (e.g. no inter-process messages), libraries
>(e.g. no file i/o), and tools (e.g. no ) ... so far, so good.
>
>Then, remains a bare CPU, and an application software design, and
>hardware-triggered events. A neat and simple execution environment. Yes, the
>developer can do the processor initialization that ocsurs before the main()
>instruction ... and the system flash programming tools (that were needed
>anyway).
>
>The fun actually starts when the developer needs interrupt dispatching ... the
>developer actually needs to re-invent (piecewise and painfully) what was removed
>
>in the first place. Among those pieces, there is some science that goes beyond
>the mere technicalities of processor initialization and flash programming.
>
>I'm suggesting that you should consider kernels in the "deeply embedded" kernel
>category (or "hard real-time", not because you need hard real-time but because
>those kernels are perhaps features-lean). E.g. the ABCD Proto-Kernel(tm) (
>http://www.connotech.com/abcd_proto_kernel/abcd_proto_kernel_intro.htm ), but it
>
>is defnitely not the only one.
>
>Cheers
>
>--
>
>- Thierry Moreau
>
>CONNOTECH Experts-conseils inc.
>9130 Place de Montgolfier
>Montreal, Qc
>H2M 2A1
>
>Tel.: (514)385-5691
>Fax:  (514)385-5900
>
>web site: http://www.connotech.com
>e-mail: thierry.moreau@connotech.com
>====
>5.     Basic ABCD Concepts
>
>5.1     ‘A’ - Interrupt Dispatching
>
>A basic function of any operating system or kernel is to handle the
>microprocessor interrupts. This is usually closely tied to the microprocessor
>architecture. The ABCD Proto-Kernel™ provides a unified handling of interrupts
>that logically dispatch the interrupt signals to the interrupt service routine
>(ISR) that correspond to the exact source of the interrupt, as if the
>microprocessor had a large number of independent interrupt vectors. In doing so,
>
>the ABCD Proto-Kernel™ prepares the ISR execution context (some limitations
>apply to the software statements that make up the ISR). Lastly, the interrupt
>handling includes ISR epilogue facilities that restore a normal software task
>context once the ISR processing is complete.
>
>It is the application developers' responsibility to code the interrupt services
>routines required by the application, to register them with the ABCD
>Proto-Kernel™ interrupt dispatching, and to request the enabling of the
>interrupt source associated with each ISR.
>
>
>
>------
>Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
>Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
>
>  
>



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com



More information about the crossgcc mailing list