Re: [ECOS] malloc vs. new

[Tim Drury <tdrury@siliconmotorsports.com>]

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