From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13092 invoked by alias); 6 May 2005 12:19:27 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 13010 invoked from network); 6 May 2005 12:19:19 -0000 Received: from unknown (HELO hermes.chez-thomas.org) (206.168.96.204) by sourceware.org with SMTP; 6 May 2005 12:19:19 -0000 Received: by hermes.chez-thomas.org (Postfix, from userid 2000) id 5C5266FD227; Fri, 6 May 2005 06:19:19 -0600 (MDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by hermes.chez-thomas.org (Postfix) with ESMTP id 18EBB10000C; Fri, 6 May 2005 06:19:18 -0600 (MDT) From: Gary Thomas To: bob.koninckx@o-3s.com Cc: eCos Discussion In-Reply-To: <1115378197.5655.23.camel@pc-006.vuilenbos.net> References: <1115378197.5655.23.camel@pc-006.vuilenbos.net> Content-Type: text/plain Date: Fri, 06 May 2005 12:19:00 -0000 Message-Id: <1115381957.5511.240.camel@hermes> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [ECOS] Porting question X-SW-Source: 2005-05/txt/msg00066.txt.bz2 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