Hi, in order to push this forward I just opened a PR for an RDM at https://github.com/RIOT-OS/RIOT/pull/12970. This PR is in an early state and both feedback and help will be greatly appreciated.
> IMO, users should just not use these timer values as timestamps. > That maybe needs to be stated at a prominent place (or multiple) in the > documentation. > For that, we can (should?) re-introduce a 64bit API in ztimer. I don't think that 64 bit is needed for every feature of a high-level timer API; especially for delaying the execution of the calling thread or for software timers. A 64 bit system clock would however be quite nice in some use cases. > > E.g. adding support for dedicated overflow interrupts together with an > > API to read > > the corresponding IRQ status bit. > > The high level timer would benefit from that on many platforms. > > E.g. Ztimer wouldn't require the code for the time partitioning > > mechanism then. > > But thats yet another part of the story... > > Yes. Also, do all platforms support that overflow interrupt? > I don't think so, in which case this cannot be relied upon to be available. This would not strictly be needed. In case either an overflow interrupt or a alarm interrupt is supported, the other could be implemented by the timer driver. (If only an overflow is supported, the driver could set the current timer value so that the overflow interrupt happens exactly when the alarm should happen. And if only an alarm is supported, the driver could multiplex two alarms with one being the overflow.) It needs however to be determined if this would indeed be better. > Marian: would you also be interested in attending a timer meeting? If I can find the time, sure! Some weekend in the first half of January might work for me. How about Kaspar or Michel can organize a room and use one of the many online scheduling services to find out a date most interested developers could join? Kind regards, Marian On Mon, 16 Dec 2019 11:31:34 +0100 Kaspar Schleiser <kas...@schleiser.de> wrote: > Hi Ralf, > > On 12/13/19 6:41 PM, Ralf Schlatterbeck wrote: > > As far as I understand, the new timer implementation would not use 64 > > bit for the timer and the user is responsible for not overrunning the > > timer? Note that I haven't looked a the implementation yet, so forgive > > my ignorance. > > I think you got it right. In ztimer, the clocks' now() value will > overflow after 32bits. > > E.g., `t1 = now(); t2 = now(); assert(t1 < t2)` might fail. > > Setting timer values is always relative (target = now() + X), and X can > be any 32bit value, the user does not need to handle any overflow there. > > > Over the years my experience is that it's no good idea to burden the > > user with the knowledge of timer overflow. The latest example was a > > bunch of HPE SSDs that stop working after 32.768 hours (a little less > > than 4 years). Bad when you have several of them in a RAID for > > redundancy :-) > > Failing after 32768h strongly points to using a signed 16bit variable > for the hours count. That's an odd choice to begin with. > > > https://www.techradar.com/news/hpe-ssd-drives-could-fail-at-this-critical-moment > > So I'd vote for the (small) additional overhead, even on 8-bit µCs due > > to safety reasons. Unless the implementation can produce the correct > > timer representation with, say, C-preprocessor magic at compile-time. > > You mean, you'd vote for all timer values to be always 64bit? I don't > think the overhead is small enough to justify that, but that needs to be > evaluated. > The increased CPU usage needs benchmarks, in RAM we can estimate easily. > > IMO, users should just not use these timer values as timestamps. > That maybe needs to be stated at a prominent place (or multiple) in the > documentation. > For that, we can (should?) re-introduce a 64bit API in ztimer. > > It might make sense to add a (very large or possibly randomized) > constant offset to all 32bit timers, maybe limited to development > builds, that causes the timer value to overflow early(er), so > applications would break early in tests. > > Kaspar > > _______________________________________________ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel
pgpxImlMJaxBj.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
