This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Porting question
- From: Bob Koninckx <bob dot koninckx at o-3s dot com>
- To: ecos-discuss at sources dot redhat dot com
- Date: Fri, 06 May 2005 13:16:37 +0200
- Subject: [ECOS] Porting question
- Reply-to: bob dot koninckx at o-3s dot com
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 ?
All suggestions, comments are more than welcome,
Bob
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss