SH Question

[Joel Sherrill]

Fernando RUIZ CASAS wrote:
> 
> > -----Mensaje original-----
> > De: joel [mailto:joel]En nombre de Joel Sherrill
> > Enviado el: viernes, 29 de diciembre de 2000 22:01
> > Para: rtems-users at OARcorp.com
> > Asunto: SH Question
> >
> >
> >
> > I am trying to reduce the duplication between sh7032 and sh7045 in the
> > libcpu code.  In particular, I believe it should be possible to have
> > a single copy of the context switch and interrupt dispatching code.
> > But I have run into a routine that I can't figure out how portable
> > it really is .. so how portable is the routine
> > sh_set_irq_priority()?
> >
> > I am leaning toward creating "shared", "sh1", and "sh2"
> > subdirectories.
> >
> > I would also think that the /dev/null driver could be moved to a
> > non-SH directory.
> >
> > Comments, suggestions?
> >
> >
> > --
> > Joel Sherrill, Ph.D.             Director of Research & Development
> > joel at OARcorp.com                 On-Line Applications Research
> > Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> >    Support Available             (256) 722-9985
> >
> 
> Hi, Joel.
> 
> I am Fernando.
> 
> /dev/null is for a simulated link to console because the hard links are not
> present
> when Ralf(?) writed it. (I suppose)
> /dev/null is better to place it with /dev/stub in (?).

/dev/stub is a test fixture and is in the test source tree.
I think /dev/null could go in libmisc without too much
worry.

> I have a termios driver terminal for sh console.
> I have two ports /dev/sci0 and /dev/sci1 and a HARD LINK /dev/console into
> /dev/sciX.
> The sci drivers works with interrupts very well.

Nice to hear.

> Perhaps the moment to update it?
> Have you hardware to probe it the changes?
> Are you interested in updates?

Always.  :)

My concern is that the sh family is a set of CPU cores plus
peripherals.  The context switch and interrupt dispatching code is
almost certainly shareable across the entire family with
careful ifdefs.  The peripherals are also probably shareable
to some extent since there is likely a set of them that 
can be glued to the various cores.  My main concern
is getting the code that is only dependent on the CPU core 
out of the particular model directories.


> Happy new year at all rtems-users

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985