Guidance required for PIC API

[Vipul Nayyar]

________________________________
 From: Joel Sherrill <joel.sherrill at oarcorp.com>
To: rtems-devel at rtems.org; Vipul Nayyar <nayyar_vipul at 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_vipul at 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.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805 
Support Available                (256) 722-9985 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130616/7b5ac3c8/attachment-0001.html>