This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Custom Device Driver
- To: Andy dot Simpkins at TardisMobile dot com
- Subject: Re: [ECOS] Custom Device Driver
- From: Jonathan Larmour <jlarmour at redhat dot com>
- Date: Tue, 27 Mar 2001 18:15:15 +0100
- Cc: eCos discussion <ecos-discuss at sources dot redhat dot com>
- Organization: Red Hat UK Ltd.
- References: <NEBBKCPHAKKLBOKILBONGEHOCBAA.Andy.Simpkins@TardisMobile.com>
Andy Simpkins wrote:
>
> Assuming that I read you right, Can Software raise an interrupt on an ARM
> core?
> How would this be trapped in the low level ISR (in ##platform##_misc.c) to
> determine the vector?
> No Can't have understood properly :-)
If no interrupt is delivered, then you would probably want a separate
thread that polls the device, and (again) uses an mbox to give results to
other threads that want it.
> True there is an ISR raised that causes me to vector to the GPS engine's ISR
> this may result in 0, 1 or more events being raised. It's getting these
> events into my DSR that is causing me grief (mainly because the IP we have
> is not all in source form - hence the ADS library). I do not have a clear
> picture of the execution thread of this IP. I do have an routine in ADS
> that is called whenever a GPS event occurs - can I use a callback into the
> device driver to populate a message box as you suggest?
This would be an ISR, not a DSR right? In which case don't do it like that
- message box operations are not safe in ISRs, only DSRs.
But by the sound of it what you want to do is call the GPS engine's ISR in
your *DSR*, and then use the message box options from your callback then.
Just remember to acknowledge the interrupt in your real ISR.
At a guess anyway.
Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine