Re: Porting question

[Nick Garnett <nickg at ecoscentric dot com>]

Gary Parnes <GaryP@logicpd.com> writes:

> Hello, I am starting a porting effort to get eCos running on one of our
> development platform kits:
> 
> http://www.logicpd.com/eps/sharp/devkits/sdk/default.php
> 
> using a Sharp LH-75401 core:
> 
> http://www.sharpsma.com/sma/products/mcu_soc/LH75401_splash.htm
> 
> 
> I want to make sure that I'm designing the package(s) properly, so I'm
> looking for a bit of feedback here.  It looks like some of the HAL efforts
> ended up combining the CPU and the board support package into one ball of
> wax (.../hal/arm/ebsa285, for instance).  Seeing as how the 75401 has a rich
> set of on-chip features, I get the feeling that, if I really want to do this
> right, I should be breaking things up into a processor layer and a board
> support layer.  For example:
> 
> ../hal/arm/sh75401/common/v2_0/... (which would contain headers and generic
> code for the LH-75401)
> ../hal/arm/sh75401/zoomdevkit/v2_0/... (which would contain headers and code
> specific to our Zoom DevKit offering)
>

Yes, apart from a slight change of terminology this is the recommended
way of doing it.


> Would you say that this is the proper way of doing things, or is taking an
> approach similar to the ebsa285 considered okay?

The ebsa285 is probably not a good example at this point, it's fairly
old. A better example, and one that is probably closer to what you
want, is the AT91 HAL. This consists of a variant HAL
(hal/arm/at91/var/...) plus platform hals for the various boards
supported.

The AT91 is only in the anoncvs repository at present. However, if you
intend to contribute your port back, it is best to do the work in the
anoncvs source tree anyway.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts