From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25064 invoked by alias); 26 Jun 2002 09:42:21 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 25040 invoked from network); 26 Jun 2002 09:42:17 -0000 Received: from unknown (HELO proxy.baslerweb.com) (145.253.187.130) by sources.redhat.com with SMTP; 26 Jun 2002 09:42:17 -0000 Received: from comm1.baslerweb.com ([172.16.13.2]) by proxy.baslerweb.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Wed, 26 Jun 2002 11:41:29 +0200 Received: by COMM1 with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jun 2002 11:42:31 +0200 Message-ID: <850597605E79D21182830008C7A4B9CF1EB423D9@COMM1> From: "Koeller, T." To: 'Tim Drury' Cc: "ecos-discuss (E-Mail)" Date: Wed, 26 Jun 2002 03:38:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ECOS] malloc vs. new X-SW-Source: 2002-06/txt/msg00464.txt.bz2 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: > > > > > > > > > > > > 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