ARM and interrupts

[Toralf Lund]

Bill Gatliff wrote:

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

Yes. I'm pretty sure anything like Linux isn't called for in my case. 
I'd probably require only about 2% of the functionality, and I don't 
want to do the extra work that I assume is necessary to get the other 
98% to work, or to have those laying around to complicate matters. KISS...

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

How about the stack pointer etc.? Do I have to set up that specifically 
for IRQ mode, too? Is the morale perhaps that I simply can't use the 
crt0 provided with newlib? (I was otherwise thinking that I might simply 
insert the vectors in front of it, if you now what I mean.)

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

I'll have a closer look at what you mention here...

We also found some example code for a test board from Motorola (we're 
actually using a Motorola CPU with ARM core), and it turns out that they 
also have an "Interrupt Controler" application note that's quite helpful 
(unlike the CPU reference manual, I might add..)

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