Sorry, for sending this again, but,
Is there a distinction between old & new code. How do I identify it ?
Regards
Vipul Nayyar
________________________________
From: Vipul Nayyar <nayyar_vi...@yahoo.com>
To: Joel Sherrill <joel.sherr...@oarcorp.com>
Cc: "rtems-devel@rtems.org" <rtems-devel@rtems.org>
Sent: Saturday, 15 June 2013 11:44 PM
Subject: Re: Guidance required for PIC API
________________________________
From: Joel Sherrill <joel.sherr...@oarcorp.com>
To: rtems-devel@rtems.org; Vipul Nayyar <nayyar_vi...@yahoo.com>
Sent: Saturday, 15 June 2013 10:44 PM
Subject: Re: Guidance required for PIC API
Hi
I hate to reply to myself but to make the work flow clearer,
here is a rough view
For each area to be worked
- identify proper usage pattern
- document this pattern and put to rtems-devel for review
- final version with instructions goes in BSP and Device
Driver Guide
- implement script to find violations of pattern
- probably enhancements to check_subm ission or successor
- Fix violations
- Address "enhancements" that are not standard
- could be merged into main API/pattern
- Submit incrementally
As I mentioned for the PIC IRQ, there is a new "shared generic"
framework.
I know there are BSPs which should include more in their
Makefile.am but don't.
There are BSPs which use different names or have content in
differently named
files.
There is old IRQ code possibly lurking and possibly used.
SPARC has adaption of new shared PIC code implemented on top of
Simple
API. That code can be made generic.
Is there a distinction between old & new code. How do identify it ?
That's more or less a work plan for that topic.
On 6/15/2013 10:39 AM, Joel Sherrill wrote:
Unified implies all do things the same way with the same APIs, BSPs include all
the proper components and implement what is expected of them in a standard way.
Go back to my challenge question. The arm lpc24xx is probably a good reference.
What files does it share for generic IRQ handling? What files does if provide
itself? Do other BSPs using this framework on this and other architectures
include all the generic files? Use the same name for BSP specific ones? I
recall finding one BSP which did not include them all and an entire
architecture which put a method in a big file which is in a separate file on
other architectures. What are the rules for using shared generic IRQ API..
Write them down.. Automate checking them.. Present violations and fixes. If any
other implementations of PIC IRQ frameworks exist, we want to address getting
rid of them. There were predecessors of current code which may hang around.
After that, SPARC has an implementation of
shared IRQ PIC code for A SINGLE simple vectored architecture. That needs to
be available for all simple vectored targets. It is a layer on top .. That is
on. If the Gaisler code patches have additional functionality in this area, it
could be merged. But in a way that let's all targets use it. Vipul Nayyar
<nayyar_vi...@yahoo.com> wrote:
>Hello
>
>
>As part of my GSOC Project, I'll be implementing the PIC API on simple
>vectored architecture as a first step. I had hoped that I would've been a bit
>ahead as of now, but I'm kinda stuck in the basic stuff for now. Some points
>which I'm having trouble figuring out is :
>
>
>1) Which is the latest Programmable Interrupt Controller API that needs to be
>implemented, and where does it lie in the RTEMS code base ?
>2) How to identify which are simple vectored architectures ?
>3) Architectures like arm, i386, powerpc etc. which implement the desired PIC
>API, do not seem to have common code. I'm having trouble identifying which
>part of code is architecture dependent and which is common among different
>architectures.
>
>
>I'm currently going through the docs, especially the BSP How to Guide, given
>in the docs online for previous few days, but I've failed to grasp answers to
>the above questions. Thanks in advance for helping and guiding me out.
>
>
>Regards
>Vipul Nayyar
>
>
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
