This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: on ARM: Using the FIQ vector



Dan Hovang <dan.hovang@cpen.com> writes:
> I'm using the FIQ vector to process data which arrives at a very high
> rate. My problem is that I'm unable to control the enable/disable FIQ
> bit of the cpsr. At first, I figured it was just to exclude the FIQ
> bit from the HAL_* macros but after some poking around I found that
> the FIQ bit has a per-thread value which is set every time a new thread
> is created (CPSR_THREAD_INITIAL in arm/arch/v1_2_1/src/hal_arch.h).

Yeah; the interrupt state of the CPU (FIQ and IRQ bits in the CPSR) is
preserved on a per-thread basis, and since starting a new thread is no
different from resuming a descheduled one, it has to be initialized to
*something* in a new thread.  And there will be as many folks who like the
value for *something* we chose as don't like it ;-)
 
This is all OK because the intention is that the scheduler will only ever
be called when interrupts are enabled, so in fact the state being preserved
is a constant both sources enabled - the code works out neater that way.

> The only workaround I see would be to exclude the FIQ bit from
> load_context in context.S aswell as from all relevant HAL_* macros.
> It feels like kind of a 'hack' tough. Is there some code design with
> the intention to solve this which I missed out?

Yup, changing load_context so it does not not change the FIQ bit would
likely work.

BUT the recommended solution is that your hardware should have an interrupt
disable in it - akin to the interrupt controller that's typically attached
to IRQ.  So you control whether you get FIQs or not using your hardware
register, which obviously eCos knows nothing about.

Put another way:

 o short-term masking of *all* interrupts is done using the CPU register,
and you shouldn't let a thread that has done this sleep whilst interrupts
are disabled.  (Macros with ENABLE/DISABLE/RESTORE in them)
 o longer-term masking of *particular* interrupts is done using the PIC or
whatever the platform has.  (Macros with MASK/UNMASK in them and a vector)

It just *happens* that the CPU reg is preserved rather than always
re-enabled in load_context, because it doesn't really matter.

The PIC state is of course quite separate from the CPU state and scheduling
has no effect on it.

HTH,
	- Huge

-- 
The 20th Century brought unprecedented increases in worldwide numeracy and
literacy and incredible advances in technology, science and mathematics.
It was also the only century in the past or in any reasonable predictable
future apparently to contain only 99 years.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]