Dear Wolfgang Denk,
Am 30.11.2010 09:16, schrieb Wolfgang Denk:
Dear "=?UTF-8?B?QW5kcmVhcyBCaWXDn21hbm4=?=",
In message 4CF4AFED.1010609@gmail.com you wrote:
To get this bss issue fixed for v2010.12 I'd like to add another value to GD to hold the last hw timer value. My current usage of tbu should therefore go to tbl, to have a virutal 64 bit value just counting 32 bit, is that right?
That sounds like a terrible mess to me, please do not do that. Either we have a 64 bit counter, hen it should cound the full 64 bit range. Or use a plain uint32_t if 32 bit are sfficient. Don't play any tricks like misusing an "unused" part of one variable for other, independent purposes.
If I got Reinhard correct the uint32 values tbl and tbu do build the Upper and Lower part of an virtual 64 bit counter. His statement is to not use these values in another context like I did (32 bit timestamp and 32 bit 'lastinc' which is really 16 bit). Therefore I additionally suggested to have the idea with virtual 64 bit reproduced for at91rm9200 and use the lower part for timestamp.
I think we should provide a "uint64_t timebase" which represents a real 64 bit counter. And if you need a separate "uint32_t timelast" to store the previous timer value then please make this a separate variable.
As you suggested in another thread those changes will go into next branch. So for v2010.12 I'd like to have a 'short time' solution to get the at91rm9200 boards working. Is it OK to use the tbu/tbl values as mentioned above and then migrate to a uint64_t timebase later on?
regards
Andreas Bießmann