I think that at one time or other, just about every one of us has -- or
will -- use the parallel port for this purpose. There's only one problem in
a Linux system: the kernel doesn't always give up access to the ports
without a fight.
While there are many solutions, here are two that I've used successfully in
the past:
1. Some (early) add-in parallel port boards could be modified to reside
at non-standard addresses. Cutting a few traces and/or adding a few jumpers
made it appear at a place the kernel would never think to look for a
parallel port and nothing else (that I ever used) would conflict with it.
2. There are some relatively inexpensive "discrete I/O" boards --
Jameco's offering comes to mind -- that have anywhere from one to six
input/output ports.
Using either of these methods allows:
(1) no possible conflict with the normal linux kernel's co-opting the
standard parallel ports
(2) no conflict with (most) other boards;
(3) easily "removed" for production systems: if there is no port at the
specified address, the I/O operation simply goes into the bit-bucket even if
you haven't #define'd or commented out the operations in your operational
code.
Norm
----- Original Message -----
From: Estabridis, Janet P <[EMAIL PROTECTED]>
To: 'David Olofson ' <[EMAIL PROTECTED]>; 'Jeffrey Krasky '
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, February 15, 2001 12:18 PM
Subject: RE: real-time versus non-real-time
> Jeffery,
>
> I use the parallel port and set and clear a bit when I enter and exit a
IRS
> or thread (I use a different bit for each ISR or thread). Then I use an
> o-scope to see what is happening. That way I have also documented my
> embedded code to show the timing and how everything interacts.
>
> Janet Estabridis
>
> -----Original Message-----
> From: David Olofson
> To: Jeffrey Krasky; [EMAIL PROTECTED]
> Sent: 2/15/01 7:55 AM
> Subject: Re: real-time versus non-real-time
>
> On Thursday 15 February 2001 15:40, Jeffrey Krasky wrote:
>
> > > Hi,
> > is there a way in Linux to run a process and determine which other
> > processes might have been going on during the execution of your
> process? I
> > would like to run my task in real-time and see how long it takes to
> run,
> > and then run it in ordinary linux mode and see how long it takes to
> run.
>
> Well, if you want to be entirely sure you're not being disturbed, just
> run
> your thread as SCHED_FIFO at top prio - that will freeze the entire user
>
> space until you release the CPU. (It's effective to the point that
> you'll
> have to press the reset button if your code doesn't feel like giving
> up!)
>
>
> > Then I want to note the differences, but I would like to also be able
> to
> > see, when running in ordinary linux mode, if anything else used any of
> the
> > same CPUs as my task did.
>
> Not possible in SCHED_FIFO mode - the timesharing is entirely bypassed,
> giving you full control over CPU utilization until you yield. However,
> note
> that the *kernel* still has higher priority than your thread, if it
> should
> feel like doing something.
>
>
> Anyway, what are you looking for, really? There shouldn't be any
> differences
> in raw code execution speed, I think... (Unless you're going to compare
> kernel vs user space ways of doing various kinds of I/O and that kind of
>
> stuff, of course. :-)
>
>
> file://David
>
> - M A I A -------------------------------------------------.
> | Multimedia Application Integration Architecture |
> | A Free/Open Source Plugin API for Professional Multimedia |
> `----------------------> http://www.linuxaudiodev.com/maia -'
> .- David Olofson -------------------------------------------.
> | Audio Hacker - Open Source Advocate - Singer - Songwriter |
> `--------------------------------------> [EMAIL PROTECTED] -'
