RE: [ECOS] malloc vs. new

RE: [ECOS] malloc vs. new

[Koeller, T.]

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

Re: [ECOS] malloc vs. new

[Tim Drury]

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

RE: [ECOS] malloc vs. new

[Daniel Leu]

Hello Thomas,

I saw your posting regarding the separation of the AT91/HAL 
and I think this is the right way to proceed. Could you 
please email me your latest copy? Thanks.

We have a development board running eCos 1.3 on it. I 
kind of waited with the porting to eCos 2.0 until your
patch is incorporated. But since this won't happen 
soon, I guess I start with the migration anyway...
Specially it should be much easier based on your 
modifs :)

BTW, if anyone is interest on a AT91R40807 with 2Mbyte
SRAM, ample of Flash, a big FPGA etc.... Have a look
at www.inicore.com/products/sdb.htm

Thanks,
Daniel



At 11:33 AM 6/25/2002 +0200, 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


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

Re: [ECOS] malloc vs. new

[Tim Drury]

Thomas,

I copied your eb40 directory and created an eb40a directory.  I changed
everything over to match the eb40a eval board, but I have a couple questions:

1) in var/current/cdl/hal_arm_at91.cdl the CPU clock speed is defined.  But
the eb40a runs at 66MHz, not the 32.768MHz of the eb40.  Should I pull
that constant out and put it in eb40*/var/current/cdl/hal_arm_at91_eb40*.cdl?

2) eb40/current/src/eb40_misc.c is confusing.  The eb40 schematic shows that
pulling a PIO pin low turns the LED on, but the code shows setting the SODR
bit (setting PIO pin high) turning the LED on.  And what in the world does
_at91_led() really do? It looks like it just strobes the data LED on briefly.
What is that used for?

3) also about eb40_misc.c: both function take an 'int led' argument which is
supposed to be a correctly bit-mapped value to the LED/PIO pins.  Shouldn't
we have some #defines for the LEDs so a user can call, for example:
set_leds(LED2 | LED4);
Keep in mind the eb40a has 8 LEDs and none are labelled CLOCK and DATA
like the eb40.  Where would be the appropriate place to put these #defines?

4) var/current/include/hal_platform_setup.h.  This file will also change for
eb40a.  Should it be moved to eb40a/current/include?  Mostly just the
memory mapping data.  Oddly enough, the wait states for the Flash are
the same for the eb40a and the eb40.  The eb40a is running at 66MHz,
but the flash chip (AT49BV1614) is also faster and the numbers work 
out the same:
tOE = 90ns -> 90ns/15.2ns = 5.92 ~= 6 WS before
tDF = 25ns -> 25ns/15.2ns = 1.64 ~= 2 WS after

The ram wait states (1WS before and 1 WS after) has not been tested.
I originally calculated this to be correct for the eb40, but Atmel said to
use 3WS before and 4WS after which I think is overkill.  I'll test this when
I get this port to compile.

Thanks,

-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

RE: [ECOS] malloc vs. new

[Koeller, T.]

I assume you mean the eb40 platform hal ;-)
How's about a patch?
tk

> -----Original Message-----
> From: Tim Drury [mailto:tdrury@siliconmotorsports.com]
> Sent: Thursday, June 27, 2002 4:31 AM
> To: Koeller, T.
> Subject: Re: [ECOS] malloc vs. new
> 
> hal_diag_led(int mask) was missing from the at91 platform
> hal_diag.c file.  I added it in.
> 
> -tim
>
----------------------------------------------- 
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

RE: [ECOS] malloc vs. new

[Koeller, T.]

I think this is what hal_diag_led() is for. It takes
an int argument specifiying which LEDs should be on.
Have alook at it!

tk

> -----Original Message-----
> From: Tim Drury [mailto:tdrury@siliconmotorsports.com]
> Sent: Wednesday, June 26, 2002 5:17 PM
> To: ecos-discuss (E-Mail)
> Subject: Re: [ECOS] malloc vs. new
> 
> 
> ...
> I can test the eb40a stuff.  I also added a led_on() and
> led_off() for turning individual LEDs on and off.
> ...

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

RE: [ECOS] malloc vs. new

[Koeller, T.]

Hi Tim,

first of all, before doing anything else you should get
the latest version of the patch that I just uploaded to
ecos-patches@sources.redhat.com. Now to your questions:

1) Yes, this is a platform-dependent parameter and
   therefore should go into the platform cdl file.

2) The short answer is that I just took the LED code as
   it were without modifying it. In the latest version I
   implemented the function hal_diag_led() which the
   original code defined in hal_diag.h, but did not
   actually implement. It tries to get setting those
   LEDs right by using a lookup table for the PIO bits,
   but I haven't tested it so far - maybe you can?

3) Yes, I agree. These definitions should go into
   plf_io.h.

4) Generally, everything platform-specific should go
   into that platform's directory and thus become a
   part of the platform hal package.

tk

> -----Original Message-----
> From: Tim Drury [mailto:tdrury@siliconmotorsports.com]
> Sent: Wednesday, June 26, 2002 6:19 AM
> To: Koeller, T.
> Cc: ecos-discuss (E-Mail)
> Subject: Re: [ECOS] malloc vs. new
> 
> 
> 
> Thomas,
> 
> I copied your eb40 directory and created an eb40a directory.  
> I changed
> everything over to match the eb40a eval board, but I have a 
> couple questions:
> 
> 1) in var/current/cdl/hal_arm_at91.cdl the CPU clock speed is 
> defined.  But
> the eb40a runs at 66MHz, not the 32.768MHz of the eb40.  Should I pull
> that constant out and put it in 
> eb40*/var/current/cdl/hal_arm_at91_eb40*.cdl?
> 
> 2) eb40/current/src/eb40_misc.c is confusing.  The eb40 
> schematic shows that
> pulling a PIO pin low turns the LED on, but the code shows 
> setting the SODR
> bit (setting PIO pin high) turning the LED on.  And what in 
> the world does
> _at91_led() really do? It looks like it just strobes the data 
> LED on briefly.
> What is that used for?
> 
> 3) also about eb40_misc.c: both function take an 'int led' 
> argument which is
> supposed to be a correctly bit-mapped value to the LED/PIO 
> pins.  Shouldn't
> we have some #defines for the LEDs so a user can call, for example:
> set_leds(LED2 | LED4);
> Keep in mind the eb40a has 8 LEDs and none are labelled CLOCK and DATA
> like the eb40.  Where would be the appropriate place to put 
> these #defines?
> 
> 4) var/current/include/hal_platform_setup.h.  This file will 
> also change for
> eb40a.  Should it be moved to eb40a/current/include?  Mostly just the
> memory mapping data.  Oddly enough, the wait states for the Flash are
> the same for the eb40a and the eb40.  The eb40a is running at 66MHz,
> but the flash chip (AT49BV1614) is also faster and the numbers work 
> out the same:
> tOE = 90ns -> 90ns/15.2ns = 5.92 ~= 6 WS before
> tDF = 25ns -> 25ns/15.2ns = 1.64 ~= 2 WS after
> 
> The ram wait states (1WS before and 1 WS after) has not been tested.
> I originally calculated this to be correct for the eb40, but 
> Atmel said to
> use 3WS before and 4WS after which I think is overkill.  I'll 
> test this when
> I get this port to compile.
> 
> Thanks,
> 
> -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
----------------------------------------------- 
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

Re: [ECOS] malloc vs. new

[Tim Drury]

On Wednesday 26 June 2002 05:42 am, Koeller, T. wrote:
> Hi Tim,
>
> first of all, before doing anything else you should get
> the latest version of the patch that I just uploaded to
> ecos-patches@sources.redhat.com. Now to your questions:

got it.

> 1) Yes, this is a platform-dependent parameter and
>    therefore should go into the platform cdl file.

I took it out of var/current/cdl and put in into both
eb40/current/cdl and eb40a/current/cdl

> 2) The short answer is that I just took the LED code as
>    it were without modifying it. In the latest version I
>    implemented the function hal_diag_led() which the
>    original code defined in hal_diag.h, but did not
>    actually implement. It tries to get setting those
>    LEDs right by using a lookup table for the PIO bits,
>    but I haven't tested it so far - maybe you can?

I can test the eb40a stuff.  I also added a led_on() and
led_off() for turning individual LEDs on and off.

> 3) Yes, I agree. These definitions should go into
>    plf_io.h.

I put them in eb40a/current/include/plf_io.h

-tim


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

RE: [ECOS] malloc vs. new

[Dan Conti]

new shouldn't be broken, since it just calls malloc. does malloc work
when making allocations of the exact same size?

two things to try as workarounds:

1) write your own operator new/new[]/delete/delete[]. tossing the
following into some file should work:

void* operator new(size_t size) {
	return malloc(size_t);
}
void operator delete(void* ptr) {
	if( ptr )
		free(ptr);
}

make versions for new[] and delete[] also, which are the same function
with different names.

2) use placement new, which is what you were getting at below. be wary
of alignment considerations for the buffer you use. also at clean up you
have to manually call the destructor IIRC. C++ is not my forte.

#include <new.h>

char buffer[1024] __attribute__((align(4));

CObject* pObj = new(buffer) CObject();

...
pObj->~CObject();

Good luck.

-----Original Message-----
From: Scott Dattalo [mailto:scott@dattalo.com]
Sent: Friday, June 21, 2002 7:18 PM
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] malloc vs. new



In a project I'm porting to eCos there is some C++ code. Consequently, 
there are several new() calls for creating new objects. Unfortunately, 
calls to new() hang. Specifically, the kernel is unable to allocate
memory 
and throws an exception. This switches control to the exception thread
and 
control is never released...

Calls to malloc, OTOH, work just fine.

I've sifted through the documentation and the best I could come up with
is 
this snippet:

#define MEMORY_BUFFER  0x1000
char StaticMemoryBuffer[MEMORY_BUFFER];

...


  cyg_handle_t mempool;
  cyg_mempool_var mempool_obj;
  cyg_mempool_var_create(StaticMemoryBuffer, MEMORY_BUFFER, &mempool, 
&mempool_obj);

This still fails. How does one provide a memory allocation buffer for 
new()?

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


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

RE: [ECOS] malloc vs. new

[Scott Dattalo]

On Sat, 22 Jun 2002, Dan Conti wrote:

> new shouldn't be broken, since it just calls malloc. does malloc work
> when making allocations of the exact same size?

malloc works fine but new fails. I did a real simple case where I malloc'd 
75 bytes and new'd a 75 byte char array.

> 
> two things to try as workarounds:
> 
> 1) write your own operator new/new[]/delete/delete[]. tossing the
> following into some file should work:

I thought about this, but when you overload new and delete the constructor 
is no longer called (actually, that's an assumption on my part). So I'll 
have to add special code to initialize the objects as they're new'd.

> 2) use placement new, which is what you were getting at below. be wary
> of alignment considerations for the buffer you use. also at clean up you
> have to manually call the destructor IIRC. C++ is not my forte.
> 
> #include <new.h>
> 
> char buffer[1024] __attribute__((align(4));
> 
> CObject* pObj = new(buffer) CObject();
> 
> ...
> pObj->~CObject();
> 
> Good luck.

Thanks for the help. Little tid-bits about alignment and such are good to 
know.

I'm going to dig a little deeper with the debugger and determine exactly 
the mode of failure. new'ing is such a fundamental thing that I'd be 
extremely surprised if it didn't work in an eCos world. While I could work 
around new (with malloc for example), I don't wish to artificially 
constrain other developers that will eventually be working on the code 
base that I'm creating. OTOH, this *is* an embedded application and most 
of the desktop assumptions (like infinite memory) are invalid!

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

Re: [ECOS] malloc vs. new

[Pierre Merlin]

Hi Scott,

On Sunday 23 June 2002 03:03, Scott Dattalo wrote:
> On Sat, 22 Jun 2002, Dan Conti wrote:
> > 1) write your own operator new/new[]/delete/delete[]. tossing the
> > following into some file should work:
>
> I thought about this, but when you overload new and delete the constructor
> is no longer called (actually, that's an assumption on my part). So I'll
> have to add special code to initialize the objects as they're new'd.

I think your assumption is wrong. IIRC, when you call _ new _, it always 
works as follows :
1) allocates memory space, using operator new  
2) initializes the object(s) being created, using the constructor

Pay attention to this distinction between the NOT overloadable new and the 
operator new, which you can redefine at your convenience.

Regards,
Pierre

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

RE: [ECOS] malloc vs. new

[Scott Dattalo]

On Sat, 22 Jun 2002, Dan Conti wrote:

> new shouldn't be broken, since it just calls malloc. does malloc work
> when making allocations of the exact same size?

Dan, 

I've looked into this more closely, and you're right new() just calls 
malloc(). So the next question is, how can malloc work and not new? Well, 
it turns out that malloc isn't working either. The difference between new 
and malloc is that new will through an exception whenever it's unable to 
allocate any memory. I misinterpreted the exception as a failure of new, 
when in fact the fundamental cause is a failure in malloc! In both cases 
of malloc and new, the kernel is unable to allocate any memory.

malloc works just fine in a stripped down version of a hello_world.c type 
program. So the failure I'm experiencing is somehow due to my specific 
port. Unfortunately, it's not clear to me exactly what can be causing this 
failure. As a simple test, I placed the malloc call right at the beginning 
of my program  (the big one, not the hello_world.c one) and tried 
allocating a tiny 50 byte array:

  char *test1;

  test1 = (char *) malloc(50);
/* returns null */


In my particlar application, there are several large arrays that are 100's 
of Kbytes, but these are all statically declared. Just to be sure that I 
wasn't running out of memory, I went into my ecos.ecc file and increased 
the pool size to 4 MBytes:

cdl_option CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE {
    # Flavor: data
    user_value 4194304
    # value_source user
    # Default value: 16384
    # Legal values: 32 to 0x7fffffff
};


After making this change, I run ecosconfig tree followed by make. I then 
switch over to the directory of my application and run make there (my 
application Makefile properly refers to the ecos directory in which the 
ecos software was built).

Now for debugging the "crash". Using Insight I target the simulator, 
download and run the code. I single step through the call to malloc and 
can pin-point exactly the failure:

malloc 

 POOL.try_alloc( size );
  mypool.try_alloc();
   Cyg_Mempool_dlmalloc_Implementation::try_alloc()

within try_alloc(), there's this sequence of code:

  remainder_size = long_sub_size_t(chunksize(top), nb);
  if (chunksize(top) < nb || remainder_size < (long)MINSIZE)
  {

before the call to long_sub_size_t:

inspect /x remainder_size
$4 = 0x21333d4

but after:

inspect /x remainder_size
$5 = 0xfff4c7c0

That doesn't look right. try_alloc doesn't think so either and returns 
NULL; . 

---
I also verified that only one constructor (that wants memory) is getting 
called on startup; Cyg::StdioStream. It tries to allocate 256 bytes, but 
gets 0.


Does anyone have an idea why I'm experiencing this problem?


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

RE: [ECOS] malloc vs. new

[Scott Dattalo]

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

RE: [ECOS] malloc vs. new

[Gary Thomas]

On Mon, 2002-06-24 at 13:23, Scott Dattalo wrote:
> 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).

Is your platform an EB40 or EB40A?  

The "proper" way is to define a new platform.  This can be much the same
as an extant one, in fact, all that might be different is the mlt_* 
files.  Look at the (ARM) Cirrus Logic edbxxx platforms.  One platform 
HAL is used for 4 different boards (platforms).


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

RE: [ECOS] malloc vs. new

[Scott Dattalo]

On 24 Jun 2002, Gary Thomas wrote:

> 
> Is your platform an EB40 or EB40A?  

I have both, but for the moment I was targeting the EB40 since eCos works
"out of the box" for it. Ultimately, I'll target my own platform which 
will be different than both of these, but more similar to the EB40A (e.g. 
I plan on using the 40008).

> 
> The "proper" way is to define a new platform.  This can be much the same
> as an extant one, in fact, all that might be different is the mlt_* 
> files.  Look at the (ARM) Cirrus Logic edbxxx platforms.  One platform 
> HAL is used for 4 different boards (platforms).

Great! I look into a EB40a mlt_* version, (assuming Tim hasn't done one 
already).

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

Re: [ECOS] malloc vs. new

[Tim Drury]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]


Actually....  I have.  But I'm not sure they are correct. I cannot figure out 
how to target a ROM-based redboot target.  If I do an ecosconfig and 
import redboot_ROM.ecm instead of the RAM version, the resulting elf 
file appears to have addresses starting at 0x02020000 (RAM) instead of
0x01000000 which is the Flash.  Is there something else I'm supposed to 
do or will the addresses get automagically adjusted upon upload?

-tim


On Monday 24 June 2002 05:55 pm, Scott Dattalo wrote:
> On 24 Jun 2002, Gary Thomas wrote:
> > Is your platform an EB40 or EB40A?
>
> I have both, but for the moment I was targeting the EB40 since eCos works
> "out of the box" for it. Ultimately, I'll target my own platform which
> will be different than both of these, but more similar to the EB40A (e.g.
> I plan on using the 40008).
>
> > The "proper" way is to define a new platform.  This can be much the same
> > as an extant one, in fact, all that might be different is the mlt_*
> > files.  Look at the (ARM) Cirrus Logic edbxxx platforms.  One platform
> > HAL is used for 4 different boards (platforms).
>
> Great! I look into a EB40a mlt_* version, (assuming Tim hasn't done one
> already).
>
> Thanks,
> Scott

[-- Attachment #2: mlt_arm_at91_eb40_rom.h --]
[-- Type: text/x-chdr, Size: 978 bytes --]

// eCos memory layout - Wed Apr 11 13:49:55 2001

// This is a generated file - do not edit

#ifndef __ASSEMBLER__
#include <cyg/infra/cyg_type.h>
#include <stddef.h>

#endif
#define CYGMEM_REGION_ram (0x02000000)
//#define CYGMEM_REGION_ram_SIZE (0x80000)
#define CYGMEM_REGION_ram_SIZE (0x100000)
#define CYGMEM_REGION_ram_ATTR (CYGMEM_REGION_ATTR_R | CYGMEM_REGION_ATTR_W)
#define CYGMEM_REGION_rom (0x01000000)
//#define CYGMEM_REGION_rom_SIZE (0x20000)
#define CYGMEM_REGION_rom_SIZE (0x1200000)
#define CYGMEM_REGION_rom_ATTR (CYGMEM_REGION_ATTR_R)
#ifndef __ASSEMBLER__
extern char CYG_LABEL_NAME (__reserved_bootmon) [];
#endif
#define CYGMEM_SECTION_reserved_bootmon (CYG_LABEL_NAME (__reserved_bootmon))
#define CYGMEM_SECTION_reserved_bootmon_SIZE (0x10000)
#ifndef __ASSEMBLER__
extern char CYG_LABEL_NAME (__heap1) [];
#endif
#define CYGMEM_SECTION_heap1 (CYG_LABEL_NAME (__heap1))
#define CYGMEM_SECTION_heap1_SIZE (0x02080000 - (size_t) CYG_LABEL_NAME (__heap1))

[-- Attachment #3: mlt_arm_at91_eb40_rom.ldi --]
[-- Type: text/x-c++src, Size: 1157 bytes --]

// eCos memory layout - Wed Apr 11 13:49:55 2001

// This is a generated file - do not edit

#include <cyg/infra/cyg_type.inc>

MEMORY
{
//    sram : ORIGIN = 0x00000000, LENGTH = 0x2000
    sram : ORIGIN = 0x00000000, LENGTH = 0x40000
//    ram : ORIGIN = 0x02000000, LENGTH = 0x80000
    ram : ORIGIN = 0x02000000, LENGTH = 0x100000
//    rom : ORIGIN = 0x01000000, LENGTH = 0x20000
    rom : ORIGIN = 0x01000000, LENGTH = 0x200000
}

SECTIONS
{
    SECTIONS_BEGIN
    CYG_LABEL_DEFN(__reserved_bootmon) = 0x01000000; . = CYG_LABEL_DEFN(__reserved_bootmon) + 0x10000;
    SECTION_rom_vectors (rom, ALIGN (0x8), LMA_EQ_VMA)
    SECTION_text (rom, ALIGN (0x1), LMA_EQ_VMA)
    SECTION_fini (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata1 (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixup (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_gcc_except_table (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixed_vectors (sram, 0x20, LMA_EQ_VMA)
    SECTION_data (ram, 0x02000000, FOLLOWING (.gcc_except_table))
    SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
    SECTIONS_END
}

[-- Attachment #4: mlt_arm_at91_eb40_romram.h --]
[-- Type: text/x-chdr, Size: 862 bytes --]

// eCos memory layout - Mon Jul 23 11:49:04 2001

// This is a generated file - do not edit

#ifndef __ASSEMBLER__
#include <cyg/infra/cyg_type.h>
#include <stddef.h>

#endif
#define CYGMEM_REGION_sram (0)
//#define CYGMEM_REGION_sram_SIZE (0x1000)
#define CYGMEM_REGION_sram_SIZE (0x400000)
#define CYGMEM_REGION_sram_ATTR (CYGMEM_REGION_ATTR_R | CYGMEM_REGION_ATTR_W)
#define CYGMEM_REGION_ram (0x2000000)
//#define CYGMEM_REGION_ram_SIZE (0x80000)
#define CYGMEM_REGION_ram_SIZE (0x100000)
#define CYGMEM_REGION_ram_ATTR (CYGMEM_REGION_ATTR_R | CYGMEM_REGION_ATTR_W)
#ifndef __ASSEMBLER__
extern char CYG_LABEL_NAME (__heap1) [];
#endif
#define CYGMEM_SECTION_heap1 (CYG_LABEL_NAME (__heap1))
//#define CYGMEM_SECTION_heap1_SIZE (0x2080000 - (size_t) CYG_LABEL_NAME (__heap1))
#define CYGMEM_SECTION_heap1_SIZE (0x2100000 - (size_t) CYG_LABEL_NAME (__heap1))

[-- Attachment #5: mlt_arm_at91_eb40_romram.ldi --]
[-- Type: text/x-c++src, Size: 926 bytes --]

// eCos memory layout - Mon Jul 23 11:49:04 2001

// This is a generated file - do not edit

#include <cyg/infra/cyg_type.inc>

MEMORY
{
//    sram : ORIGIN = 0, LENGTH = 0x1000
    sram : ORIGIN = 0x00000000, LENGTH = 0x40000
//    ram : ORIGIN = 0x2000000, LENGTH = 0x80000
    ram : ORIGIN = 0x02000000, LENGTH = 0x100000
}

SECTIONS
{
    SECTIONS_BEGIN
    SECTION_fixed_vectors (sram, 0x20, LMA_EQ_VMA)
    SECTION_rom_vectors (ram, 0x2000000, LMA_EQ_VMA)
    SECTION_text (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata1 (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixup (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_gcc_except_table (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_data (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
    SECTIONS_END
}


[-- Attachment #6: Type: text/plain, Size: 146 bytes --]

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

Re: [ECOS] malloc vs. new

[Kjell Svensson]

Hi Scott,

As You have noted, the EB40 is indeed somewhat RAM-limited ;-)
Atmel does sell a variant of the EB40 with 2MB RAM, but they are 
unfortunately quite hard to come by so this seems to be a prototyping 
problem for quite many early AT91 projects.

We did an AT91-based mixed HW/SW project for the telecoms company 
Ericsson some time ago, and when the project was finished we were given 
the opportunity to buy a number of the proto boards we produced during 
the project. We are using them for internal prototyping, but have also 
sold a few boards to people doing AT91-prototyping.

Consequently, we have a number of AT9140F416 based (40400 with 2MB 
built-in flash) proto boards lying around here.
Some of them are equipped with 1MB RAM, and some with 2MB + Ethernet 
CS8900A. Both variants are also equipped with a Bluetooth module and a 
JTAG interface. The variant with 1MB RAM has USART0 connected to an 
RS232-port, while the 2MB variant has the RS232 connected to an external 
Philips UART (both internal USARTs are used for the BT module in that 
variant). Some more info, and pictures of "variant 2" can be found at: 
http://www.angelfire.com/linuc/tribe

So if You'd like to solve Your proto board RAM bottlenecks in a fast and 
simple way, drop me an email and I'll give You a "special eCos offer" 
for one or max two proto boards.

Happy AT91 hacking!
/Kjell
-- 
Kjell Svensson                 Embedded Technology Manager
Techtribe Solutions AB         Tel:  +46 (0)31 706 06 00
Flöjelbergsgatan 12            GSM:  +46 (0)70 270 76 66
SE-431 37  MÖLNDAL             Mail: kjell@techtribe.se
Sweden




Scott Dattalo wrote:
> 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

Re: [ECOS] malloc vs. new

[Kjell Svensson]

Hi Tim,

Ooops, it seems like I misspelled "linux" in the link :-)))
The correct link should read: http://www.angelfire.com/linux/tribe

We have a fairly limited number of AT91 proto boards left (approx 
20pcs). We will keep at least 4-5 for ourselves, but I'm willing to sell 
the others to people who are intending to do anything sensible with them 
(typically like eCos or uClinux work:-). This offer of course goes for 
anyone on the eCos list, but in order to make them useful for as many 
projects as possible, I wouldn't be to happy about selling someone more 
than max 2 boards each.

Cheers,
/Kjell
-- 
Kjell Svensson                 Embedded Technology Manager
Techtribe Solutions AB         Tel:  +46 (0)31 706 06 00
Flöjelbergsgatan 12            GSM:  +46 (0)70 270 76 66
SE-431 37  MÖLNDAL             Mail: kjell@techtribe.se
Sweden




Tim Drury wrote:
> Kjell,  the link you posted didn't seem to work.  Since you posted to the
> entire ecos list are you making a public offer to sell your proto boards?
> I've been dying to try some bluetooth hardware...
> 
> -tim
> 
> 
> On Tuesday 25 June 2002 07:41 am, Kjell Svensson wrote:
> 
>>Hi Scott,
>>
>>As You have noted, the EB40 is indeed somewhat RAM-limited ;-)
>>Atmel does sell a variant of the EB40 with 2MB RAM, but they are
>>unfortunately quite hard to come by so this seems to be a prototyping
>>problem for quite many early AT91 projects.
>>
>>We did an AT91-based mixed HW/SW project for the telecoms company
>>Ericsson some time ago, and when the project was finished we were given
>>the opportunity to buy a number of the proto boards we produced during
>>the project. We are using them for internal prototyping, but have also
>>sold a few boards to people doing AT91-prototyping.
>>
>>Consequently, we have a number of AT9140F416 based (40400 with 2MB
>>built-in flash) proto boards lying around here.
>>Some of them are equipped with 1MB RAM, and some with 2MB + Ethernet
>>CS8900A. Both variants are also equipped with a Bluetooth module and a
>>JTAG interface. The variant with 1MB RAM has USART0 connected to an
>>RS232-port, while the 2MB variant has the RS232 connected to an external
>>Philips UART (both internal USARTs are used for the BT module in that
>>variant). Some more info, and pictures of "variant 2" can be found at:
>>http://www.angelfire.com/linuc/tribe
>>
>>So if You'd like to solve Your proto board RAM bottlenecks in a fast and
>>simple way, drop me an email and I'll give You a "special eCos offer"
>>for one or max two proto boards.
>>
>>Happy AT91 hacking!
>>/Kjell
> 
> 
> 
> 




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

[ECOS] malloc vs. new

[Scott Dattalo]

In a project I'm porting to eCos there is some C++ code. Consequently, 
there are several new() calls for creating new objects. Unfortunately, 
calls to new() hang. Specifically, the kernel is unable to allocate memory 
and throws an exception. This switches control to the exception thread and 
control is never released...

Calls to malloc, OTOH, work just fine.

I've sifted through the documentation and the best I could come up with is 
this snippet:

#define MEMORY_BUFFER  0x1000
char StaticMemoryBuffer[MEMORY_BUFFER];

...


  cyg_handle_t mempool;
  cyg_mempool_var mempool_obj;
  cyg_mempool_var_create(StaticMemoryBuffer, MEMORY_BUFFER, &mempool, 
&mempool_obj);

This still fails. How does one provide a memory allocation buffer for 
new()?

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