Exact match. Not showing close matches.
'[OT] Logic Analyzer'
Ing. Marcelo Fornaso
I apologize for the OT, but you are the most talented and funny bunch of
*consultants* I know.
I need to test some serial signals, and so I've been working in a very
simple parallel port based logic analyzer.
My first try was Kyle C. Quinnell's "Building an 8-bit PC-Based Logic
Analyzer", from software and a description available on the Net. It's very
simple and easy to build (I assembled a bus driver and a voltage regulator
right into a DB-25 connector), but its sampling rate is only 5 KHz. (It's
based on the PC Timer0 interrupt). My hope was to be able to modify the
source code to accelerate
it, but 10 Khz was my best result.
So I turned to learn about EPP mode. It's claimed to transfer data at 500
KB/S to 2 MB/S and that's enough for me.
Now my project is a small piece of harware with a Pic (16F84?) reading
configuration from the EPP (sample rate, start trigger pattern, etc.), and
generating EPP handshake and the sampling clock (500 KHz?).
Named sampling clock would be connected to parallel port hardware interrupt
input, as to trigger PC's IRQ 7, which service routine reads the data and
fills the buffer (2K, 4K, 8K ?). OK?
My concern is that I need the samples to be evenly spaced in time (at the
rate of the sampling clock), but I know there is higher priority hardware
interrupts running in the PC.
To be short: How can I manage to get a steady data reading rate of 500 KHz?
Is it possible?
I'm writing C code.
Any idea will be fully appreciated!
Note: As you see there's at least one Pic (just to justify)
Ing. Marcelo M. Fornaso
> ... 500kHz sampling at PC parallel port...
You can start to forget about to run it under Windows (at least for a
while), write a simple timming loop routine (to run on pure DOS 6.22) to
read the parallel port and store the sample data... do it during a fixed
time and display the number of samples done, then you can fine tunning
the time delay so you can have a round number of samples per second.
In an old 20MHz 486 machine you will not be able to sample (and store,
etc) more than 50 to 80 thousand samples per second. I am telling this
because lots of people use old cheap ($150) notebooks to serve as logic
analyzer and data collector, and most of those run from 20 to 40Mhz...
When you start to migrate this routine to run under Windows, and it
starts to give you problems, and lots of headaches and you want to blame
somebody, just remember Bill Gates.
If you need some parallel port addresses and info, just pick at
|I had basically the same idea except mine was going to be a DSO utilizing
a PIC and a couple of MAXIM A/D converters. My idea for getting precise
sample rates was to use the PIC to generate the "clock". The PIC would
assert one of the status lines on the parallel port at precise intervals.
My PC (running at 233Mhz) would just sit and watch for the status line
to go high, then grab the reading and go back to waiting. With the
widely varying speed of PC's and their peripheral hardware, this was the
only method I could think of that guaranteed precise time intervals.
One of these days I hope to get the time to actually build the darn
Too many hobbies in Colorado :-),
On Wed, 8 Sep 1999 12:18:21 -0300 "Ing. Marcelo Fornaso"
<INFOVIA.COM.AR> writes: mfornaso
> Hi PicListers!
> I apologize for the OT, but you are the most talented and funny
> bunch of
> *consultants* I know.
> I need to test some serial signals, and so I've been working in a
> simple parallel port based logic analyzer.
Adam Bryant (age 0x23)
peaktech.com (work) abryant
juno.com (home) adamdb
Parker, CO, USA
Robotics, RC Airplanes, anything using a PIC
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: dl.http://www.juno.com/dynoget/tagj.
> When you start to migrate this routine to run under Windows, and
> it starts to give you problems, and lots of headaches and you
> want to blame somebody, just remember Bill Gates.
When you migrate anything from a single-process operating system
to a multi-process operating system, expect problems and headaches.
There is no one to blame - that's just the way it is. Either your
code runs at ring 0 or YOU are to blame.
|On Wed, Sep 08, 1999 at 03:46:04PM -0400, Steven Harter wrote:
> > When you start to migrate this routine to run under Windows, and
> > it starts to give you problems, and lots of headaches and you
> > want to blame somebody, just remember Bill Gates.
> When you migrate anything from a single-process operating system
> to a multi-process operating system, expect problems and headaches.
> There is no one to blame - that's just the way it is. Either your
> code runs at ring 0 or YOU are to blame.
Well, but to write the code running at ring 0 in Windows you have
to buy some additional tools (Windows DDK). I don't know if something
has changed since the old Win 3.1 times, when I was writing Win apps,
but then they wanted ~$500 for it. I've found a workaround, buying
the book "Writing Windows Virtual Drivers" with DDK Lite for $150 or so.
Maybe under pressure of Free Software they changed the DDK pricing
Wojciech M. Zabolotny
http://www.ise.pw.edu.pl/~wzab <--> ise.pw.edu.plwzab
http://www.debian.org Linux - free OS for free people!
More... (looser matching)
- Last day of these posts
- In 1999
, 2000 only
- New search...