|
I agree with Jim; from user state you're not going to be
given access to the registers needed for controlling interrupts unless you find
a way to first elevate to system state.
In my opinion, doing things as a kernel module rather than
a user application is an easier approach. If you're just more comfortable with
the program method, something you could consider is using the "rt" version of
the kernel, which TS includes with the RTAI real time package. I've never used
this part of the package, but one aspect is an API that lets a user program
become a real time progam (in system state), and if can go back to user state as
well. I suspect there's even an API to disable and reenable interrupts safely.
(Well, as safe as possible, which sometimes isn't too safe
;)
It'd probably be easier to learn how to write a kernel
module though, than install RTAI, get the proper modules it provides loaded, and
learn its API. Especially for something as straight-forward as what you're
looking to do.
Caveat: I do Not know a lot about the ARM processor
hardware.
However, in general I would not expect any multi-user capable
processor
hardware to allow code running in "user" mode to execute
instructions
that play with interrupts. You would have to be in some sort
of
"supervisor" mode, i.e. in the kernel.
But I'm willing to be
contradicted and put right.
On Sun, 22 Oct 2006, Don W. Carr
wrote:
> On a stock kernel, I don't think it would be possible to
disable interrupts
> from user mode, but, with this kernel, it is set up
to let you do a lot
> more, like mmap() even. What you need to do is look
up the assembly
> instruction on arm for disabling interrupts, and then
use in-line assembly
> from your C code.
>
> However, you
should only disable interrupts for a few microseconds
> typically, and I
am not sure what it would do disabling them for seconds. It
> would
obviously cause the kernel to miss clock ticks and the clock would be
>
off, but not sure what else it would do.
>
> I also need to disable
interrupts as well for an application where I want to
> read two counters,
one an internal free running counter, and another, and
> XDIO counter
counting pulses on an external signal, so I can measure exact
> time
between external counter readings. In my case however, it would be
> less
than a microsecond or two that interrupts are disabled.
>
> Well, if
anybody has the assembly code to disable (and re-enable)
> interrupts, let
us know.
>
>
>
>
> On 10/22/06, mikedupuis2000
< mikedupuis2000@yahoo.ca>
wrote:
> >
> > nope...not joking...I am that
stupid..teehee.
> >
> > How do I write I kernal/module
driver?
> >
> > I designed a A/D card and I need to acquire
data at about 1MByte/s. It
> > works perfectly up to 8 or 9 seconds but
I need 25 seconds worth of
> > data. I have a 4K FIFO but it looks like
I would need at least a 32K
> > FIFO...maybe more.
> >
>
> Are there other processes I can stop?
> >
> >
Thanks.
> >
> > Mike
> >
> > --- In .com
<ts-7000%40yahoogroups.com>, Jim Jackson
> > <>
wrote:
> > >
> > >
> > >
> >
>
> > > On Sun, 22 Oct 2006, Mike Dupuis wrote:
> >
>
> > > > I am using a TS-7200. How do I disable the
interrupts so my code does
> > > > not get interrupted. I am
using GCC on Debian Linux. Usually I use
> > > > commands like
"cli" and "sti" but these are not recognized when I
> > try to
>
> > > compile my program.
> > >
> > > :-) you
are joking aren't you?
> > >
> > > You can only do that
sort of thing in the kernel.
> > > If your code really cannot be
interrupted, then you should be writing a
> > > kernel module/driver
for your specific purpose.
> > > Just out of curiosity, what is it
you don't want interrupting?
> > >
> > > Jim
>
> >
> >
> >
> >
>
>
>
>
--
> Dr. Don W. Carr
> J. G. Montenegro 2258
> Guadalajara,
Mexico
> +52-333-630-0704
> +52-333-836-4500 ext
2930
>
__._,_.___
![]()
SPONSORED LINKS
__,_._,___
_______________________________________________________
NOTE: The information in this message is intended for the personal and confidential use
of the designated recipient(s) named above. To the extent the recipient(s) is/are bound
by a non-disclosure agreement, or other agreement that contains an obligation of
confidentiality, with AuthenTec, then this message and/or any attachments shall be
considered confidential information and subject to the confidentiality terms of that
agreement. If the reader of this message is not the intended recipient named above, you
are notified that you have received this document in error, and any review, dissemination,
distribution or copying of this message is strictly prohibited. If you have received this
document in error, please delete the original message and notify the sender immediately.
Thank you.
AuthenTec, Inc. http://www.authentec.com
|