This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: question about isr function signature (profiling)
- From: Andrew Lunn <andrew at lunn dot ch>
- To: Yuxin Jiang <yjiang at matrics dot com>
- Cc: Andrew Lunn <andrew at lunn dot ch>,Ecos-Discuss <ecos-discuss at sources dot redhat dot com>
- Date: Mon, 29 Mar 2004 18:26:41 +0200
- Subject: Re: [ECOS] question about isr function signature (profiling)
- References: <20040327182841.GG1515@lunn.ch> <LIEGIBEMFCHIDNLFFKKEKEJDCGAA.yjiang@matrics.com>
On Mon, Mar 29, 2004 at 11:10:37AM -0500, Yuxin Jiang wrote:
>
> Andrew:
>
> Thanks for your response.
>
> I have some more questions.
>
> 1, If the signature of the isr is correct, why in the documents it is always
> said to define a isr like:
>
> cyg_uint32
> isr_function(cyg_vector_t vector, cyg_addrword_t data)
> {
> cyg_bool_t dsr_required = 0;
>
> .
>
> return dsr_required ? CYG_ISR_CALL_DSR : CYG_ISR_HANDLED;
> }
>
> In this signature, there are only two parameters, not three. I am wondering
> if this is an undocumented feature, or maybe I am missing something here.
It is an undocumented feature. Not all architectures support passing
this 3rd parameter. I know ARM does. Being undocumented means it could
disappear in the future, but thats actually unlikely.
> 2, From your comment, I understand the pc value is for the *next*
> instruction. My question is, even though, do I get the correct pc value(the
> pc value saved by the interrupt) by the means in my code?
Yep, that should work. I've done this on ARM before and it works
properly for me.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss