This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
AW: how to measure time from within flash_program_buf
- From: "Neundorf, Alexander" <Alexander dot Neundorf at jenoptik dot com>
- To: "Andrew Lunn" <andrew at lunn dot ch>, "David Vrabel" <dvrabel at arcom dot com>
- Cc: <ecos-discuss at ecos dot sourceware dot org>
- Date: Tue, 23 May 2006 11:20:45 +0200
- Subject: AW: [ECOS] how to measure time from within flash_program_buf
Hi,
> Von: Andrew Lunn [mailto:andrew@lunn.ch]
>
> 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.
These are all the issues we also thought about but didn't come to a nice solution.
While making the loop count a CDL value is better than hardcoding it, it is still not really good.
Bye
Alex
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss