[ECOS] Are the HALs in the eCos repository meant for deployment?

[ECOS] Are the HALs in the eCos repository meant for deployment?

[Øyvind Harboe]

Are the HALs in the eCos repository meant for deployment?

I would expect the average PCB to be somewhat/quite similar to an
exisiting development board.  I would *not* expect that the average
product(hardware/software) would use some HAL completely unmodified.

Rather than tweaking an existing HAL (often a couple of changes are
sufficient), I would recommend to copy the existing HAL to a seperate
repository(including the section in the ecos.db) and then placing that
HAL before the snapshot of the eCos CVS HEAD. Renaming the HAL,
although I would encourage it, isn't stricly required and probably not
a lot of effort to rename at some later stage.

-- 
Øyvind Harboe
http://www.zylin.com

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are the HALs in the eCos repository meant for deployment?

[Gary Thomas]

Øyvind Harboe wrote:
> Are the HALs in the eCos repository meant for deployment?

Absolutely!  Every one that's in the repository is for some board or 
device that [at least at
some time in the past] existed and the platform could be built and run 
with no software "tweaks".

>
> I would expect the average PCB to be somewhat/quite similar to an
> exisiting development board.  I would *not* expect that the average
> product(hardware/software) would use some HAL completely unmodified.
>
> Rather than tweaking an existing HAL (often a couple of changes are
> sufficient), I would recommend to copy the existing HAL to a seperate
> repository(including the section in the ecos.db) and then placing that
> HAL before the snapshot of the eCos CVS HEAD. Renaming the HAL,
> although I would encourage it, isn't stricly required and probably not
> a lot of effort to rename at some later stage.
>


-- 
------------------------------------------------------------
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

Re: [ECOS] Are the HALs in the eCos repository meant for deployment?

[Øyvind Harboe]

On 8/14/06, Gary Thomas <gary@mlbassoc.com> wrote:
> Øyvind Harboe wrote:
> > Are the HALs in the eCos repository meant for deployment?
>
> Absolutely!  Every one that's in the repository is for some board or
> device that [at least at
> some time in the past] existed and the platform could be built and run
> with no software "tweaks".

But are development/eval boards deployed? I would have thought that
largely microcontrollers would go on some custom PCB

-- 
Øyvind Harboe
http://www.zylin.com

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are the HALs in the eCos repository meant for deployment?

[Gary Thomas]

Øyvind Harboe wrote:
> On 8/14/06, Gary Thomas <gary@mlbassoc.com> wrote:
>> Øyvind Harboe wrote:
>> > Are the HALs in the eCos repository meant for deployment?
>>
>> Absolutely!  Every one that's in the repository is for some board or
>> device that [at least at
>> some time in the past] existed and the platform could be built and run
>> with no software "tweaks".
> 
> But are development/eval boards deployed? I would have thought that
> largely microcontrollers would go on some custom PCB
> 

I disagree - there are many "development/eval" boards that make it
into the real world (I personally know of many*many thousands...)

Yes, there may be some development boards that are modified, however
slightly, before deployment, but I firmly believe that the basic
structure of eCos should be sound enough that these changes should
be easily added/adjusted in the various HAL and other packages.

-- 
------------------------------------------------------------
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

Re: [ECOS] Are the HALs in the eCos repository meant for deployment?

[Andrew Lunn]

On Mon, Aug 14, 2006 at 01:54:45PM +0200, ?yvind Harboe wrote:
> On 8/14/06, Gary Thomas <gary@mlbassoc.com> wrote:
> >?yvind Harboe wrote:
> >> Are the HALs in the eCos repository meant for deployment?
> >
> >Absolutely!  Every one that's in the repository is for some board or
> >device that [at least at
> >some time in the past] existed and the platform could be built and run
> >with no software "tweaks".
> 
> But are development/eval boards deployed? I would have thought that
> largely microcontrollers would go on some custom PCB

In my experiance, the hardware i've used for products is so nearly
identical to the development board that i've been able to use the HAL
unchanged. This is something i want, since during the two months it
takes for the hardware people to design, layout, route it, get the PCB
manufactured, get the components put on, power it up and put the fire
out, turn the DRAM the right way around and fix the bugs in the reset
logic, re-spin the board, make it run and finally put it on my desk, i
want to be using the development board to do as much software
development as possible.

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are the HALs in the eCos repository meant for deployment?

[Øyvind Harboe]

On 8/14/06, Andrew Lunn <andrew@lunn.ch> wrote:
> On Mon, Aug 14, 2006 at 01:54:45PM +0200, ?yvind Harboe wrote:
> > On 8/14/06, Gary Thomas <gary@mlbassoc.com> wrote:
> > >?yvind Harboe wrote:
> > >> Are the HALs in the eCos repository meant for deployment?
> > >
> > >Absolutely!  Every one that's in the repository is for some board or
> > >device that [at least at
> > >some time in the past] existed and the platform could be built and run
> > >with no software "tweaks".
> >
> > But are development/eval boards deployed? I would have thought that
> > largely microcontrollers would go on some custom PCB
>
> In my experiance, the hardware i've used for products is so nearly
> identical to the development board that i've been able to use the HAL
> unchanged. This is something i want, since during the two months it
> takes for the hardware people to design, layout, route it, get the PCB
> manufactured, get the components put on, power it up and put the fire
> out, turn the DRAM the right way around and fix the bugs in the reset
> logic, re-spin the board, make it run and finally put it on my desk, i
> want to be using the development board to do as much software
> development as possible.

Even for a board like the EB40a where the final product strictly
followed the schemtics of EB40a as closely as possible, I found that I
made the following changes:

- modifications to the EBI interface. There is no provision in the
EB40a HAL for configuring the EBI.
- The reset on the EB40a HAL does not reset external circuits(or even the flash)
- changes to memory layout

I.e. the eval board HAL could not be used unchanged. Copying the EB40a
HAL to a seperate repository and renaming was the way to go here.


-- 
Øyvind Harboe
http://www.zylin.com

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are the HALs in the eCos repository meant for deployment?

[Andrew Lunn]

> - modifications to the EBI interface. There is no provision in the
> EB40a HAL for configuring the EBI.

This could be done in "application" space. If necassary, use a static
constructor with the appropriate priority. Otherwise do it from
cyg_user_start().

> - The reset on the EB40a HAL does not reset external circuits(or even the 
> flash)

Reseting flash has to be done by hardware, not software. If the CPU
does it via software, you are going to get into trouble, when you get
a reboot part way through a flash operation, leaving the flash in
write mode, resulting in yet another crash. 

Other bits of hardware should be reset by there respective device
drivers.

> - changes to memory layout

Making the RAM/ROM bigger can sometimes be a problem, granted.

       Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are the HALs in the eCos repository meant for deployment?

[Gary Thomas]

Øyvind Harboe wrote:
> On 8/14/06, Andrew Lunn <andrew@lunn.ch> wrote:
>> On Mon, Aug 14, 2006 at 01:54:45PM +0200, ?yvind Harboe wrote:
>> > On 8/14/06, Gary Thomas <gary@mlbassoc.com> wrote:
>> > >?yvind Harboe wrote:
>> > >> Are the HALs in the eCos repository meant for deployment?
>> > >
>> > >Absolutely!  Every one that's in the repository is for some board or
>> > >device that [at least at
>> > >some time in the past] existed and the platform could be built and run
>> > >with no software "tweaks".
>> >
>> > But are development/eval boards deployed? I would have thought that
>> > largely microcontrollers would go on some custom PCB
>>
>> In my experiance, the hardware i've used for products is so nearly
>> identical to the development board that i've been able to use the HAL
>> unchanged. This is something i want, since during the two months it
>> takes for the hardware people to design, layout, route it, get the PCB
>> manufactured, get the components put on, power it up and put the fire
>> out, turn the DRAM the right way around and fix the bugs in the reset
>> logic, re-spin the board, make it run and finally put it on my desk, i
>> want to be using the development board to do as much software
>> development as possible.
> 
> Even for a board like the EB40a where the final product strictly
> followed the schemtics of EB40a as closely as possible, I found that I
> made the following changes:
> 
> - modifications to the EBI interface. There is no provision in the
> EB40a HAL for configuring the EBI.
> - The reset on the EB40a HAL does not reset external circuits(or even 
> the flash)
> - changes to memory layout
> 
> I.e. the eval board HAL could not be used unchanged. Copying the EB40a
> HAL to a seperate repository and renaming was the way to go here.

It seems to me that such changes could [indeed, should] be made in a flexible
manner such that the original EB40a could still be configured as well as your
updated board.  These changes could then be folded back into the main CVS.

If the changes you need are truly platform (or even confidential) in nature,
then a platform include file could contain the specifics in such a way that
the generic [public] version is unchanged and you simply provide the private
changes/specifics in that file.

-- 
------------------------------------------------------------
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

Re: [ECOS] Are the HALs in the eCos repository meant for deployment?

[Øyvind Harboe]

On 8/14/06, Gary Thomas <gary@mlbassoc.com> wrote:
> Øyvind Harboe wrote:
> > On 8/14/06, Andrew Lunn <andrew@lunn.ch> wrote:
> >> On Mon, Aug 14, 2006 at 01:54:45PM +0200, ?yvind Harboe wrote:
> >> > On 8/14/06, Gary Thomas <gary@mlbassoc.com> wrote:
> >> > >?yvind Harboe wrote:
> >> > >> Are the HALs in the eCos repository meant for deployment?
> >> > >
> >> > >Absolutely!  Every one that's in the repository is for some board or
> >> > >device that [at least at
> >> > >some time in the past] existed and the platform could be built and run
> >> > >with no software "tweaks".
> >> >
> >> > But are development/eval boards deployed? I would have thought that
> >> > largely microcontrollers would go on some custom PCB
> >>
> >> In my experiance, the hardware i've used for products is so nearly
> >> identical to the development board that i've been able to use the HAL
> >> unchanged. This is something i want, since during the two months it
> >> takes for the hardware people to design, layout, route it, get the PCB
> >> manufactured, get the components put on, power it up and put the fire
> >> out, turn the DRAM the right way around and fix the bugs in the reset
> >> logic, re-spin the board, make it run and finally put it on my desk, i
> >> want to be using the development board to do as much software
> >> development as possible.
> >
> > Even for a board like the EB40a where the final product strictly
> > followed the schemtics of EB40a as closely as possible, I found that I
> > made the following changes:
> >
> > - modifications to the EBI interface. There is no provision in the
> > EB40a HAL for configuring the EBI.
> > - The reset on the EB40a HAL does not reset external circuits(or even
> > the flash)
> > - changes to memory layout
> >
> > I.e. the eval board HAL could not be used unchanged. Copying the EB40a
> > HAL to a seperate repository and renaming was the way to go here.
>
> It seems to me that such changes could [indeed, should] be made in a flexible
> manner such that the original EB40a could still be configured as well as your
> updated board.  These changes could then be folded back into the main CVS.
>
> If the changes you need are truly platform (or even confidential) in nature,
> then a platform include file could contain the specifics in such a way that
> the generic [public] version is unchanged and you simply provide the private
> changes/specifics in that file.

I guess I'm not a believer in that the HALs need to be deployed unmodified.

I don't see a problem with duplicating the HAL into another repository
and then tweaking it w.r.t. e.g. memory layout, reset procedures, etc.

I never though to check if ecosconfig supports moving/copying a module
from one repository to another(i.e. moving the files and updating the
ecos.db), but it would be neat. :-)

Let me see if I can dig up a couple of more EB40a modifications and
post them. Ca. 20-30% of my eCos changes get committed eventually,
which is a pretty good yield :-)

-- 
Øyvind Harboe
http://www.zylin.com

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are the HALs in the eCos repository meant for deployment?

[Bart Veer]

>>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind Harboe?= <ISO-8859-1> writes:

    Oyvind> Are the HALs in the eCos repository meant for deployment?
    Oyvind> I would expect the average PCB to be somewhat/quite
    Oyvind> similar to an exisiting development board. I would *not*
    Oyvind> expect that the average product(hardware/software) would
    Oyvind> use some HAL completely unmodified.

There is a range of scenarios.

Some evaluation boards may provide all the peripherals needed for the
target application, quite possibly with a few too spare. For smallish
volumes it will be a lot more cost-efficient to buy a number of the
eval boards than to design a custom board. Of course cost
effectiveness will depend in part on whether the eval board costs a
few tens of dollars or a few thousand.

If the eval board does not quite have all the I/O facilities needed,
it may be easy to add some via an expansion connector. If the board
exposes the I2C SDA and SCL lines then it may be quite easy to fit a
daughter board hooked up to those lines, ditto for an SPI bus. Or you
could have something like a PC-compatible board with various PCI
plug-in cards. Often it will be possible to handle the extra I/O
facilities entirely in application space with no need for any HAL
modifications, e.g. extra I2C device objects can be instantiated
within application code.

Sometimes the eval board will not be appropriate, e.g. its footprint
may be too large for the intended application. If so a new board may
be designed but based on the schematics of the eval board. This saves
a lot of h/w design effort and reduces the risk of running into
previously undiscovered h/w bugs. The existing platform HAL may work
unchanged on the new h/w, with any extra I/O facilities again handled
within application space, Or it may be necessary to make minor tweaks,
e.g. change the linker script support to reflect a larger amount of
RAM and change the ROM startup code with different SDRAM controller
register values. You may also want a different ecos.db entry, a new
target which specifies the same platform HAL but e.g. removes the
ethernet device driver because that device is no longer accessible.

Or it may be desirable to design a completely new board. This is
particularly likely for high-volume cost-sensitive applications. Again
it may still be possible to reuse an existing eval board platform HAL,
but it is now more likely that a new platform HAL will be appropriate.
It depends in large part on how well the platform HAL and higher level
HALs were written, i.e. how well they can cope with minor board
variations, and that in turn depends in part on the h/w design.

There is an awful lot of variety in the embedded space - hence the
need for a configurable operating system.

    Oyvind> Rather than tweaking an existing HAL (often a couple of
    Oyvind> changes are sufficient), I would recommend to copy the
    Oyvind> existing HAL to a seperate repository(including the
    Oyvind> section in the ecos.db) and then placing that HAL before
    Oyvind> the snapshot of the eCos CVS HEAD. Renaming the HAL,
    Oyvind> although I would encourage it, isn't stricly required and
    Oyvind> probably not a lot of effort to rename at some later
    Oyvind> stage.

If that is how you want to work, that is fine - subject to graphical
configtool limitations. If other people prefer to copy a platform HAL
within the existing hierarchy, that is fine too. If yet other people
prefer to munge an existing platform HAL, either by adding configury
or by simply breaking the HAL for the original board, that is fine too
- although obviously any changes that break things are unlikely to
make it back into the master repository. I have no particular desire
to shoehorn people into exactly one way of doing things, except when
absolutely necessary to maintain a coherent and maintainable
architecture for the configuration system.

(Note this does not justify any major reorganization of the master
eCos repository that could make life more complicated for novice users
etc.)

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss