Dear Graeme Russ, In message <banlktink+bxtz+sumyztvuhcd_ft+jf...@mail.gmail.com> 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_timer()? If a platform is using > it's most accurate, commonly available, source for get_timer() the the > whole accuracy argument is moot - You can't get any better anyway so > why sweat the details.
Actually most boards do that, at least most of those who have a RTC chip on board. Almost always these RTCs provide much better accuracy than the system clock used for the CPU-internal timers. In an OS like Linux you will frequently see NTP being used to keep the system time in sync with the more accurate RTC (and eventually other, external time sources). > (*)I'm actually referring to what is commonly available for that platform, > and not where a board has a high precision/accuracy source in addition to > the common source. I'm not sure what you mean here. Quite frequently even SoCs have a number of different clock sources, say a master clock which is used to derive the processor clock, and a 32768 Hz clock which is used to drive a SoC-internal RTC. > As a followup question, how many platforms use two completely independent > sources for udelay() and get_timer() - x86 does, but I plan to change this > so the interrupt kicks the new prescaler which can be done at >> 1ms period > and udelay() and get_timer() will use the same tick source and therefore > have equivalent accuracy. Define "completely independent" - on PowerPC one uses the timebase register, while the other uses the decrementer. But in the end, both of them are most likely derived from the same system clock (or not - depending on SoC design). But this does not matter at all. > Hmmm, I think it is worthwhile at least comparing the two - What is the > lesser of two evils > > 1. Exposing 'ticks' through a HAL for the prescaler > 2. Duplicating a function with identical code 50+ times across the source > tree If it's identical code, all these implementations can share common code, right? > I personally think #2 is way worse - The massive redundant duplication and > blind copying of code is what has get us into this (and many other) messes That don;t do it, and use common code for this. > > Currently we have unsigned long long get_ticks(void) =A0which is better > > as it matches existing hardware. > > Matches PPC - Does it match every other platform? I know it does not match > the sc520 which has a 16-bit millisecond and a 16-bit microsecond counter > (which only counts to 999 before resetting to 0) > > Don't assume every platform can implement a 64-bit tick counter. But yes, > we should cater for those platforms that can There are counters of many different sizes around. You cannot squeeze a bigger counter into a smaller data ubit, but you can easily stick smaller data into a bigger container. So it seems most natural to me to chose that data type that fits all, i. e. a bigger one. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When in doubt, mumble; when in trouble, delegate; when in charge, ponder. -- James H. Boren _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
