[ECOS] VGCC that supports eCos for ARM THUMB

[ECOS] VGCC that supports eCos for ARM THUMB

[Odd Lindahl]

> Does anyone know what the latest version of GCC is that supports eCos for
> ARM THUMB.
> 
> Accordingly to http://sources.redhat.com/ecos/tools/win-thumb-elf.html:
> "the most official release of (GCC 2.95.2) is not capable of supporting
> eCos for ARM THUMB."
> and that "eCos has been tested with the 2000-03-13 snappshot"
> 
> I haven't been able to locate such an old version of GCC though.
> 
> /odd
> 

Re: [ECOS] VGCC that supports eCos for ARM THUMB

[Lewin A.R.W. Edwards]

> > Accordingly to http://sources.redhat.com/ecos/tools/win-thumb-elf.html:
> > "the most official release of (GCC 2.95.2) is not capable of supporting
> > eCos for ARM THUMB."
> > and that "eCos has been tested with the 2000-03-13 snappshot"

You can do a CVS checkout of that date. However, it didn't work for me - I 
don't know what magic Red Hat put in to make this statement.

At this time, I consider thumb support broken for eCos, and I'm waiting for 
gcc updates...

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

[ECOS] Custom Device Driver

[Andy Simpkins]

I am integrating a GPS receiver into eCos, the problem is that the IP for
this is in the form of an ARM ADS library.  To overcome this problem I
simply call the appropriate routine in memory when one of the relevant
interrupts are received.  The calling function takes the form of an eCos
device driver.  Great everything works, eCos and the GPS engine.

The GPS engine currently flashes LEDs when a GPS event occurs.  What I am
now trying to do is get events generated by the GPS engine to be recognised
by eCos.  These events happen for example when there is position information
available.

1. How would one go about incorporating this into a device driver?
2. How should I then pass this information out to interested threads?
3. I am guessing that the thread would treat this in much the same way as a
serial device but the data will be a single event code (probably one byte)?

Any ideas of how to approach this would be most helpful.


Andy

Re: [ECOS] Custom Device Driver

[Jonathan Larmour]

Andy Simpkins wrote:
> 
> I am integrating a GPS receiver into eCos, the problem is that the IP for
> this is in the form of an ARM ADS library.  To overcome this problem I
> simply call the appropriate routine in memory when one of the relevant
> interrupts are received.  The calling function takes the form of an eCos
> device driver.  Great everything works, eCos and the GPS engine.
> 
> The GPS engine currently flashes LEDs when a GPS event occurs.  What I am
> now trying to do is get events generated by the GPS engine to be recognised
> by eCos.  These events happen for example when there is position information
> available.
> 
> 1. How would one go about incorporating this into a device driver?

Assuming it can deliver interrupts, write an ISR that acks the interrupt,
and returns a code instructing eCos to call a DSR.

> 2. How should I then pass this information out to interested threads?

Create a message box, and in the DSR, put the information in that. The
threads can then read out of it.

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

RE: [ECOS] Custom Device Driver

[Andy Simpkins]

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 :-)

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?

Andy

-----Original Message-----
From: jlarmour@cambridge.redhat.com
[ mailto:jlarmour@cambridge.redhat.com]On Behalf Of Jonathan Larmour
Sent: 27 March 2001 16:44
To: Andy.Simpkins@TardisMobile.com
Cc: eCos discussion
Subject: Re: [ECOS] Custom Device Driver


Andy Simpkins wrote:
>
> I am integrating a GPS receiver into eCos, the problem is that the IP for
> this is in the form of an ARM ADS library.  To overcome this problem I
> simply call the appropriate routine in memory when one of the relevant
> interrupts are received.  The calling function takes the form of an eCos
> device driver.  Great everything works, eCos and the GPS engine.
>
> The GPS engine currently flashes LEDs when a GPS event occurs.  What I am
> now trying to do is get events generated by the GPS engine to be
recognised
> by eCos.  These events happen for example when there is position
information
> available.
>
> 1. How would one go about incorporating this into a device driver?

Assuming it can deliver interrupts, write an ISR that acks the interrupt,
and returns a code instructing eCos to call a DSR.

> 2. How should I then pass this information out to interested threads?

Create a message box, and in the DSR, put the information in that. The
threads can then read out of it.

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

Re: [ECOS] Custom Device Driver

[Jonathan Larmour]

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