This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Porting question
- From: Gary Thomas <gary at mlbassoc dot com>
- To: bob dot koninckx at o-3s dot com
- Cc: eCos Discussion <ecos-discuss at ecos dot sourceware dot org>
- Date: Fri, 06 May 2005 06:19:17 -0600
- Subject: Re: [ECOS] Porting question
- References: <1115378197.5655.23.camel@pc-006.vuilenbos.net>
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