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



On 28-Jan-00 Dan Hovang wrote:
> Hugo 'NOx' Tyson wrote:
>> 
>> 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)
> 
> We need to be able to let the FIQ be enabled constantly, no exceptions.
> I've removed the eCos FIQ code and rely on the IRQ to handle any timer
> (scheduling) and devicedriver IRQ's. The goal is that it should be
> enough to disable the IRQ in any critical sections of the kernel and
> completely leave the FIQ to the application.
> 
>> It just *happens* that the CPU reg is preserved rather than always
>> re-enabled in load_context, because it doesn't really matter.
> 
> It does to me, I think ... :-)
> 

I agree [somewhat] with this approach.  Currently FIQ interrupts are 
handled using the eCos interrupt structure.  While this works, in design,
it is probably too heavy weight for most FIQ interrupts (the emphasis
should be on _fast_).

What I have done in the past with FIQ interrupts (I was working with one
that has a 11KHz rate with little tolerance for delay) was to install
a different FIQ VSR, using the normal eCos support.  The only problem
left was the one Dan mentions that IRQ processing in the system also
can mask the FIQ.  I solved this ad hoc, similar to what Dan did, but
I think the proper solution is to have the FIQ support configurable in
the sytem such that systems that want total control over the FIQ can
get it without have to "hack" the sources.


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