This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Interrupts In MIPS....?
- To: ecos-discuss at sourceware dot cygnus dot com
- Subject: Re: [ECOS] Interrupts In MIPS....?
- From: Nick Garnett <nickg at cygnus dot co dot uk>
- Date: 05 Oct 2000 18:10:14 +0100
- Newsgroups: cygnus.sourceware.ecos.d
- Organization: Red Hat UK
- References: <39DA048B.23FEA384@pipinghotnetworks.com>
Colin Ford <colin.ford@pipinghotnetworks.com> writes:
> Hello,
>
> I've got a bit of a design question. Eventually I want
> to service all types of interrupts i.e. Ethernet, DMA,
> MII, UART, PCI etc.
>
> The problem I have is that all of these interrupts latch
> up to a bit in the "cause" register. Now the question
> I have is should I change the "hal_interrupt_handler" to
> call another handler to then check which actual
> peripheral caused the interrupt which in turn calls the
> devices ISR or should I go about it in a different way.
>
> I don't really know the philosophy of eCos enough to
> know what would be the best course of action?
>
Take a look in the VR4373 HAL for the model of what you should do.
The default interrupt VSR chooses a first ISR based on the cause
register bits. Three of the bits are connected to the interrupt
controller and the ISRs for these are springboard ISRs that decode the
controller's registers and revector to a second ISR further down the
table. This is hal_isr_springboard in platform.S in the VRC4373 HAL
package.
--
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK