From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3344 invoked by alias); 23 May 2006 09:05:34 -0000 Received: (qmail 3335 invoked by uid 22791); 23 May 2006 09:05:34 -0000 X-Spam-Check-By: sourceware.org Received: from webapps.arcom.com (HELO webapps.arcom.com) (194.200.159.168) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 23 May 2006 09:05:29 +0000 Received: from [10.2.2.14] ([10.2.2.14]) by webapps.arcom.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 10:05:23 +0100 Message-ID: <4472D055.8040201@arcom.com> Date: Tue, 23 May 2006 09:05:00 -0000 From: David Vrabel User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: "Neundorf, Alexander" CC: ecos-discuss@ecos.sourceware.org References: <5A8A17126B73AC4C83968F6C4505E3C504315E0F@JO-EX01.JENOPTIK.NET> In-Reply-To: <5A8A17126B73AC4C83968F6C4505E3C504315E0F@JO-EX01.JENOPTIK.NET> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] how to measure time from within flash_program_buf X-SW-Source: 2006-05/txt/msg00190.txt.bz2 Neundorf, Alexander wrote: > Hi, > > in the Intel 28fxxx flash driver there is a timeout used, and this > timeout is specified as a simple loop which is executed 5000000 > times. Now we have a fast processor and a slow flash, so for us this > timeout isn't big enough. We could simply increase the count, but > this still depends on flash and processor speed. I'd have suggested putting HAL_DELAY_US() macro calls in the loop. That would give you a lower bound on the timeout. However, I think it it has the same problem as HAL_CLOCK_READ() below. How about sticking a few more functions (like hal_delay_us) in .2ram ? > Ideally we'd like to use HAL_CLOCK_READ() to measure the time, but > this isn't possible since hal_clock_read() is located in the section > .text which is in the flash, but flash_program_buf() is located in > the section .data which is located in RAM. When calling > hal_clock_read() the linker complains and more importantly it won't > work since the flash is busy while it is being programmed. David Vrabel -- David Vrabel, Design Engineer Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233 Cambridge CB1 7EA, UK Web: http://www.arcom.com/ -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss