This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Porting question


On Fri, 2005-05-06 at 13:16 +0200, Bob Koninckx wrote:
> Hi list,
> 
> I got stuck when porting ecos to motorola's mpc565 processor. This
> variant is very similar to the mpc555, main differences lie in the on-
> chip peripherals (3 vs 2 CAN controllers, different MIOS etc...). At
> present, knowledge of on-chip peripherals is dealt with in the mpc5xx
> variant code. Apparently, it does not belong there ...
> 
> I was thinking of introducing subvariants of mpc5xx for mpc555 and
> mpc565 (similar to the quicc subvariant of mpc8xx). Considering the
> similarities between mpc555 and mpc565, this would imply duplication of
> lots of code.
> 
> Ideal would be to provide separate HALs for on-chip peripherals like
> TouCAN, MIOS, QADC etc ... These HALs could then provide
> 
>  * interrupt vector definitions
>  * interrupt mask / unmask / configure definitions
> 
> All the subvariants should do then is include the necessary device HALs
> and no code duplication would be necessary any more. I see however also
> some drawbacks with this approach:
> 
>  * the HAL directory is now processor / board oriented. Having a
> directory TouCAN at the same level as e.g. mpc8xx does not seem logical.
> Placing the device HALs in
> 
>  packages/hal/motorola/toucan
>  packages/hal/motorola/mios
>  packages/hal/motorola/qadc
> 
> is probably a better solution, especially since motorola uses the same
> devices with other cores than powerpc.
> 
>  * How to generate unique interrupt vector definitions if it is no
> longer done in one single location ?

Have you looked at how the SH HAL is structured?  Those processors
are similar in nature (lots of shared peripherals with a given
chip using some subset thereof).  It might be a way to go.

Also, if the differences are just number/type of peripherals, you
could use methods similar to what is used by 8xx/8xxx.  There, a 
given platform (CPU) will "implement" certain functionality.  The
generic code (quicc, etc) then knows how to support that.  

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]