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
