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.
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
