Subject:
|
Re: sys_time (long post)
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Fri, 13 Dec 2002 17:13:27 GMT
|
Viewed:
|
2821 times
|
| |
|
|
"Joseph Woolley" <jwoolley@spamblock.insight.rr.com> wrote:
> Could the 'Get' function do the following? (I wonder)
>
> Read sys_time into A;
> Read sys_time into B;
> return the larger of the two;
It turns out that the nature of the glitch depends
on the order you read the upper and lower 16-bits
of sys_time. If the compiler generates code that
reads the high word first (which it seems to do),
then your example will work. However, if the low
word is read first then you want to return the minimum
of the two readings. In this case, sys_time would
appear to increment as follows when the glitch
occurred:
0x0014FFFE
0x0014FFFF
0x0015FFFF
0x00150000
0x00150001
Contrast this with the increment example I gave in
my original post.
> Another similar approach would be...
>
> disable irqs;
> Clear sys_time_flag;
> Read sys_time into A;
> check sys_time_flag, if non-zero, reread sys_time into A;
> enable irqs;
> return A;
>
> The sys_time handler would update sys_time and set the sys_time flag to
> non-zero.
Actually, you don't need to keep a seperate flag
because if you read the low word twice and it changes
then you know the NMI occurred. That's how the
get_sys_time() function in my original post works.
> I guess it comes down to:
>
> sys_time is as accurate as possible, but it takes a bit of work to read • it.
> -- or --
> sys_time is easy to read, but can be kept from updating by masking
> interrupts off.
>
> I am leaning toward the first situation myself.
Me, too. So, we'd have something like the get_sys_time()
function if the user needs 32-bit timer resolution.
Often times, however, the user only needs a 16-bit timer.
For example, see Steve Hassenplug's recent post where he
takes sys_time and masks off the lower 3 bits. The upper 29
bits are not necessary for his application. I'd recommend
splitting sys_time into two 16-bit variables, sys_time_low and
sys_time_high, only exposing the sys_time_low to user
programs that can get by with 16-bit resolution. The
sys_time_high variable would be a static in the systime.c
source file. (Of course, there are backwards compatibility
issues here...)
Mark
|
|
Message has 2 Replies:
 | | Re: sys_time (long post)
|
| Does the H8 let an interrupt interrupt an interrupt? (Or at least the interrupts that matter in this case?) You two might want to check on that. It would seem the code is safe if the answer to the first question is no... ? Maybe I'm missing (...) (22 years ago, 13-Dec-02, to lugnet.robotics.rcx.legos)
| | | Re: sys_time (long post)
|
| Only a suggestion, In any processor architecture (with or without disabling or recursive interrupts) when I need to read timers with more than 1 single instruction I do the following: Read the timer (both low and high value) until I get 2 times the (...) (22 years ago, 16-Dec-02, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: sys_time (long post)
|
| Mark, Excellent Post ! Ok, I will admit it; I was the one that put the sys_time handler on the NMI. 8-) I guess I will want to think about this a bit; but I see that you have done a good bit of that yourself. ... Could the 'Get' function do the (...) (22 years ago, 12-Dec-02, to lugnet.robotics.rcx.legos)
|
6 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
