[ECOS] On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[ECOS] On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Grant Edwards]

I've got an application where some low-level interrupt driven
stuff needs to happen with minimal latency (a hard deadline of
20us). It's an ARM7 running at 22Mhz, and preliminary
measurements indicate that the eCos ISR latency is going to be
too large.

One thought was to use IRQ for normal eCos stuff, and dedicate
FIQ to the low-latency stuff.  The theory was that since the
FIQ service routine wouldn't do anything with any eCos data
structures, it would be allowed to interrupt normal eCos ISRs.
That would allow the FIQ latency to be kept low.

From looking at the ARM/arch hal stuff, it looks like eCos
expects to handle both IRQ and FIQ interrupts.  AFAICT, all of
the interrupt sources in my part (Samsung S3C4530) can be
assigned to either IRQ or FIQ.

Is there any reason why eCos has to have control of both
interrupt sources if all of the peripherals which eCos is
handling are on just one of them?

-- 
Grant Edwards                   grante             Yow! Nipples, dimples,
                                  at               knuckles, NICKLES,
                               visi.com            wrinkles, pimples!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Chris Zimman]

> From looking at the ARM/arch hal stuff, it looks like eCos
> expects to handle both IRQ and FIQ interrupts.  AFAICT, all of
> the interrupt sources in my part (Samsung S3C4530) can be
> assigned to either IRQ or FIQ.
> 
> Is there any reason why eCos has to have control of both
> interrupt sources if all of the peripherals which eCos is
> handling are on just one of them?

Just change the FIQ vector to point to your handler.  I don't know of
anything that uses FIQ right now anyhow.

--Chris

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Grant Edwards]

On 2008-04-02, Chris Zimman <czimman@bloomberg.com> wrote:

>> From looking at the ARM/arch hal stuff, it looks like eCos
>> expects to handle both IRQ and FIQ interrupts.  AFAICT, all of
>> the interrupt sources in my part (Samsung S3C4530) can be
>> assigned to either IRQ or FIQ.
>> 
>> Is there any reason why eCos has to have control of both
>> interrupt sources if all of the peripherals which eCos is
>> handling are on just one of them?
>
> Just change the FIQ vector to point to your handler.  I don't
> know of anything that uses FIQ right now anyhow.

I just double-checked the initialization code for my HAL (it's
a custom one), and it is indeed configuring all of the
interrupts currently in use to use IRQ, so nothing is using
FIQ.

However, there quite a few spots in the arm/arch interrupt and
exception handling code where FIQ is being disabled.  It looks
like I'd have to fork the arch code and modify it to prevent it
from disabling FIQ.

I suppose the right thing to do would be to make the arm/arch
stuff configurable via CDL so that it would use either FIQ or
IRQ or both.

-- 
Grant Edwards                   grante             Yow! ... I want FORTY-TWO
                                  at               TRYNEL FLOATATION SYSTEMS
                               visi.com            installed within SIX AND A
                                                   HALF HOURS!!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Chris Zimman]

> However, there quite a few spots in the arm/arch interrupt and
> exception handling code where FIQ is being disabled.  It looks
> like I'd have to fork the arch code and modify it to prevent it
> from disabling FIQ.

Yes, there definitely is that issue.  It's not too many places that 
have to be updated though.
 
> I suppose the right thing to do would be to make the arm/arch
> stuff configurable via CDL so that it would use either FIQ or
> IRQ or both.

I would think what you'd want to do is to provide a function to change 
the FIQ vector after eCos has started.  If you start things without 
the FIQ vector assigned, and for whatever reason it fires, you're in 
trouble.  With regards to CDL, I don't know that it would make sense to 
have a CDL option to not have eCos own the FIQ vector on startup.

--Chris

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Grant Edwards]

On 2008-04-02, Chris Zimman <czimman@bloomberg.com> wrote:

>> However, there quite a few spots in the arm/arch interrupt and
>> exception handling code where FIQ is being disabled.  It looks
>> like I'd have to fork the arch code and modify it to prevent
>> it from disabling FIQ.
>
> Yes, there definitely is that issue.  It's not too many places
> that have to be updated though.
>  
>> I suppose the right thing to do would be to make the arm/arch
>> stuff configurable via CDL so that it would use either FIQ or
>> IRQ or both.
>
> I would think what you'd want to do is to provide a function
> to change the FIQ vector after eCos has started.

That's easy enough, but it'd be trickier to provide a run-time
function to fix the places in vectors.S that are currently
disabling FIQ.

> If you start things without the FIQ vector assigned, and for
> whatever reason it fires, you're in trouble.

True.

> With regards to CDL, I don't know that it would make sense to
> have a CDL option to not have eCos own the FIQ vector on
> startup.

The main point of the CDL would be to avoid having to fork the
arm/arch code.  I don't really like maintaining my own separate
versions of files unless I absolutely have to.  Besides,
somebody else might actually want to use the new "feature".

-- 
Grant Edwards                   grante             Yow! I feel ... JUGULAR ...
                                  at               
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Andrew Lunn]

> I would think what you'd want to do is to provide a function to change 
> the FIQ vector after eCos has started. 

It already exists.

void cyg_interrupt_get_vsr(cyg_vector_t vector, cyg_VSR_t** vsr);

void cyg_interrupt_set_vsr(cyg_vector_t vector, cyg_VSR_t* vsr);

with the vector CYGNUM_HAL_VECTOR_FIQ.

The vsr function needs to be written in assembly and save and restore
all registers etc.

     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

Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Alexander Neundorf]

On Wednesday 02 April 2008, Grant Edwards wrote:
...
> The main point of the CDL would be to avoid having to fork the
> arm/arch code.  I don't really like maintaining my own separate
> versions of files unless I absolutely have to.  Besides,
> somebody else might actually want to use the new "feature".

Yes. I think providing an official way how to use the FIQ with lowest possible 
overhead under eCos would be good. Some kind of communication with eCos is 
required I think, e.g. a recommended way how to generate a regular interrupt 
so that if some condition is detected in the FIQ handler a regular ISR can 
overtake.

Alex

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Grant Edwards]

On 2008-04-02, Andrew Lunn <andrew@lunn.ch> wrote:

>> I would think what you'd want to do is to provide a function to change 
>> the FIQ vector after eCos has started. 
>
> It already exists.
>
> void cyg_interrupt_get_vsr(cyg_vector_t vector, cyg_VSR_t** vsr);
>
> void cyg_interrupt_set_vsr(cyg_vector_t vector, cyg_VSR_t* vsr);
>
> with the vector CYGNUM_HAL_VECTOR_FIQ.

That would work.  It would save a few clock cycles to set the
vector in the actual vector table rather than in the secondary
indirect one, but I don't know if it's worth the extra hassle.

> The vsr function needs to be written in assembly and save and restore
> all registers etc.

Yup.

-- 
Grant Edwards                   grante             Yow! Don't SANFORIZE me!!
                                  at               
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Andrew Lunn]

On Wed, Apr 02, 2008 at 09:25:19PM +0200, Alexander Neundorf wrote:
> On Wednesday 02 April 2008, Grant Edwards wrote:
> ...
> > The main point of the CDL would be to avoid having to fork the
> > arm/arch code.  I don't really like maintaining my own separate
> > versions of files unless I absolutely have to.  Besides,
> > somebody else might actually want to use the new "feature".
> 
> Yes. I think providing an official way how to use the FIQ with lowest possible 
> overhead under eCos would be good. Some kind of communication with eCos is 
> required I think, e.g. a recommended way how to generate a regular interrupt 
> so that if some condition is detected in the FIQ handler a regular ISR can 
> overtake.

I've done this before, but it used hardware support.

The Intel StrongARM interrupt controller had a bit you could set to
cause an IRQ interrupt to happen. So in the FIQ you hit this bit and
exit the FIQ. Once interrupts are re-enabled the IRQ goes off and you
are in normal eCos interrupt context.

I don't know of a generic way to do this. There is no standardised
interrupt controller for ARMs.

          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

[ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Grant Edwards]

On 2008-04-02, Alexander Neundorf <neundorf@kde.org> wrote:
> On Wednesday 02 April 2008, Grant Edwards wrote:
> ...
>> The main point of the CDL would be to avoid having to fork the
>> arm/arch code.  I don't really like maintaining my own
>> separate versions of files unless I absolutely have to.
>> Besides, somebody else might actually want to use the new
>> "feature".
>
> Yes. I think providing an official way how to use the FIQ with
> lowest possible overhead under eCos would be good. Some kind
> of communication with eCos is required I think, e.g. a
> recommended way how to generate a regular interrupt so that if
> some condition is detected in the FIQ handler a regular ISR
> can overtake.

I was thinking about that.  We're not sure yet if we need to be
able to do that or not -- I'm guessing we will probably want to.

Is there a platform-independant way to trigger an ISR from
software?  IIRC, it's pretty easy to do so with the interrupt
controller in the part I'm using, but that's platform
dependent.  That doesn't mean it can't be done, it just means
that everybody who wants to do that would have to add support
to the HAL that they're using.

-- 
Grant Edwards                   grante             Yow! I'm ANN LANDERS!!
                                  at               I can SHOPLIFT!!
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Andrew Lunn]

On Wed, Apr 02, 2008 at 07:26:25PM +0000, Grant Edwards wrote:
> On 2008-04-02, Andrew Lunn <andrew@lunn.ch> wrote:
> 
> >> I would think what you'd want to do is to provide a function to change 
> >> the FIQ vector after eCos has started. 
> >
> > It already exists.
> >
> > void cyg_interrupt_get_vsr(cyg_vector_t vector, cyg_VSR_t** vsr);
> >
> > void cyg_interrupt_set_vsr(cyg_vector_t vector, cyg_VSR_t* vsr);
> >
> > with the vector CYGNUM_HAL_VECTOR_FIQ.
> 
> That would work.  It would save a few clock cycles to set the
> vector in the actual vector table rather than in the secondary
> indirect one, but I don't know if it's worth the extra hassle.

It is directly in the vector table, normally at address 0x20 for the
beginning of the table and the FIQ entry at 0x3C. You cannot put an
address at 0x1C, it has to be an instruction, and you have limited
branch range so cannot make it generic.

       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

[ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Grant Edwards]

On 2008-04-02, Andrew Lunn <andrew@lunn.ch> wrote:

>> > void cyg_interrupt_set_vsr(cyg_vector_t vector, cyg_VSR_t* vsr);
>> >
>> > with the vector CYGNUM_HAL_VECTOR_FIQ.
>> 
>> That would work.  It would save a few clock cycles to set the
>> vector in the actual vector table rather than in the secondary
>> indirect one, but I don't know if it's worth the extra hassle.
>
> It is directly in the vector table, normally at address 0x20 for the
> beginning of the table and the FIQ entry at 0x3C. You cannot put an
> address at 0x1C, it has to be an instruction, and you have limited
> branch range so cannot make it generic.

Ah, right.  I had forgotten about the address vs. instruction
piece of the puzzle.  I was thinking you put an address at
0x1C.

-- 
Grant Edwards                   grante             Yow! if it GLISTENS,
                                  at               gobble it!!
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Grant Edwards]

On 2008-04-02, Andrew Lunn <andrew@lunn.ch> wrote:

>> Yes. I think providing an official way how to use the FIQ with
>> lowest possible overhead under eCos would be good. Some kind
>> of communication with eCos is required I think, e.g. a
>> recommended way how to generate a regular interrupt so that if
>> some condition is detected in the FIQ handler a regular ISR
>> can overtake.
>
> I've done this before, but it used hardware support.
>
> The Intel StrongARM interrupt controller had a bit you could
> set to cause an IRQ interrupt to happen. So in the FIQ you hit
> this bit and exit the FIQ. Once interrupts are re-enabled the
> IRQ goes off and you are in normal eCos interrupt context.

How did eCos know where the interrupt came from?  Did that bit
you set have it's own unique hardware-generated ID value?

> I don't know of a generic way to do this. There is no
> standardised interrupt controller for ARMs.

I think it's going to be target-dependent.

-- 
Grant Edwards                   grante             Yow! I'll eat ANYTHING
                                  at               that's BRIGHT BLUE!!
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Andrew Lunn]

> Is there a platform-independant way to trigger an ISR from
> software? 

I don't think so. The function to actually handle the interrupt,
hal_IRQ_handler() is in the platform package, not the architecture
package. hal_IRQ_handler() asks the interrupt controller what
triggered the interrupt and that is all platform dependent.

          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

Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Andrew Lunn]

On Wed, Apr 02, 2008 at 07:36:21PM +0000, Grant Edwards wrote:
> On 2008-04-02, Andrew Lunn <andrew@lunn.ch> wrote:
> 
> >> Yes. I think providing an official way how to use the FIQ with
> >> lowest possible overhead under eCos would be good. Some kind
> >> of communication with eCos is required I think, e.g. a
> >> recommended way how to generate a regular interrupt so that if
> >> some condition is detected in the FIQ handler a regular ISR
> >> can overtake.
> >
> > I've done this before, but it used hardware support.
> >
> > The Intel StrongARM interrupt controller had a bit you could
> > set to cause an IRQ interrupt to happen. So in the FIQ you hit
> > this bit and exit the FIQ. Once interrupts are re-enabled the
> > IRQ goes off and you are in normal eCos interrupt context.
> 
> How did eCos know where the interrupt came from?  Did that bit
> you set have it's own unique hardware-generated ID value?

Yep. CYGNUM_HAL_INTERRUPT_SOFT_IRQ, So you just register an interrupt
handler for this as normal. When the interrupt fires the interrupt
controller say a soft IRQ has gone off when hal_IRQ_handler() asks it.

        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

Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[David Roethig]

Andrew Lunn wrote:
>> I would think what you'd want to do is to provide a function to change 
>> the FIQ vector after eCos has started. 
>>     
>
> It already exists.
>
> void cyg_interrupt_get_vsr(cyg_vector_t vector, cyg_VSR_t** vsr);
>
> void cyg_interrupt_set_vsr(cyg_vector_t vector, cyg_VSR_t* vsr);
>
> with the vector CYGNUM_HAL_VECTOR_FIQ.
>
> The vsr function needs to be written in assembly and save and restore
> all registers etc.
>
>      Andrew
>
>   

We implemented a similar solution for a hard-time requirement of 300us.
In our application, we read ADC values and store them away.

Here are the notes for the setup:
// **************************
// This exception handler replaces the standard FIQ handler
// located in vectors.S. It is specific for the <name changed>
// application.
//
// To use this replacement FIQ handler:
//  1) modify linker file:
//     The linker file needs to be modified so that the HAL_VSR_SET()
//     macro works correctly.
//     In the file mlt_arm_lpc2xxx_<name changed>.ldi, change:
//
//        SECTION_fixed_vectors (ram, 0x40000040, LMA_EQ_VMA)
//     to
//        SECTION_fixed_vectors (ram, 0x40000020, LMA_EQ_VMA)
//
//     This locates hal_vsr_table at 0x40000020 (on-chip RAM).
//     hal_vsr_table is not used (except we are using it now!).
//
//     this assumes running from flash with exception vector located
//     in on-chip RAM (MEMMAP=2).
//
//  2) HAL_VSR_SET
//     The initialization code needs to replace the existing FIQ
//     handler with the application specific one. This call is
//     located in hal_api_analog_init() which is called with
//     interrupts disabled (MUST!).
//
//        extern void APPFIQ (void);
//
//        /* set APPFIQ to be the FIQ handler */
//        HAL_VSR_SET(CYGNUM_HAL_VECTOR_FIQ, APPFIQ, NULL);
//
//


A timer is used to trigger the ADC to start sampling:

/* ***                              *** */
/* set up timer for 300us reading cycle */

/* Disable and reset counter */
HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxTCR, 
2);

/* set prescale register to 0 */
HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxPR, 
0);

/* clear all interrupts */
HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxIR, 
0xffffffff);

/* clear all match/capture control settings */
HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxMCR, 
0);

/*   */
HAL_READ_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxEMR, 
regTemp);
HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxEMR, 
(2 << 4)); 

/* Set up match register (plus extra for first time) */
HAL_READ_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxTC, 
regTemp);
HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxMR0,
               (regTemp + 17695 + 0x00ffffff));  /* add a fudge factor 
for initialization */

/* Enable counter */
HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxTCR, 
1);

/* ***                                                               *** */
/* set up ADC divisor                                                    */
/* enable with a divisor of 14 (-> ~4.2MHz)                              */
/* With an input clock of ~58.98MHz, this results in a clock of ~4.2MHz. */
/* turn the adc 'on'                                                     */
 
/* ***                                                            *** */
/* set up ADC to sample channel 0 sample dependent upon MR0 of Timer1 */

/* set the timing, enable the power */
HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_AD_BASE+CYGARC_HAL_LPC2XXX_REG_ADCR,
              (CYGARC_HAL_LPC2XXX_REG_ADCR_PDN) |       /* power enable */
               (13 << 8)                         );      /* clkdiv 
(~4.2MHz) */

/* sample channel 0 */
HAL_READ_UINT32(CYGARC_HAL_LPC2XXX_REG_AD_BASE+CYGARC_HAL_LPC2XXX_REG_ADCR, 
regTemp);
HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_AD_BASE+CYGARC_HAL_LPC2XXX_REG_ADCR,
               ((regTemp & 0xffffff00) | (1 << 6))  );   /* channel 6 */

/* START = '110' -> MR0 of Timer1 */
HAL_READ_UINT32(CYGARC_HAL_LPC2XXX_REG_AD_BASE+CYGARC_HAL_LPC2XXX_REG_ADCR, 
regTemp);
HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_AD_BASE+CYGARC_HAL_LPC2XXX_REG_ADCR,
               (  (regTemp & (~(7<<24))) | ((6 << 24) ) ) );      /* 110 
-> start MAT1.0 */


/* ***                                *** */
/* set up ADC interrupt as FIQ and enable */

/* set interrupt as FIQ */
HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_VIC_BASE+CYGARC_HAL_LPC2XXX_REG_VICINTSELECT,
               (1<<CYGNUM_HAL_INTERRUPT_AD));

/* enable interrupt */
cyg_interrupt_unmask(CYGNUM_HAL_INTERRUPT_AD);


The APPFIQ code is written in assembler and just saves some stack
and calls the handler routine.




I hope this wasn't too much detail...
 - Dave



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Andrew Lunn]

> Here are the notes for the setup:
> // **************************
> // This exception handler replaces the standard FIQ handler
> // located in vectors.S. It is specific for the <name changed>
> // application.
> //
> // To use this replacement FIQ handler:
> //  1) modify linker file:
> //     The linker file needs to be modified so that the HAL_VSR_SET()
> //     macro works correctly.
> //     In the file mlt_arm_lpc2xxx_<name changed>.ldi, change:
> //
> //        SECTION_fixed_vectors (ram, 0x40000040, LMA_EQ_VMA)
> //     to
> //        SECTION_fixed_vectors (ram, 0x40000020, LMA_EQ_VMA)
> //
> //     This locates hal_vsr_table at 0x40000020 (on-chip RAM).
> //     hal_vsr_table is not used (except we are using it now!).

Interesting. It looks like all lpc2xxx platforms are broken in the
same way...

     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

Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Alexander Neundorf]

On Wednesday 02 April 2008, Andrew Lunn wrote:
> > Is there a platform-independant way to trigger an ISR from
> > software?
>
> I don't think so. The function to actually handle the interrupt,
> hal_IRQ_handler() is in the platform package, not the architecture
> package. hal_IRQ_handler() asks the interrupt controller what
> triggered the interrupt and that is all platform dependent.

Could that be hidden by some HAL macro ?

Alex



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Paul D. DeRocco]

> From: Grant Edwards
>
> That's easy enough, but it'd be trickier to provide a run-time
> function to fix the places in vectors.S that are currently
> disabling FIQ.

I think the issue is that there are lots of small critical sections
scattered all over the place that mask interrupts in the CPU, and they
currently mask both IRQ and FIQ. For the ARM, HAL_*_INTERRUPTS uses 0xC0 to
manipulate both these bits. If all eCos ISRs are invoked via IRQ, and FIQ is
reserved for a special bit of driver code that merely adds functionality to
a piece of hardware (like adding a FIFO to a serial port) without invoking a
DSR, then these macros really ought to use 0x80 instead. That would be a
useful CDL option.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Grant Edwards]

On 2008-04-02, Andrew Lunn <andrew@lunn.ch> wrote:
> On Wed, Apr 02, 2008 at 07:36:21PM +0000, Grant Edwards wrote:
>> On 2008-04-02, Andrew Lunn <andrew@lunn.ch> wrote:
>> 
>> >> Yes. I think providing an official way how to use the FIQ with
>> >> lowest possible overhead under eCos would be good. Some kind
>> >> of communication with eCos is required I think, e.g. a
>> >> recommended way how to generate a regular interrupt so that if
>> >> some condition is detected in the FIQ handler a regular ISR
>> >> can overtake.
>> >
>> > I've done this before, but it used hardware support.
>> >
>> > The Intel StrongARM interrupt controller had a bit you could
>> > set to cause an IRQ interrupt to happen. So in the FIQ you hit
>> > this bit and exit the FIQ. Once interrupts are re-enabled the
>> > IRQ goes off and you are in normal eCos interrupt context.
>> 
>> How did eCos know where the interrupt came from?  Did that bit
>> you set have it's own unique hardware-generated ID value?
>
> Yep. CYGNUM_HAL_INTERRUPT_SOFT_IRQ, So you just register an interrupt
> handler for this as normal. When the interrupt fires the interrupt
> controller say a soft IRQ has gone off when hal_IRQ_handler() asks it.

That's pretty much ideal.  I don't remember seeing a feature
like that on my part, but I believe I can manually set the
interrupt request flag for one of the unused external
interrupt/port  pins.

-- 
Grant Edwards                   grante             Yow! Could I have a drug
                                  at               overdose?
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Grant Edwards]

On 2008-04-02, David Roethig <droethig@cipher.com> wrote:

> We implemented a similar solution for a hard-time requirement of 300us.
> In our application, we read ADC values and store them away.
>
>
> Here are the notes for the setup:

Thanks!

That'll be very helpful.

-- 
Grant Edwards                   grante             Yow! Am I in GRADUATE
                                  at               SCHOOL yet?
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff?

[Grant Edwards]

On 2008-04-02, Paul D. DeRocco <pderocco@ix.netcom.com> wrote:
>> From: Grant Edwards
>>
>> That's easy enough, but it'd be trickier to provide a run-time
>> function to fix the places in vectors.S that are currently
>> disabling FIQ.
>
> I think the issue is that there are lots of small critical sections
> scattered all over the place that mask interrupts in the CPU, and they
> currently mask both IRQ and FIQ. For the ARM, HAL_*_INTERRUPTS uses 0xC0 to
> manipulate both these bits. If all eCos ISRs are invoked via IRQ, and FIQ is
> reserved for a special bit of driver code that merely adds functionality to
> a piece of hardware (like adding a FIFO to a serial port) without invoking a
> DSR, then these macros really ought to use 0x80 instead. That would be a
> useful CDL option.

Exactly.  We can leave the FIQ handler code there, and just
overried it by pointing the VSR table entry elsewhere. But, the
places (e.g. in vectors.S) that are disabling and enabling
FIQ+IRQ need to be changed so that they only disable/enable
the right one(s).

-- 
Grant Edwards                   grante             Yow! WHOA!!  Ken and Barbie
                                  at               are having TOO MUCH FUN!!
                               visi.com            It must be the NEGATIVE
                                                   IONS!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss