PC scope point

More of a PC hardware question really...

I want to attach a scope probe to a PC to detect program activity...(newish model, no ISA, running W2000).

The general idea is that I can write a test instruction in my C++ program, and this would cause a blip on the scope when the instruction gets executed. The purpose is to get visual information about program timings etc..

The pulse has to come out very, very soon after the instruction gets executed, and not be delayed by the OS stack (otherwise I would have done something like sending an edge to a serial port RTS line, or use the sound card/joystick)

The shape of the pulse is irrelevant, I just want a positive reaction that can be detected by a scope probe.

Any bright ideas how I can do this???

TIA

ted

Reply to
ted
Loading thread data ...

Bypass the OS, Write directly to the parallel port or some other I/O or memory address where you can attach a scope probe. I normally use a crude R-2R DAC ladder on LPT1 which I write value to. The scope then triggers on the "higest" value, and I can get different timings on one scope trace. Use something like giveio.sys to bypass Win2000.

Regards Anton Erasmus

--
Anton Erasmus
antone _at_ sentechsa  com
Reply to
Anton Erasmus

Or send a char out of an RS-232 port if you have one. It's not too hard to read the actual byte sent if you have a digital scope or a LA hooked up to it.

Reply to
Jim Stewart

formatting link
might be helpful.

Vadim

Reply to
Vadim Borshchev

Hi Ted,

I use a logic analyzer for those kinds of jobs. But you can also take a digital scope with long enough pre- and post-trigger storage. Then you can look at events that happened way before the trigger, which might allow you to use the RS232 or a parallel port 'ping' signal. I believe some scopes of the Tektronix TDS Series are equipped with long buffers. But it's been a while that I did that with a Tek scope (and just because the client had no logic analyzer and ours is too heavy for carry-on). Most of my work is HW and high frequency or fast digital stuff, not programming.

If you absolutely need to have your trigger really close to your event maybe you could send something unique to the video chip. That typically gets accessed rapidly. I did that once with an ET4000 (remember these?) by programming in a flip of the color palette, something extreme like from blue to red (no political pun intended...). Or place a hard disk access after a 'quiet period'.

Regards, Joerg

formatting link

Reply to
Joerg

Thanks all.

Perhaps I should have made the query a bit clearer...

I am after a method that will respond immediately after the instruction.

Any method that uses the OS will be too slow. Calling the OS, generating IRPs, calling the kernel routines..all takes far too long...(:-(

I am after some clever idea like placing the scope probe somewhere on the motherboard where such an "immediate" signal would be available.. any ideas??

TIA

Reply to
edaudio2000

There isn't such a thing except to perform a direct write to some IO port; and even those can be delayed from the execution of their instruction. With all the caching, prefetching, speculative branching and multiple execution streams not to mention smart IO controllers it is very, very difficult to tell exactly when an instruction is executed. Even if it is executed, it may have been a speculative execution whose results are not saved.

If I'm not mistaken, a write to an IO port with a read to the same port and some operation performed immediately on the data read would be the only way to be sure.

Noel

Reply to
Noel Henson

And at least some of the methods you were given do exactly that. In particular the "write to printer port" one.

The crux of the matter is what "immediately" means. Direct I/O port writing is "immediate" in the only sense that can possibly apply in a multitasking environment such as Windows NT: the physical change to the port pins will happen *before* your program gets to continue doing anything else. It's quite impossible to tell how long it will take from the point your program gets to the OUTP instruction to the voltage change, and from there to the execution of the next instruction of your program, by the very nature of the environment.

In other words, it's possible you're asking for the impossible.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

I would even quibble with the *before* in your description. While somewhat unlikely, it is quite possible that output to the port is queued up for later delivery, much like disk writes in Unix. Thus your program may be continuing while the data is still in the queue, and you cannot count on any timing relationship except that the signal occurs *after* the event.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 Click to see the full signature
Reply to
CBFalconer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.