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

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

[Neundorf, Alexander]

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

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

[Andrew Lunn]

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

Implementing a time based solution is also not really good since it
adds bloat. 

99% of hardware will always run at the same speed and have the same
flash access speed. You only once need to calibrate the loop and then
it is fixed for the hardware. So there is no real need to dynamically
calibrate your delay loop.

          Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] how to measure time from within flash_program_buf

[Neundorf, Alexander]

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.

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.

So we see the following options:
-just increase the loop counter (ugly)
-use some ifdefs and access the timer registers directly (slightly less ugly)
-remove the timeout completely and just wait until it has finished (still ugly)
-make hal_clock_read() inline -> changes behaviour everywhere (also not too nice)

So, how do you deal with this problem or do you have a better suggestion ?

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

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

[Andrew Lunn]

On Tue, May 23, 2006 at 09:32:03AM +0200, 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.
> 
> 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.
> 
> So we see the following options:
> -just increase the loop counter (ugly)
> -use some ifdefs and access the timer registers directly (slightly less ugly)
> -remove the timeout completely and just wait until it has finished (still ugly)
> -make hal_clock_read() inline -> changes behaviour everywhere (also not too nice)
> 
> So, how do you deal with this problem or do you have a better suggestion ?

Probably a better solution is to change the hard coded value into a
CDL paramter so that it can be configured.

    Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

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

[David Vrabel]

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

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

[Andrew Lunn]

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.

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

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

[David Vrabel]

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