Subject:
|
System Interrupts & frequency counting
|
Newsgroups:
|
lugnet.robotics.handyboard
|
Date:
|
Mon, 9 Jun 1997 14:23:37 GMT
|
Original-From:
|
Paul Mrozowski <mrozowski@glis/spamless/.net>
|
Viewed:
|
1438 times
|
| |
|
|
I'm in the middle of planning/writing a small program that will read a
digital input to determine it's frequency & pulse width. I thought it'd be
nice to have this part of the program (in assembly) running off the system
interrupt so that these various freqs. & PW are available "transparently"
to my C program (by passing the results into a C Global variable). The one
issue I'm wondering about is how my code will be affected if it is
executing still when the system generates an interrupt. For example, my
code is attempting to measure the freq. of an input. If the freq. is lower
than 1000 Hz (which is the sysint. freq.) my code will still be executing
when sysint. grabs control and gives it to the next routine. Will it return
safely to my code where it left off? Do I even have to worry about this? Or
should I just call my routine directly from C when I need a value? How will
all the other interrupts affect my accuracy? Should I just code the entire
program is assembly (which I >really< don't want to do since C makes some
things really easy to do).
All my code does to calc. the freq. & PW (or, I should say "will do"
since I've only framed it out, not actually coded it) is to first
synchronize to the incoming signal (i.e. wait for a state change). Then it
goes into a loop checking to see if the state has changed again. Each time
through the loop it increments a counter. Once this is all done, I should
be able to calculate both values by using the counter value * # of clock
ticks per instruction executed in the loop (plus using the "total" time of
the signal, etc..). Does this make sense? It seemed the most
straightforward way of handling this. Is there another (more elegant?) way
of doing this?
Any help/suggestions is appreciated. Thanks.
-Paul
RCS Solutions, Inc.
Paul Mrozowski
Phone: (810) 263-4151
Fax : (810) 263-4516
email: mrozowski@glis.net
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzLv93UAAAEEAMVzD+uhIyzcDNiqshReoqMKSTjZ7iyBhzrgxo9UCuQH7ijt
pkK6MFBevzk8BnYC1a+toTOXy8deI0362dST6CLEiV8gf+Uwp+sMtEHjwcd9c6qj
3u8+2eFVdNKTa0wUkhHkkSethY3WB8ln4zN8evMRn9Flg5aF1/YYdzIcSAb9AAUR
tCNQYXVsIE1yb3pvd3NraSA8bXJvem93c2tpQGdsaXMubmV0Pg==
=1l8x
-----END PGP PUBLIC KEY BLOCK-----
|
|
Message has 2 Replies:
 | | Re: System Interrupts & frequency counting
|
| (...) I'm unfamiliar with the workings of IC, but if your interrupt service routine is sufficiently short, and you don't reset the interrupt mask to enable recursive interrupts, you shouldn't notice the difference. You asked if there was a more (...) (27 years ago, 9-Jun-97, to lugnet.robotics.handyboard)
| | | Re: System Interrupts & frequency counting
|
| (...) Paul, What you want to do is easy. All you need to do is get a small assembler routine which uses the Input Capture feature. Set the IC via registers to trigger when a rising pulse begins, it will stash the time and strigger an interrupt. Then (...) (27 years ago, 9-Jun-97, to lugnet.robotics.handyboard)
|
3 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
