On Thursday, May 26, 2011, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you wrote:
>>
>> and then start banging on arch maintainers heads to implement the trivial
>> ISR to kick the prescaler:
>
> I guess a lot of my confusion could be removed if you could think of a
> better name for
Dear Graeme Russ,
In message you wrote:
>
> and then start banging on arch maintainers heads to implement the trivial
> ISR to kick the prescaler:
I guess a lot of my confusion could be removed if you could think of a
better name for this function. For me a "prescaler" has a very
definitive mea
Dear Albert ARIBAUD,
> Le 26/05/2011 07:25, Graeme Russ a écrit :
>
>> I think we can still rationalise the timer API as suggested which, as
>> a minimum will:
>>
>> - Not diminish current functionality for any platform
>> - Will dramatically reduce the current amount of code duplication
>>
Hi Albert,
On Thu, May 26, 2011 at 3:55 PM, Albert ARIBAUD
wrote:
> Le 26/05/2011 07:25, Graeme Russ a écrit :
>
>> I think we can still rationalise the timer API as suggested which, as
>> a minimum will:
>>
>> - Not diminish current functionality for any platform
>> - Will dramatically reduce
Le 26/05/2011 07:25, Graeme Russ a écrit :
> I think we can still rationalise the timer API as suggested which, as
> a minimum will:
>
> - Not diminish current functionality for any platform
> - Will dramatically reduce the current amount of code duplication
> - Improve functionality on some
On Thu, May 26, 2011 at 3:16 PM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message <4f2e.8070...@comcast.net> you wrote:
>>
>> True, if the processor supports timer interrupts. The problem is
>> that the existing u-boots in many cases do not. I think that is really
>> th
Dear "J. William Campbell",
In message <4f2e.8070...@comcast.net> you wrote:
>
>True, if the processor supports timer interrupts. The problem is
> that the existing u-boots in many cases do not. I think that is really
> the crux of the problem. So what are we going to do? I am open t
On 5/25/2011 9:40 PM, Graeme Russ wrote:
> On Thu, May 26, 2011 at 2:19 PM, Reinhard Meyer
> wrote:
>> Dear Graeme Russ,
>>> On closer inspection, some do, some don't. All ARMv7 (OMAP, S5P, Tegra2)
>>> do. at91 is odd - It looks like it uses interrupts, but get_timer() and
>>> udelay() both end u
On 5/25/2011 9:19 PM, Reinhard Meyer wrote:
> Dear Graeme Russ,
>> On closer inspection, some do, some don't. All ARMv7 (OMAP, S5P, Tegra2)
>> do. at91 is odd - It looks like it uses interrupts, but get_timer() and
>> udelay() both end up calling get_timer_raw() (with udelay only having
>> millisec
On Thu, May 26, 2011 at 2:19 PM, Reinhard Meyer
wrote:
>
> Dear Graeme Russ,
>>
>> On closer inspection, some do, some don't. All ARMv7 (OMAP, S5P, Tegra2)
>> do. at91 is odd - It looks like it uses interrupts, but get_timer() and
>> udelay() both end up calling get_timer_raw() (with udelay only h
Dear Graeme Russ,
> On closer inspection, some do, some don't. All ARMv7 (OMAP, S5P, Tegra2)
> do. at91 is odd - It looks like it uses interrupts, but get_timer() and
> udelay() both end up calling get_timer_raw() (with udelay only having
> millisecond resolution it seems). Some others can be confi
On Thu, May 26, 2011 at 10:15 AM, J. William Campbell
wrote:
> On 5/25/2011 4:13 PM, Graeme Russ wrote:
>>
>> Hi Wolfgang
>>
>> On Thu, May 26, 2011 at 7:16 AM, Wolfgang Denk wrote:
>>>
>>> Dear Graeme Russ,
>>>
>>> In message<4ddd7066.4000...@gmail.com> you wrote:
>
[snip]
_exactly_
On 5/25/2011 4:13 PM, Graeme Russ wrote:
> Hi Wolfgang
>
> On Thu, May 26, 2011 at 7:16 AM, Wolfgang Denk wrote:
>> Dear Graeme Russ,
>>
>> In message<4ddd7066.4000...@gmail.com> you wrote:
No, not at all. And I already answered this. For example on PPC, just
reading the timebase would
Hi Wolfgang
On Thu, May 26, 2011 at 7:16 AM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4ddd7066.4000...@gmail.com> you wrote:
>>
>> > No, not at all. And I already answered this. For example on PPC, just
>> > reading the timebase would be perfectly sufficient, and simpler and
>> >
Dear Graeme Russ,
In message <4ddd7066.4000...@gmail.com> you wrote:
>
> > No, not at all. And I already answered this. For example on PPC, just
> > reading the timebase would be perfectly sufficient, and simpler and
> > more reliable than the current interrupt based approach.
>
> I assume by 'ti
On 25/05/11 23:38, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you wrote:
>>
>> And what about platforms that do not support interrupts? Are you
>> mandating that get_timer() MUST always be supported by a timer updated
>> by an ISR?
>
> No, not at all. And I already answered this. Fo
Dear "J. William Campbell",
In message <4ddd6930.2080...@comcast.net> you wrote:
>
> methods are functionally identical. The only problems arise on systems
> that don't support interrupts and don't have any timers with enough bits
> available to meet the 4294967 seconds maximum interval requirem
On 5/25/2011 12:46 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you wrote:
>> I hope to get an implementation agreed upon that does not require
>> interrupts at all, provided a tick counter with sufficiently long roll
>> over time is available (longer than the maximum expected perio
Dear "J. William Campbell",
In message <4ddd3354.8030...@comcast.net> you wrote:
>
> >> A tick is defined as the smallest increment of system time as measured by a
> >> computer system (seehttp://en.wikipedia.org/wiki/System_time):
> >>
> >>System time is measured by a system clock, which is t
Dear Graeme Russ,
In message you wrote:
>
> I hope to get an implementation agreed upon that does not require
> interrupts at all, provided a tick counter with sufficiently long roll
> over time is available (longer than the maximum expected period
> between 'related' get_timer() calls, for exam
On 5/24/2011 10:17 PM, Wolfgang Denk wrote:
Dear "J. William Campbell",
In message<4ddc31eb.6040...@comcast.net> you wrote:
...
A tick is defined as the smallest increment of system time as measured by a
computer system (seehttp://en.wikipedia.org/wiki/System_time):
System time is mea
Hi Scott,
On Wednesday, May 25, 2011, Scott McNutt wrote:
> Graeme Russ wrote:
>
> Hi Scott,
>
> On Wednesday, May 25, 2011, Scott McNutt wrote:
>
> Graeme Russ wrote:
>
> Hi Scott,
>
> On 25/05/11 22:36, Scott McNutt wrote:
>
> Graeme Russ wrote:
>
> OK, let's wind back - My original suggestion
Graeme Russ wrote:
> Hi Scott,
>
> On Wednesday, May 25, 2011, Scott McNutt wrote:
>> Graeme Russ wrote:
>>
>> Hi Scott,
>>
>> On 25/05/11 22:36, Scott McNutt wrote:
>>
>> Graeme Russ wrote:
>>
>> OK, let's wind back - My original suggestion made no claim towards changing
>> what the API is used
Dear Graeme Russ,
In message you wrote:
>
> And what about platforms that do not support interrupts? Are you
> mandating that get_timer() MUST always be supported by a timer updated
> by an ISR?
No, not at all. And I already answered this. For example on PPC, just
reading the timebase would be p
Hi Scott,
On Wednesday, May 25, 2011, Scott McNutt wrote:
> Graeme Russ wrote:
>
> Hi Scott,
>
> On 25/05/11 22:36, Scott McNutt wrote:
>
> Graeme Russ wrote:
>
> OK, let's wind back - My original suggestion made no claim towards changing
> what the API is used for, or how it looks to those who u
On Wednesday, May 25, 2011, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4ddcf926.1050...@gmail.com> you wrote:
>>
>> Many platforms have a hardware counter which is incremented without
>> assistance from software - not by an ISR, nothing (I mentioned this before,
>> but I can't track
Graeme Russ wrote:
> Hi Scott,
>
> On 25/05/11 22:36, Scott McNutt wrote:
>> Graeme Russ wrote:
>>> OK, let's wind back - My original suggestion made no claim towards changing
>>> what the API is used for, or how it looks to those who use it (for all
>>> practical intents and purposes). I suggeste
Dear Graeme Russ,
In message <4ddcf926.1050...@gmail.com> you wrote:
>
> Many platforms have a hardware counter which is incremented without
> assistance from software - not by an ISR, nothing (I mentioned this before,
> but I can't track down the exact email) - THIS is the tick counter returned
Hi Scott,
On 25/05/11 22:36, Scott McNutt wrote:
> Graeme Russ wrote:
>> OK, let's wind back - My original suggestion made no claim towards changing
>> what the API is used for, or how it looks to those who use it (for all
>> practical intents and purposes). I suggested:
>> - Removing set_timer()
Hi Wolfgang,
On 25/05/11 22:26, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4ddced75.8030...@gmail.com> you wrote:
>>
> I don't get you. In such a system, the interrupt would be the tick
> (see the PPC implementation). If you miss interrupts, you miss ticks.
> ...
>>> The "
Graeme Russ wrote:
> OK, let's wind back - My original suggestion made no claim towards changing
> what the API is used for, or how it looks to those who use it (for all
> practical intents and purposes). I suggested:
> - Removing set_timer() and reset_timer()
> - Implement get_timer() as a platf
Dear Graeme Russ,
In message <4ddceda1.2010...@gmail.com> you wrote:
>
> >> 3) Keep calling get_timer() (which you do when checking protocol time-outs)
> >> - This keeps kicking the prescaler
> >
> > We cannot guarantee for this, so this is not really an option.
>
> You can when you are waiting
Dear Graeme Russ,
In message <4ddced75.8030...@gmail.com> you wrote:
>
> >>> I don't get you. In such a system, the interrupt would be the tick
> >>> (see the PPC implementation). If you miss interrupts, you miss ticks.
...
> > The "tick counter" is already in the higher level, i. e. implemente
Hi Wolfgang,
On 25/05/11 21:32, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4ddcbd3d.4080...@gmail.com> you wrote:
>>
>>> I see two options:
>>>
>>> 1) either we can have some signal when the timer wrapes around (like
>>>an interrupt); in this case it does not matter how big the
Hi Wolfgang,
On 25/05/11 21:37, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4ddcbff4.40...@gmail.com> you wrote:
>>
>>> I don't get you. In such a system, the interrupt would be the tick
>>> (see the PPC implementation). If you miss interrupts, you miss ticks.
>>
>> Yes, you miss t
Dear Graeme Russ,
In message <4ddcbff4.40...@gmail.com> you wrote:
>
> > I don't get you. In such a system, the interrupt would be the tick
> > (see the PPC implementation). If you miss interrupts, you miss ticks.
>
> Yes, you miss ticks, but if the hardware is keeping the tick counter
> curren
Dear Graeme Russ,
In message <4ddcbd3d.4080...@gmail.com> you wrote:
>
> > I see two options:
> >
> > 1) either we can have some signal when the timer wrapes around (like
> >an interrupt); in this case it does not matter how big the counter
> >itself is, we just increment our own local 64
On 25/05/11 18:08, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you wrote:
>>
>> With the prescaler design we are discussing, as long as we have access to
>> a free-running tick counter, it does not matter one iota if the interrupt
>> is delayed by one tick, a hundred ticks or a thousa
On 25/05/11 18:06, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you wrote:
>>
>> Well, I think we can leave NTP out of the picture for U-Boot - What I am
>> really getting at is are the time bases for udelay() and get_timer() the
>> same, and are they always the most accurate which is
Dear Graeme Russ,
In message you wrote:
>
> With the prescaler design we are discussing, as long as we have access to
> a free-running tick counter, it does not matter one iota if the interrupt
> is delayed by one tick, a hundred ticks or a thousand ticks privided it
> eventually happens within
Dear Graeme Russ,
In message you wrote:
>
> Well, I think we can leave NTP out of the picture for U-Boot - What I am
> really getting at is are the time bases for udelay() and get_timer() the
> same, and are they always the most accurate which is readily available
> to U-Boot.
Please assume "no
Hi Wolfgang,
On Wed, May 25, 2011 at 3:28 PM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message <4ddc6f46.4090...@comcast.net> you wrote:
>>
>> Well, it is not quite that simple. The "accuracy" of the 1 ms
>> interrupt rate is controlled in all cases I know about by the re
Hi Wolfgang
On Wed, May 25, 2011 at 3:25 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you wrote:
>>
>> > Yes, but without any guarantee for accuracy or resolution.
>> > This is good enough for timeouts, but nothing for time measurements.
>>
>> Out of curiosity, are there any platf
Dear "J. William Campbell",
In message <4ddc6f46.4090...@comcast.net> you wrote:
>
> Well, it is not quite that simple. The "accuracy" of the 1 ms
> interrupt rate is controlled in all cases I know about by the resolution
> of the programmable divider used to produce it. It appears that
Dear Graeme Russ,
In message you wrote:
>
> > Yes, but without any guarantee for accuracy or resolution.
> > This is good enough for timeouts, but nothing for time measurements.
>
> Out of curiosity, are there any platforms that do not use their most
> accurate source(*) as the timebase for get_
Dear "J. William Campbell",
In message <4ddc31eb.6040...@comcast.net> you wrote:
...
> A tick is defined as the smallest increment of system time as measured by a
> computer system (seehttp://en.wikipedia.org/wiki/System_time):
>
> System time is measured by a system clock, which is typical
On Wed, May 25, 2011 at 12:53 PM, J. William Campbell
wrote:
> On 5/24/2011 5:17 PM, Graeme Russ wrote:
>>
>> On Wed, May 25, 2011 at 5:19 AM, Wolfgang Denk wrote:
>>>
>>> Dear Graeme Russ,
>>>
>>> In message<4ddbe22d.6050...@gmail.com> you wrote:
>>
>> Why must get_timer() be used to pe
On 5/24/2011 5:17 PM, Graeme Russ wrote:
> On Wed, May 25, 2011 at 5:19 AM, Wolfgang Denk wrote:
>> Dear Graeme Russ,
>>
>> In message<4ddbe22d.6050...@gmail.com> you wrote:
> Why must get_timer() be used to perform "meaningful time measurement?"
Excellent question! It was never intende
On Wed, May 25, 2011 at 5:19 AM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4ddbe22d.6050...@gmail.com> you wrote:
>>
>> >> Why must get_timer() be used to perform "meaningful time measurement?"
>> >
>> > Excellent question! It was never intended to be used as such.
>>
>> Because ge
On 5/24/2011 12:19 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message<4ddbe22d.6050...@gmail.com> you wrote:
Why must get_timer() be used to perform "meaningful time measurement?"
>>> Excellent question! It was never intended to be used as such.
>> Because get_timer() as it currentl
Dear "J. William Campbell",
In message <4ddbfff5.1020...@comcast.net> you wrote:
>
> First, it seems that the get_timer interface is expected to work
> properly only after relocation and only when bss is available. I say
> this because the PPC version uses an (initialized) variable, timestamp,
Dear Graeme Russ,
In message <4ddbe22d.6050...@gmail.com> you wrote:
>
> >> Why must get_timer() be used to perform "meaningful time measurement?"
> >
> > Excellent question! It was never intended to be used as such.
>
> Because get_timer() as it currently stands can as it is assumed to return
Dear "J. William Campbell",
In message <4ddbcd69.9090...@comcast.net> you wrote:
>
> After really looking into this, I think I agree with Wolfgang
> that using ms for a get_timer timebase is the best way to go. This
> thinking is heavily influenced (in my case anyway) by the fact that i
On 5/24/2011 9:51 AM, Graeme Russ wrote:
> On 25/05/11 00:19, Wolfgang Denk wrote:
> =
Hi all,
I have a few of questions.
First, it seems that the get_timer interface is expected to work
properly only after relocation and only when bss is available. I say
this because the PP
On 25/05/11 00:19, Wolfgang Denk wrote:
> Dear Scott McNutt,
>
> In message <4ddbb29d.2050...@psyent.com> you wrote:
>>
>> Why must get_timer() be used to perform "meaningful time measurement?"
>
> Excellent question! It was never intended to be used as such.
Because get_timer() as it currently
On 5/24/2011 7:12 AM, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message<4ddb4c1c.7030...@aribaud.net> you wrote:
>> Not sure I still follow what the two options are -- a heads up is welcome.
>> However, I do like the simplicity in having a single time unit (ticks)
>> for the timer API --
Dear Scott McNutt,
In message <4ddbb29d.2050...@psyent.com> you wrote:
>
> Why must get_timer() be used to perform "meaningful time measurement?"
Excellent question! It was never intended to be used as such.
Also, neither udelay() nor get_timer() make any warranties about
accuracy or precision.
Dear Graeme Russ,
In message <4ddb59cd.2020...@gmail.com> you wrote:
>
> My preference is to expose SI (and derivative) units of time measurement
> (seconds, milliseconds, microseconds) only to the outside world (drivers,
> stand alone applications etc)
Please delete the "to the outside world ...
Dear Albert ARIBAUD,
In message <4ddb4c1c.7030...@aribaud.net> you wrote:
>
> Not sure I still follow what the two options are -- a heads up is welcome.
> However, I do like the simplicity in having a single time unit (ticks)
> for the timer API -- asuming it covers all needs -- and providing othe
Graeme Russ wrote:
> Dear Reinhard,
>
> On Tue, May 24, 2011 at 3:31 PM, Reinhard Meyer
> wrote:
>> I know its futile to repeat what I suggested about 9 months ago...
>>
>> Since get_timer() is only used (to my knowledge) to break out of
>> loops that do not terminate normally because an expected
On 24/05/11 16:11, Albert ARIBAUD wrote:
> Le 24/05/2011 07:43, Graeme Russ a écrit :
>> Dear Reinhard,
>>
>> On Tue, May 24, 2011 at 3:31 PM, Reinhard Meyer
>> wrote:
>>> I know its futile to repeat what I suggested about 9 months ago...
>>>
>>> Since get_timer() is only used (to my knowledge) t
Le 24/05/2011 07:43, Graeme Russ a écrit :
> Dear Reinhard,
>
> On Tue, May 24, 2011 at 3:31 PM, Reinhard Meyer
> wrote:
>> I know its futile to repeat what I suggested about 9 months ago...
>>
>> Since get_timer() is only used (to my knowledge) to break out of
>> loops that do not terminate norm
Dear Reinhard,
On Tue, May 24, 2011 at 3:31 PM, Reinhard Meyer
wrote:
> I know its futile to repeat what I suggested about 9 months ago...
>
> Since get_timer() is only used (to my knowledge) to break out of
> loops that do not terminate normally because an expected event does
> not occur, the fo
I know its futile to repeat what I suggested about 9 months ago...
Since get_timer() is only used (to my knowledge) to break out of
loops that do not terminate normally because an expected event does
not occur, the following API would be simpler and take less time per
loop:
(I use the names A and
Mike,
On Tue, May 24, 2011 at 2:24 PM, Mike Frysinger wrote:
> rather than inventing our own set of terms, how about piggybacking what Linux
> has already done ? they have "cycle counters" and "timer counters" (which
> bubble up into "clock sources", but i dont think we need those).
I only put
rather than inventing our own set of terms, how about piggybacking what Linux
has already done ? they have "cycle counters" and "timer counters" (which
bubble up into "clock sources", but i dont think we need those).
further, Linux probably already has implementations we can steal for the arch-
Hi All,
OK, here goes - A much more in-depth generic analysis for a timer API
I hope this highlights why the current discussion thread has ended
up where is has
Regards,
Graeme
Definitions:
'register' - A storage element - Can be:
- A dedicated CPU register
- A location in memory (as de
On Saturday, May 21, 2011 08:38:29 Graeme Russ wrote:
> NOTE: http://lists.denx.de/pipermail/u-boot/2010-June/073024.html appears
> to imply the following implementation of get_timer() is wrong:
>
> ulong get_timer(ulong base)
> {
> return get_timer_masked() - base;
>
Dear "J. William Campbell",
In message <4ddac2f5.7060...@comcast.net> you wrote:
>
> Does that sound right?
I think so.
> --000308010205050804040502
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
Could you please stop posting HTML? Thanks.
Best re
On 23/05/11 23:19, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4dda5334.4060...@gmail.com> you wrote:
>>
- A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks()
and get_tick_rate() to correctly maintain the ms counter used by
get_timer() - This f
On 5/23/2011 12:33 PM, Wolfgang Denk wrote:
Dear "J. William Campbell",
In message<4ddaa705.1040...@comcast.net> you wrote:
My apologies for being a little (perhaps more than a little)
dense. As they say, "after further review", I think the key aspect of
the PPC timer system is that it
Dear "J. William Campbell",
In message <4ddaa705.1040...@comcast.net> you wrote:
>
> My apologies for being a little (perhaps more than a little)
> dense. As they say, "after further review", I think the key aspect of
> the PPC timer system is that it uses the decrementer register to
> ge
Dear "J. William Campbell",
In message <4dda99bc.80...@comcast.net> you wrote:
>
> >> The library function acts as a pre-scaler using a 'raw tick counter' and a
> >> 'raw tick rate' supplied by the low level architecture. We define this weak
> > What are "raw" ticks? And what are "cooked" ticks,
On 5/23/2011 6:19 AM, Wolfgang Denk wrote:
> Dear Graeme Russ,
> This is what PPC is doing. And I understand that Reinhard did the same
> in software for AT91.
Hi All,
My apologies for being a little (perhaps more than a little)
dense. As they say, "after further review", I think the key as
Le 23/05/2011 19:30, J. William Campbell a écrit :
>> Did you have a look at the PowerPC implementation? I'd like to see
>> this used as reference.
> I have looked at it as a reference. However, there is one disadvantage
> in using the PPC code as a reference. It has a 64 bit timestamp. Many
> sy
On 5/23/2011 6:19 AM, Wolfgang Denk wrote:
Dear Graeme Russ,
In message<4dda5334.4060...@gmail.com> you wrote:
- A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks()
and get_tick_rate() to correctly maintain the ms counter used by
get_timer() - This function can be
On 5/22/2011 11:29 PM, Albert ARIBAUD wrote:
Hi all,
Sorry, could not follow the discussion although I find it very
interesting, so I will handle the task of coming in late and asking the
silly questions.
I am glad you are looking at our discussion. I am sure we are going to
need all the help/o
Dear Graeme Russ,
In message <4dda5334.4060...@gmail.com> you wrote:
>
> >> - A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks()
> >>and get_tick_rate() to correctly maintain the ms counter used by
> >>get_timer() - This function can be weak (so next point)
> >
> > Di
On 23/05/11 22:09, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> sorry for jumping in late here (was busy with the ELDK 5.0 release).
I thought you were a bit quite on such a 'touchy' subject ;)
>
> In message you wrote:
>> OK, so in summary, we can (in theory) have:
>> - A timer API in /lib/
Dear "J. William Campbell",
In message <4dd8b3ed.4000...@comcast.net> you wrote:
>
...
>This statement, as written, is false. While it is true that the
> power PC (and others) have a 64 bit counter that runs at a many
> megahertz rate, it is NOT true that all 64 bits must be used to obta
Dear Graeme Russ,
sorry for jumping in late here (was busy with the ELDK 5.0 release).
In message you wrote:
> OK, so in summary, we can (in theory) have:
> - A timer API in /lib/ with a single u32 get_timer(u32 base) function
> - A HAL with two functions
>- u32 get_raw_ticks()
What des t
On 23/05/11 16:29, Albert ARIBAUD wrote:
> Hi all,
>
> Sorry, could not follow the discussion although I find it very
> interesting, so I will handle the task of coming in late and asking the
> silly questions.
>
> Le 23/05/2011 07:25, Graeme Russ a écrit :
>
>> On Mon, May 23, 2011 at 3:02 PM
Hi all,
Sorry, could not follow the discussion although I find it very
interesting, so I will handle the task of coming in late and asking the
silly questions.
Le 23/05/2011 07:25, Graeme Russ a écrit :
> On Mon, May 23, 2011 at 3:02 PM, J. William Campbell
> wrote:
>> On 5/22/2011 6:42 PM,
On Mon, May 23, 2011 at 3:02 PM, J. William Campbell
wrote:
> On 5/22/2011 6:42 PM, Graeme Russ wrote:
>>
>> OK, so in summary, we can (in theory) have:
>> - A timer API in /lib/ with a single u32 get_timer(u32 base) function
>> - A HAL with two functions
>> - u32 get_raw_ticks()
>> - u32
On 5/22/2011 8:26 PM, Reinhard Meyer wrote:
> Dear J. William Campbell,
>> On 5/22/2011 1:15 AM, Reinhard Meyer wrote:
>>> Dear J. William Campbell,
>>>
>>> please demonstrate for me (and others), by a practical example,
>>> how _any_ arithmetic (even less with just shifts and multiplies)
>>> can c
On 5/22/2011 6:42 PM, Graeme Russ wrote:
> OK, so in summary, we can (in theory) have:
> - A timer API in /lib/ with a single u32 get_timer(u32 base) function
> - A HAL with two functions
> - u32 get_raw_ticks()
> - u32 get_raw_tick_rate() which returns the tick rate in kHz (which
>
Dear J. William Campbell,
> On 5/22/2011 1:15 AM, Reinhard Meyer wrote:
>> Dear J. William Campbell,
>>
>> please demonstrate for me (and others), by a practical example,
>> how _any_ arithmetic (even less with just shifts and multiplies)
>> can convert a free running 3.576 MHz (wild example) free
OK, so in summary, we can (in theory) have:
- A timer API in /lib/ with a single u32 get_timer(u32 base) function
- A HAL with two functions
- u32 get_raw_ticks()
- u32 get_raw_tick_rate() which returns the tick rate in kHz (which
max's out at just after 4GHz)
- A helper function in /
Hi Bill,
On Mon, May 23, 2011 at 10:14 AM, J. William Campbell
wrote:
> On 5/22/2011 1:15 AM, Reinhard Meyer wrote:
>>
>> Dear J. William Campbell,
>>
>> please demonstrate for me (and others), by a practical example,
>> how _any_ arithmetic (even less with just shifts and multiplies)
>> can conv
On 5/22/2011 5:02 PM, Graeme Russ wrote:
> Dear Reinhard,
>
> On Sun, May 22, 2011 at 6:15 PM, Reinhard Meyer
> wrote:
>> Dear J. William Campbell,
>>
>> please demonstrate for me (and others), by a practical example,
>> how _any_ arithmetic (even less with just shifts and multiplies)
>> can conv
On 5/22/2011 1:15 AM, Reinhard Meyer wrote:
Dear J. William Campbell,
please demonstrate for me (and others), by a practical example,
how _any_ arithmetic (even less with just shifts and multiplies)
can convert a free running 3.576 MHz (wild example) free running
32 bit counter (maybe software e
Dear Reinhard,
On Sun, May 22, 2011 at 6:15 PM, Reinhard Meyer
wrote:
> Dear J. William Campbell,
>
> please demonstrate for me (and others), by a practical example,
> how _any_ arithmetic (even less with just shifts and multiplies)
> can convert a free running 3.576 MHz (wild example) free runni
Dear J. William Campbell,
please demonstrate for me (and others), by a practical example,
how _any_ arithmetic (even less with just shifts and multiplies)
can convert a free running 3.576 MHz (wild example) free running
32 bit counter (maybe software extended to 64 bits) into a ms
value that will
On 22/05/11 17:21, J. William Campbell wrote:
> On 5/21/2011 11:23 PM, Graeme Russ wrote:
>> On 22/05/11 14:26, Reinhard Meyer wrote:
>>> - shall not be used for delays in the seconds range and longer
>>> (or any other limit we see practical)
>> Any udelay up to the full range of a ulong should be
On 5/21/2011 11:23 PM, Graeme Russ wrote:
> On 22/05/11 14:26, Reinhard Meyer wrote:
>> Dear Graeme Russ,
>>> Hi All,
>>>
>>> I've just had a good look through the timer API code with the view of
>>> rationalising it and fixing up some of the inconsistencies. What I found
>>> was a little scarier t
On 5/21/2011 9:26 PM, Reinhard Meyer wrote:
> Dear Graeme Russ,
>> Hi All,
>>
>> I've just had a good look through the timer API code with the view of
>> rationalising it and fixing up some of the inconsistencies. What I found
>> was a little scarier than I expected! Anyway, here is a write-up of w
On 22/05/11 14:26, Reinhard Meyer wrote:
> Dear Graeme Russ,
>> Hi All,
>>
>> I've just had a good look through the timer API code with the view of
>> rationalising it and fixing up some of the inconsistencies. What I found
>> was a little scarier than I expected! Anyway, here is a write-up of what
Dear Graeme Russ,
> Hi All,
>
> I've just had a good look through the timer API code with the view of
> rationalising it and fixing up some of the inconsistencies. What I found
> was a little scarier than I expected! Anyway, here is a write-up of what I
> found - Please comment
We have been at thi
On 5/21/2011 5:06 PM, Graeme Russ wrote:
> On 22/05/11 01:33, J. William Campbell wrote:
>> On 5/21/2011 5:38 AM, Graeme Russ wrote:
>>> Hi All,
>>> 4. Implement microsecond API - get_usec_timer()
>>> ---
>>>- Useful for profiling
>>>- A 32-bit mi
On 22/05/11 01:33, J. William Campbell wrote:
> On 5/21/2011 5:38 AM, Graeme Russ wrote:
>> Hi All,
>> 4. Implement microsecond API - get_usec_timer()
>> ---
>> - Useful for profiling
>> - A 32-bit microsecond counter wraps in 71 minutes - Probably O
1 - 100 of 101 matches
Mail list logo
