public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Tim Drury <tdrury@siliconmotorsports.com>
To: "ecos-discuss (E-Mail)" <ecos-discuss@sources.redhat.com>
Subject: Re: [ECOS] malloc vs. new
Date: Tue, 25 Jun 2002 07:00:00 -0000	[thread overview]
Message-ID: <200206250842.28947.tdrury@siliconmotorsports.com> (raw)
In-Reply-To: <850597605E79D21182830008C7A4B9CF1EB423D0@COMM1>


When I joined the ecos list, Thomas' patch submission was the first email I
got.  I've kept it!  I don't know much about ecos, but I've been trying to
modify the eb40 platform hal to fit the eb40a.  The split that Thomas did
seems to be the right direction.  I'm going to apply the patches today and
see if I can figure out which files need to be modified to make an eb40a
specific platform hal.

-tim

On Tuesday 25 June 2002 05:33 am, Koeller, T. wrote:
> Scott,
>
> it may be of interest to you that I did quite a lot of work on the
> AT91/EB40. I separated the existing HAL into an AT91-specific variant
> HAL and a EB40-specific platform HAL. This is the standard ecos way of
> dealing with platforms that are variations of a common underlying
> archtecture. You can then create a platform HAL with minimum effort,
> and there you can set your platform's parameters to anything you like
> without changing the AT91 HAL. This also means that you do not have to
> release your source code under the GPL, as would be the case if you just
> modify an existing component.
>
> I submitted my changes to the ecos-patches mailing list, but the haven't
> been approved yet. There's also a newer, improved version that I did not
> submit yet, because such submissions are not currently processed. However,
> if anyone is interested, I'd like to share my code with him/her.
>
> tk
>
> > -----Original Message-----
> > From: Scott Dattalo [mailto:scott@dattalo.com]
> > Sent: Monday, June 24, 2002 9:23 PM
> > Cc: ecos-discuss@sources.redhat.com
> > Subject: RE: [ECOS] malloc vs. new
> >
> >
> > On Mon, 24 Jun 2002, Scott Dattalo wrote:
> >
> > <snip>
> >
> > I fixed my memory problem.
> >
> > It turns out that my application is big. It's too big to fit into the
> > memory footprint provided bythe At91EB40 evaluation board. I
> > know in the
> > future that I will be putting the application in different
> > hardware, but
> > I'm using the eCos configuration that's available for the
> > EB40. To make a
> > long story short, the memory foot print is defined for the AT91EB40 in
> > here:
> >
> > ecos/packages/hal/arm/at91/current/include/pkgconf/
> >
> > The RAM size is 0x80000. To work around this, I made a backup
> > of pkgconf/
> > and changed all references of 0x80000 to 0x200000 and that works!
> >
> > I know that one shouldn't go around trampling on the ecos
> > sources in such
> > a way. But, what is the preferred way to change the memory
> > foot print?
> > Should I create a new cdl for my hardware based on (say) the
> > arm/at91/ and
> > edit those hardware-specific changes? It doesn't appear that
> > fundamental
> > configuration such as this can be changed in ecos.ecc. (You
> > *can* change
> > the size of the memalloc heap, but you can't make it bigger than the
> > memory footprint that's defined in pkgconf/, AFAICT).
> >
> > Scott
> >
> >
> > --
> > Before posting, please read the FAQ:
> > http://sources.redhat.com/fom/ecos
> > and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>
> -----------------------------------------------
> Thomas Koeller, Software Development
>
> Basler Vision Technologies
> An der Strusbek 60-62
> 22926 Ahrensburg
> Germany
>
> Tel +49 (4102) 463-390
> Fax +49 (4102) 463-46390
>
> mailto:Thomas.Koeller@baslerweb.com
> http://www.baslerweb.com


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

  reply	other threads:[~2002-06-25 12:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-25  4:51 Koeller, T.
2002-06-25  7:00 ` Tim Drury [this message]
2002-06-25 11:20 ` Daniel Leu
2002-06-25 23:38 ` Tim Drury
  -- strict thread matches above, loose matches on Subject: below --
2002-06-27  1:48 Koeller, T.
2002-06-26  9:12 Koeller, T.
2002-06-26  3:38 Koeller, T.
2002-06-26  8:57 ` Tim Drury
2002-06-23 14:40 Dan Conti
2002-06-23 14:56 ` Scott Dattalo
2002-06-24  4:27   ` Pierre Merlin
2002-06-24 13:25 ` Scott Dattalo
2002-06-24 13:27   ` Scott Dattalo
2002-06-24 15:07     ` Gary Thomas
2002-06-24 19:05       ` Scott Dattalo
2002-06-25  2:32         ` Tim Drury
2002-06-25  6:45     ` Kjell Svensson
     [not found]       ` <200206250843.51339.tdrury@siliconmotorsports.com>
2002-06-25 11:12         ` Kjell Svensson
2002-06-21 20:02 Scott Dattalo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200206250842.28947.tdrury@siliconmotorsports.com \
    --to=tdrury@siliconmotorsports.com \
    --cc=ecos-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).