Re: [ECOS] how to measure time from within flash_program_buf

[David Vrabel <dvrabel at arcom dot com>]

Andrew Lunn wrote:
> On Tue, May 23, 2006 at 10:05:25AM +0100, David Vrabel wrote:
>> 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 ?
> 
> These functions are normally in the platform HAL, or varient HAL. So
> you would have to change every target. A lot of work...
> 
> Also, i work on a target which has a reasonable amount of flash and
> very little RAM. I don't want these functions in RAM because i don`t
> have space for them and my flash driver does not require them.

Makes sense.

I'm probably getting over-complicated here, but how about platforms with
large amounts of RAM (most of the ones I use have > 64M) provide a
hal_delay_us in .2ram and a CDL variant that says it does this.  In the
case where the platform doesn't provide this (e.g, not enough ram or
no-one has converted it yet), the flash drivers can fall back to number
of loops as specified in CDL.

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