From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11368 invoked by alias); 19 May 2014 09:45:14 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 11341 invoked by uid 89); 19 May 2014 09:45:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,T_FSL_HELO_BARE_IP_2 autolearn=no version=3.3.2 X-HELO: plane.gmane.org Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 19 May 2014 09:45:08 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WmK7z-0005a8-F8 for ecos-discuss@ecos.sourceware.org; Mon, 19 May 2014 11:45:03 +0200 Received: from 82.220.1.207 ([82.220.1.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 May 2014 11:45:03 +0200 Received: from baroudi.badreddine by 82.220.1.207 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 May 2014 11:45:03 +0200 To: ecos-discuss@ecos.sourceware.org From: Badreddine Date: Mon, 19 May 2014 09:45:00 -0000 Message-ID: References: <2029563421.8440.1296480614291.JavaMail.root@idefix> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes Subject: [ECOS] Re: Different section placement for kernel and application X-SW-Source: 2014-05/txt/msg00001.txt.bz2 Martin Rösch neratec.com> writes: > > Hi, > > On 2011-01-28, Grant Edwards gmail.com> wrote: > > I'm curious why you want to do this. What benefit does it provide? > > I have to link a C++ Application to eCos (with FreeBSD Stack and uSTL) on a STM32 derived board. > The footprint is to big to run it from the internal flash. So we decided to run it from external RAM. > Unfortunately the performance regarding IRQ handling of a RAM Application is too bad: > Using the timers test from the STM32 variant HAL, I've set only TIM1 active and then varied the update > interrupt period. It turned out, that with a period of 20msec. the IRQ handler run into an Assertion in > the post_dsr() function: > ASSERT FAIL: <5>intr.cxx[292]void Cyg_Interrupt::post_dsr() DSR list is not empty but its head is 0 > > Doing the same test with a ROM Application, the period can be lowered to 50usec. > > So I'm trying to move the eCos library that contains the ISRs, DSRs etc. to the Internal Flash while keeping > the rest of the application (that has no ISRs and DSRs) still in the external RAM. > > I hope this Setup will improve the IRQ handling. > > Greetings, > > Martin > Hi Martin, I am about to start a new project using ecos (need to posix os with tcp/ip stack) and I want to know roughly the footprint of the os. Do you know how much does ecos with tcp/ip stack consume? Thanks, Badreddine -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss