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]

Porting question


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


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