Comments on: AVR System Timer http://www.shapeshifter.se/2009/06/02/avr-system-timer/ Mostly miscellaneous technical mumbo-jumbo. Sun, 11 Nov 2012 22:20:30 +0100 http://wordpress.org/?v=2.8.6 hourly 1 By: fli http://www.shapeshifter.se/2009/06/02/avr-system-timer/comment-page-1/#comment-1713 fli Wed, 10 Jun 2009 08:41:34 +0000 http://www.shapeshifter.se/?p=546#comment-1713 No, it was not intentional and yes, you're right. Should be enough to disable the timer interrupts only though. (Anecdotal evidence, been using this a lot and I've never seen a bad value) No, it was not intentional and yes, you’re right.
Should be enough to disable the timer interrupts only though.

(Anecdotal evidence, been using this a lot and I’ve never seen a bad value)

]]> By: Nick Hibma http://www.shapeshifter.se/2009/06/02/avr-system-timer/comment-page-1/#comment-1710 Nick Hibma Wed, 10 Jun 2009 06:43:00 +0000 http://www.shapeshifter.se/?p=546#comment-1710 You are not using any sei() and cli() calls in clock_time(). Is this intentional? I can't imagine an 8-bit CPU updating a 32 bit value atomically. The problam arises when for example 0x0000ffff is incremented while clock_time() is fetching the value. Depending on how the memory is fetched you might get 0x00000000 or 0x0001ffff instead of the correct 0x0000ffff or 0x0001ffff values. Nick "I've written 1000 lines of AVR code as well!" Hibma You are not using any sei() and cli() calls in clock_time(). Is this intentional? I can’t imagine an 8-bit CPU updating a 32 bit value atomically. The problam arises when for example 0×0000ffff is incremented while clock_time() is fetching the value. Depending on how the memory is fetched you might get 0×00000000 or 0×0001ffff instead of the correct 0×0000ffff or 0×0001ffff values.

Nick “I’ve written 1000 lines of AVR code as well!” Hibma

]]>